Intermittent 522 Errors from Cloudflare PDX & SEA Edge Locations — Works from SJC

[user4396]

What is the name of the domain?

theashlandchronicle com

What is the error number?

522

What is the error message?

Connection timed out Error code 522 Visit cloudflare for more information. 2025-07-01 22:06:40 UTC YouBrowserWorking SeattleCloudflareWorking theashlandchronicle hostError What happened? The initial connection between Cloudflare’s network and the origin web server timed out. As a result, the web page can not be displayed. What can I do? If you’re a visitor of this website: Please try again in a few minutes.

What is the issue you’re encountering

Intermittent 522 errors from PDX and SEA Cloudflare edges; works fine from SJC and LAX.

What steps have you taken to resolve the issue?

We confirmed the origin server is healthy (low load, fast response), and all Cloudflare IPs are allowlisted in the firewall. The site works consistently from SJC/LAX colos. Users near PDX/SEA report 522s. We tested MTR to Cloudflare IPs (e.g., 104.1651.111) from our server and saw no packet loss or latency. This appears to be a Cloudflare edge-to-origin routing issue.

What are the steps to reproduce the issue?

Access the site from an IP routed through the Cloudflare PDX or SEA colo (as seen via cdn-cgi-trace). While the site usually loads correctly, requests intermittently result in a 522 error — especially during WordPress post updates or page loads. The issue does not occur when routed through other colos like SJC or LAX.

[cf-scott]

Hey there!

Sorry to hear about the connectivity issue.

As the 522 error indicates, your origin is unreachable from some of Cloudflare’s IPs.

[EDIT] Now both exit IP addresses for an edge server showing the 522s are blocked: 172.71.150.169 & 172.71.150.168

Please follow the instructions in the 522 link to ensure Cloudflare can connect to your server.

[user4396]

Hi, thank you for the response. Pretty much everything the article recommended is already in place on the server, REDACTED. This is a dedicated server hosted with Interserver. The Cloudflare IP ranges are in place in CSF as both Ignore and Allow. I added them to cPGuard’s allowlist although there were no blocks against Cloudflare IP addresses there. I’ve been working on this with ChatGPT, here’s the information it suggested I give you:

Thanks for confirming the 522 errors are due to Cloudflare edge nodes (e.g., SEA and PDX) intermittently failing to connect to our origin IP: REDACTED.

We’ve double-checked everything on our end:

All Cloudflare IP ranges are fully allowlisted in both our firewall (CSF) and WAF (cPGuard)

Server load remains consistently low

Other colos like SJC and LAX have no trouble connecting

No rate limiting or packet filtering applies to Cloudflare traffic

To help isolate the issue, we also ran a traceroute from our origin server to your SEA edge node (104.16.51.111):

traceroute to 104.16.51.111 (104.16.51.111), 30 hops max, 60 byte packets
1 REDACTED 0.901 ms 1.634 ms 1.209 ms
2 * REDACTED 14.992 ms *
3 64.20.32.215 1.144 ms 0.757 ms 64.20.32.139 0.338 ms
4 64.20.32.65 2.405 ms 2.690 ms 2.057 ms
5 * * *
6 162.158.61.125 29.942 ms 162.158.61.101 1.479 ms 162.158.61.105 5.044 ms
7 104.16.51.111 1.457 ms 1.391 ms 1.694 ms
This shows the path from our origin to your SEA edge is healthy — no loss, low latency.

Given that:

Outbound traffic from our origin to SEA/PDX completes cleanly

But inbound traffic from Cloudflare’s SEA/PDX to our server fails intermittently

…it appears to be an asymmetric routing or peering issue between Cloudflare’s SEA/PDX edges and our hosting provider (InterServer or one of their upstream transit providers)

Please escalate this to your network team for investigation. We’d appreciate a review of routing paths and any packet loss or timeouts affecting these edge nodes when connecting to REDACTED.

[cf-scott]

It’s definitely at your provider’s end. A failing MTR dies on that last hop trying to connect to your IP address your theashlandchronicle.com DNS record points to. A successful MTR makes that last hop with 0% latency loss.

p.s. I’ve redacted anything resembling your Origin IP in this thread to prevent unwanted direct access.