One of seven proxy nodes not replying to request

What is the name of the domain?

alandsradio.ax

What is the error number?

None

What is the error message?

None

What is the issue you’re encountering

One of seven proxy nodes is not responding to requests since last Thursday

What steps have you taken to resolve the issue?

Check events, requests do not show up as blocked.

What are the steps to reproduce the issue?

nslookup alandsradio.ax, check that IP 104.21.32.1 is a valid IP for the domain
Test tracert - successful
Set IP 104.21.32.1 to alandsradio.ax in hosts file
Make a http/s request - fails

This has been ongoing since Thursday 17th, save for a six hour “break” on the night between Saturday and Sunday.

Packet capture on WAN IF on our firewall shows:

08:07:31.859737 IP (tos 0x0, ttl 62, id 31213, offset 0, flags [DF], proto TCP (6), length 60)
ourfirewall.ip.49433 > 104.21.32.1.443: Flags [S], cksum 0xaaf6 (correct), seq 2403384109, win 64240, options [mss 1460,sackOK,TS val 4238186990 ecr 0,nop,wscale 7], length 0
08:07:32.874006 IP (tos 0x0, ttl 62, id 31214, offset 0, flags [DF], proto TCP (6), length 60)
ourfirewall.ip.49433 > 104.21.32.1.443: Flags [S], cksum 0xa6ff (correct), seq 2403384109, win 64240, options [mss 1460,sackOK,TS val 4238188005 ecr 0,nop,wscale 7], length 0
08:07:34.889960 IP (tos 0x0, ttl 62, id 31215, offset 0, flags [DF], proto TCP (6), length 60)
ourfirewall.ip.49433 > 104.21.32.1.443: Flags [S], cksum 0x9f1f (correct), seq 2403384109, win 64240, options [mss 1460,sackOK,TS val 4238190021 ecr 0,nop,wscale 7], length 0
08:07:36.865500 IP (tos 0x0, ttl 62, id 5814, offset 0, flags [DF], proto TCP (6), length 60)

No response at all, just silence.

Any idea what might be causing this?

Best regards
Alexander

Maybe it is that IP address is blocked by your ISP for some reason, use a traceroute to check.

There are 6 other IPv4s (plus 7 IPv6) returned from the DNS for requests for your domain, so any application should be using one of the others.

[add]
Just to be clear, the IPs don’t resolve to a particular physical “node”. Cloudflare uses anycast routing so all Cloudflare proxy IPs are announced from all Cloudflare data centres, and the request may answered by any one of the large number of servers in the data centre that your request is routed to.

1 Like

Hello sjr,

See second reproduction step:

Output is:

1 <1 ms <1 ms <1 ms 194.110.179.193
2 <1 ms <1 ms 1 ms be3.cr2.dc1.ax.as3238.net [194.112.2.232]
3 3 ms 3 ms 3 ms te0-20.cr2.mt.ax.as3238.net [194.112.7.158]
4 * * * Request timed out.
5 7 ms 10 ms 15 ms netnod-ix-ge-a-sth-1500.cloudflare.com [194.68.123.246]
6 6 ms 7 ms 10 ms 172.68.180.37
7 3 ms 3 ms 3 ms 104.21.32.1

Sorry, it was our web dev that used the term node for the proxy IP the last time we had trouble.
Either way, it’s something related to this IP.

As we have seen the IP:s come and go already during the few months we have been behind Cloudflare, we cannot rely on setting a fixed IP either. The service that is having trouble, or rather is most indicative of this issue, is doing requests by domain, mostly hitting one of the good IP:s but sometimes not and timing out. Since it’s under my control I could and will probably add logic to mitigate, but at the same time it does not feel good to have a “dead” IP sloshing about.

The traceroute is ok. The allocation of IPs is done by Cloudflare so you can’t change them. Do you actually get any problem?

Yes, the reason we found this out is from a service that is pulling rss feeds from the site and using them to render text in a video feed. The timeouts are causing delays with black video sequences as a result, triggering an alarm.

Like I wrote, I can probably fix this on my end, but who knows what other issues exist out there because of this. It all depends on the implementation of the request mechanism used, some might handle the timeouts transparently, some not.

Best/A

Those IPs are allocated to probably millions of sites on the free plan so if it was an issue then someone would have noticed. Most likely an issue on the connection from you, through your ISP to where they peer with Cloudflare.

1 Like

While that might be the most plausible scenario, I think the following indicates that the problem indeed exists between the proxy and something further within Cloudflare:

PS C:\Users\alexander> curl -4 -I -L https://www.alandsradio.ax
HTTP/1.1 301 Moved Permanently
Date: Wed, 23 Apr 2025 06:54:10 GMT
Content-Type: text/plain
Connection: keep-alive
Cache-Control: public, max-age=0, must-revalidate
Location: https://alandsradio.ax/
Server: cloudflare
Strict-Transport-Security: max-age=63072000
X-Vercel-Id: arn1::ft29r-1745391250527-e02b05895f15
Cf-Cache-Status: DYNAMIC
CF-RAY: 934b72b38fa6569c-OSL
alt-svc: h3=":443"; ma=86400

curl: (28) Failed to connect to alandsradio.ax port 443 after 21008 ms: Could not connect to server
PS C:\Users\alexander> curl -4 -I -L https://www.alandsradio.ax

If I remove

104.21.32.1 alandsradio.ax

from hosts, requests gets through without a problem.

Any thoughts?

Lots you can try…

Do you see the same when you try to get to sjr.org.uk in the same ways? (free plan zone, allocated the same 7 IPs).
Can you check https://alandsradio.ax/cdn-cgi/trace to see the colo you are connecting to?
Can you do a tcptraceroute to port 443 for that IP?
Can you try on another ISP? (check the colo used by Cloudflare there)

fwiw, I can reach your site on that IP from my location, but that doesn’t mean much due to anycast so it can only be an issue at a particular colo, or something between you and Cloudflare.

2 Likes

Hello sjr,

Thank you, I actually wondered to myself this morning if there is a tool that can trace using other ports and protocols, as tracert is a bit limited.

tcptraceroute is definitely going into the standard toolbox from now on, and you were most likely correct. Seems like other traffic is pushing through all the way to Cloudflare but not 443 specifically, stopping at the last hop before reaching the edge router.

Will proceed with the ISP.

Best regards

Alexander

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.