![[DigitalPoint] App for Cloudflare®](/community/data/resource_icons/8/8750.jpg?1692633961){kind=icon}
[DigitalPoint] App for Cloudflare® 1.9.4
- Thread starter digitalpoint
- Start date
nodle
Well-known member
Shared hosting as well, before I was on a dedicated host package (same company). Support is looking into it for me now. I think like @digitalpoint said it's a handshake issue between the host and Cloudflare, I also get a Curl 6 error which points that way as well.
digitalpoint
Well-known member
If it helps in debugging/troubleshooting on your end, most API calls are being made to the hostname
api.cloudflare.com (basically all API requests if you don't count R2 stuff). At the most basic networking level, your server needs to be able to communicate with that host over HTTPS.At this point, there are many thousands of sites using the addon between the XenForo and WordPress version, so I'm confident that whatever is going on is a network issue with your server of some sort... Could be janky network routes, could be out of date root certificates, etc. There are enough sites using it and surely someone else would be seeing the same issue if it's not something unique to your server.
While it might not be the issue, there's a possibility a basic cURL request from the server's shell may yield some insight...
Code:
curl https://api.cloudflare.com -v
* Rebuilt URL to: https://api.cloudflare.com/
* Trying 104.19.193.29...
* TCP_NODELAY set
* Connected to api.cloudflare.com (104.19.193.29) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=api.cloudflare.com
* start date: Jun 26 20:29:08 2025 GMT
* expire date: Sep 24 21:28:51 2025 GMT
* subjectAltName: host "api.cloudflare.com" matched cert's "api.cloudflare.com"
* issuer: C=US; O=Google Trust Services; CN=WE1
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55c12f854040)
> GET / HTTP/2
> Host: api.cloudflare.com
> User-Agent: curl/7.60.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 301
< date: Tue, 15 Jul 2025 16:18:54 GMT
< content-length: 0
< location: https://developers.cloudflare.com/api/
< set-cookie: __cf_bm=yKszgxZIfmysj7YuJzYGCyZJgjGn5.va1We8HupdSq8-1752596334-1.0.1.1-ysyxvzeKORQsEFMLnaljF9HG0K99ik5zdWPePJS1YWI3CU9iUUuuiDReilczPWHCoZq546aBQNqnXOx2WcKpdu7DW6FEVGSAvwpWwmmY1II; path=/; expires=Tue, 15-Jul-25 16:48:54 GMT; domain=.api.cloudflare.com; HttpOnly; Secure; SameSite=None
< set-cookie: _cfuvid=qb1MZ0aY2yWH6AL4jKn_6Hjt3CoOiuEgP2dkKGh1w34-1752596334888-0.0.1.1-604800000; path=/; domain=.api.cloudflare.com; HttpOnly; Secure; SameSite=None
< server: cloudflare
< cf-ray: 95fa9414fadc51f0-LAX
<
* Connection #0 to host api.cloudflare.com left intactLike if cURL can't connect, it should tell you why... like incompatible SSL certificates, unsupported ciphers, unsupported TLS version, HTTP version mismatch, etc.
It could even be the date/time on the server being incorrect (date/time is used for SSL verification).
Last edited:
nodle
Well-known member
This my cURL error I get:
Code:
cURL error 6: Could not resolve host: api.cloudflare.com (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://api.cloudflare.com/client/v4/zones/70c57e5ce45f8e11c800d5ecbedecf75/rulesets/phases/http_request_firewall_custom/entrypointI sent this post to support so hopefully they can figure it out, thanks again @digitalpoint .
digitalpoint
Well-known member
Ya... so that would point to DNS issues with the server. The server definitely needs to be able to resolve hostnames into IP addresses.
I assume the server admins will be able to resolve that fairly easily... if you want to check what server it's using for DNS, run this dig command:
Code:
dig api.cloudflare.comTowards the bottom, you'll see a
SERVER line.You can also force dig to use a different DNS server as a test. For example Google's DNS servers:
Code:
dig api.cloudflare.com @8.8.8.8...or a Cloudflare DNS server:
Code:
dig api.cloudflare.com @1.1.1.1nodle
Well-known member
Here is my dig output:Ya... so that would point to DNS issues with the server. The server definitely needs to be able to resolve hostnames into IP addresses.
I assume the server admins will be able to resolve that fairly easily... if you want to check what server it's using for DNS, run this dig command:
Code:dig api.cloudflare.com
Towards the bottom, you'll see aSERVERline.
You can also force dig to use a different DNS server as a test. For example Google's DNS servers:
Code:dig api.cloudflare.com @8.8.8.8
...or a Cloudflare DNS server:
Code:dig api.cloudflare.com @1.1.1.1
digitalpoint
Well-known member
If your server is using 8.8.8.8 by default (you didn’t do that with the
It’s done to prevent abuse, as those servers are meant for end users, not servers. That would also explain why it works for you once in awhile (when the rate limit expires, it will answer DNS requests for a bit until the server is rate limited again).
See: https://developers.google.com/speed/public-dns/docs/isp
@8.8.8.8 operator), your server really should not be using public DNS as it’s DNS. Specifically 8.8.8.8 and 1.1.1.1 (and more or less all public DNS servers) have rate limits… meaning they will stop answering requests if too many DNS requests come from an IP or network.It’s done to prevent abuse, as those servers are meant for end users, not servers. That would also explain why it works for you once in awhile (when the rate limit expires, it will answer DNS requests for a bit until the server is rate limited again).
See: https://developers.google.com/speed/public-dns/docs/isp
digitalpoint
Well-known member
Cloudflare's public DNS is rate limited as well... if you hit the rate limit, it will also stop answering requests, even if it's for a Cloudflare domain.That might be the difference - my DNS is with cloudflare rather than with the server. You could maybe try that? Although ignore me and listen to digitalpoint as he knows what he's talking about and I don't
Long story short is using 8.8.8.8, 1.1.1.1 or any other public DNS for a production server is lazy and will be problematic because if your network needs to do a lot of hostname resolutions, they will stop working while they are being rate limited.
nodle
Well-known member
The Host says everything is working fine on their end, *Sigh…
Code:
[mysite@myserver ~]$ curl https://api.cloudflare.com -v
* About to connect() to api.cloudflare.com port 443 (#0)
* Trying 104.19.192.176...
* Connected to api.cloudflare.com (104.19.192.176) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=api.cloudflare.com
* start date: Jun 26 20:29:08 2025 GMT
* expire date: Sep 24 21:28:51 2025 GMT
* common name: api.cloudflare.com
* issuer: CN=WE1,O=Google Trust Services,C=US
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: api.cloudflare.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Date: Tue, 15 Jul 2025 18:36:44 GMT
< Content-Length: 0
< Connection: keep-alive
< Location: https://developers.cloudflare.com/api/
< Set-Cookie: __cf_bm=bwIRwd5HvbNerDB4NHSxcHzyydNdcXO9ajW3Yo_CVVs-1752604604-1.0.1.1-ncW8oVQHazNJDC4oYJXO6oDQvxbArCSv2KC73saaeAJfV_SIBS7_YvtS58jG04OVSGdhpl7z2.Mg__vKB4h0TEoQTk9kgw48wE6kJPqV92o; path=/; expires=Tue, 15-Jul-25 19:06:44 GMT; domain=.api.cloudflare.com; HttpOnly; Secure; SameSite=None
< Set-Cookie: _cfuvid=bSFrATiMyQyuiSSd3xcUl1pFMocDChKfq929NO36T5U-1752604604176-0.0.1.1-604800000; path=/; domain=.api.cloudflare.com; HttpOnly; Secure; SameSite=None
< Server: cloudflare
< CF-RAY: 95fb5df7dd8c6b3b-DFW
<
* Connection #0 to host api.cloudflare.com left intactdigitalpoint
Well-known member
Like I said, it looks like an issue with the name server. 8.8.8.8 is not intended to be used with servers… will work until it doesn’t (when it’s rate limited). The issue you saw earlier was a DNS issue, not a network issue.
If you can change the name server that your server uses, change it to a non-public one or run your own name server.
If you can change the name server that your server uses, change it to a non-public one or run your own name server.
digitalpoint
Well-known member
Maybe something more like this... Does this happen to work for your style?
Less:
.switch-field {
input {
&:checked + label {
background-color: @xf-borderColorAccentContent;
}
}
label {
background-color: @xf-contentAltBg;
color: @xf-textColor;
border: 1px solid @xf-borderColorHeavy;
}
}
