HTTP 522 Connection Timed Out: Cloudflare Can't Reach You

Jul 28, 2026 · HTTP Status Codes

Every web request starts with a ritual older than the web itself: the TCP handshake. One machine says SYN, the other answers SYN-ACK, the first confirms with ACK — three packets, and only then does anyone talk about HTTP. The 522 status code means that ritual never completed between Cloudflare and your origin server. Cloudflare said SYN and then... nothing. No answer, no refusal, no reset. It repeated itself for about fifteen seconds, gave up, and served your visitor an error page.

The diagnostic weight sits in that word nothing. Machines that are down-but-reachable send refusals. Silence means the packets are being eaten somewhere — and things that eat packets silently form a short, specific list.

A 522 status code is a handshake that never finished

Formally, Cloudflare serves a 522 in two situations: the TCP connection to the origin couldn't be established at all, or it was established but the origin didn't acknowledge the actual request within the allowed window. Both reduce to the same operational statement — the origin, from where Cloudflare stands, is unresponsive at the network level. Note what this is not: it's not your application being slow to render a page (that surfaces as a 504-style timeout much later in the exchange). A 522 fails before HTTP even begins.

Cloudflare's 52x family at a glance

Reading across that table: 521 and 522 are siblings separated by one firewall verb. REJECT sends a refusal and produces 521; DROP stays silent and produces 522. If your errors flipped from one to the other after someone "hardened" the server, the firewall change is your entire investigation. The murkier catch-all case is covered in our 520 guide.

What blocks the connection in real deployments

• Firewalls dropping Cloudflare's ranges. The top cause by a distance. Since all proxied traffic arrives from Cloudflare's IP space, any rule that drops those ranges — a provider's DDoS scrubber, an iptables DROP policy, a cloud security group missing an allow rule — blackholes the whole site. It especially bites after migrations, when someone rebuilds firewall rules from memory and forgets the Cloudflare allowlist.
• Rate limiting at the network layer. Here's a subtle one: to your origin, Cloudflare looks like a handful of IPs making all your traffic. Connection-rate rules that would never trip on organic visitors trip constantly on a CDN's concentrated egress, throttling or dropping new connections during busy periods. The signature is intermittent 522s that track your traffic curve.
• Server overload at the TCP level. A machine buried in load — full SYN backlog, exhausted connection table, CPU pinned at 100% — can be too far gone to complete handshakes. The application never sees any of it; the kernel is drowning before the request reaches userland.
• Routing and infrastructure failures. The origin's network is genuinely unreachable: a host down without sending resets, a provider network incident, or a changed origin IP that Cloudflare's DNS entry never learned about.
• Keepalive mismatches. Cloudflare reuses connections to origins; origin configs that cap connection reuse aggressively (very low keepalive_requests or short idle timeouts) can produce sporadic 522s under sustained traffic.

Testing the path from outside Cloudflare

The question to answer first: is the origin unreachable from everywhere, or only from Cloudflare? From any machine outside your network, test the origin IP directly — curl -m 10 -sI https://203.0.113.10/ -H 'Host: yoursite.com' -k — and if plain curl can't reach it, probe the port itself with nc -zv -w 5 203.0.113.10 443. Both timing out means the origin is down or blackholed for everyone: check the host, the provider's status page, and the routing. If your test connects fine while Cloudflare keeps serving 522s, the block is selective — something on the path admits your IP but eats Cloudflare's, and the firewall or the provider's protection layer is where you look. On the origin itself, watch live handshake attempts with tcpdump -n port 443 and 'tcp[tcpflags] & tcp-syn != 0': SYNs arriving from Cloudflare's ranges with no SYN-ACK leaving means the drop is local (firewall or overloaded kernel); no SYNs arriving at all means the packets die upstream of your machine. And if the timing correlates with load, check ss -s for connection-table pressure and the kernel log for SYN flood warnings — an overloaded server 522s intermittently, a firewalled one 522s consistently.

Crawl and ranking consequences of 522s

Search engines see a 522 as one more flavor of 5xx unavailability, and the standard consequences follow: temporary errors get shrugged off, sustained ones reduce crawl frequency, and weeks of unreachability drain pages from the index. Two things make 522s particularly corrosive in practice. They're often intermittent — a rate-limit or overload problem serves errors for minutes at a time, many times a day, which keeps a steady drip of failed crawl attempts in Google's ledger without ever producing a clean, noticeable outage. And they're origin-wide: when the network path is blocked, every URL errors together, so each bad window taxes the whole site's crawl. If organic traffic sagged and you're not sure why, pull the crawl stats report in Search Console and look at the error trend — then check your whole site for errors with an external crawl to see what crawlers are currently experiencing, URL by URL.

Keeping the origin reachable

Treat Cloudflare's IP ranges as first-class infrastructure: allowlist them explicitly in every firewall layer, exempt them from connection-rate rules (or better, rate-limit at Cloudflare's edge where per-visitor identity is visible, instead of at the origin where everything looks like Cloudflare). Keep the published range list fresh — it changes occasionally, and a stale copy is a slow-motion outage. Give the origin TCP headroom: a sane somaxconn, SYN cookies enabled, and enough capacity that peak load doesn't push the kernel into dropping handshakes. Update Cloudflare's DNS entry as part of any migration checklist, not as a thing someone remembers later. And monitor both paths — through Cloudflare and direct to the origin IP — because the difference between those two checks is the fastest 522 diagnosis there is: through-path fails while direct-path works, and you already know it's the edge-to-origin leg before you've logged into anything.