![[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;
}
}
Matt C.
Well-known member
nodle
Well-known member
Anything left I should tell them @digitalpoint? I have sent them everything that you said, but I think they are blaming the addon.
digitalpoint
Well-known member
Well, I was just saying that because YOU couldn't resolve api.cloudflare.com from the server (outside of the addon). See:Anything left I should tell them @digitalpoint? I have sent them everything that you said, but I think they are blaming the addon.
Maybe don't confuse them by saying it's specific to the addon. They don't need to debug the addon... the server wasn't able to resolve api.cloudflare.com even when NOT using the addon (via curl on the shell). That's the issue... The addon isn't doing any DNS resolution on it's own, it's relying on the server's network stack.
Your server appeared to be using 8.8.8.8 for DNS, and unless the ISP has been granted an exception by Google for it's rate-limiting, it's not always going to do DNS properly in a server environment:
Google Public DNS for ISPs | Google for Developers
developers.google.com
nodle
Well-known member
I did that, but I don’t think they want to admit it’s their problem.Anything left I should tell them @digitalpoint? I have sent them everything that you said, but I think they are blaming the addon.
It’s fine, at this point I either have to uninstall your addon or try to find a new host. I appreciate all the support you gave, I know it’s not your problem.
digitalpoint
Well-known member
Well, not sure what to tell you... if your server admins are refusing to give you a server that can (always) resolve DNS queries, I know what I would do (switch to a better host).
Not only is 8.8.8.8 rate-limited by Google, using an external DNS server (external to your server's data center) is going to be slower (in addition to being rate limited) because your server needs to make requests to Gogole's servers (longer network path) vs. making a local request.
Either way, if your hosting company thinks using 8.8.8.8 (or any other public DNS server) is "fine" for a production server, they are wrong. They can blame it on whatever they want, but Google documentation LITERALLY says not to use them for ISPs. They literally ask ISPs to do anything/everything other than use them... even suggesting using other DNS servers.
Google said:
digitalpoint
Well-known member
Usually that's going to be an old/outdated version of cURL or outdated root certificates on your server. The link it gives you tells you those for error 35:
Last edited:
