Understanding Cloudflare 522 Connection Timed Out: The TCP Handshake That Never Finished
522 Connection Timed Out is Cloudflare giving up on your origin before a connection ever really got going — or, in a slightly later failure mode, giving up while waiting for your origin to acknowledge it received the request at all. Either way, this is a pre-response timeout: no HTTP data has been exchanged yet. This post covers the two specific timeout windows Cloudflare documents, why 522 is a different animal from 524 (which happens after a connection succeeds), and the checklist Cloudflare gives for tracking it down.
What Is a 522?
A 522 means Cloudflare's edge tried to establish or use a TCP connection to your origin, and it didn't get the expected acknowledgment in time.
Not a standard code. 522 has no RFC and no IANA registry entry — it's specific to Cloudflare's reverse-proxy architecture, describing a stage of the request (Cloudflare's own connection attempt to your origin) that a non-proxied server never goes through at all.
Cloudflare's documentation states the core definition simply:
Error 522 occurs when Cloudflare times out contacting the origin web server. — Cloudflare documentation, Error 522
Two Different Timeouts, Two Different Windows
What makes 522 worth understanding in detail is that Cloudflare's docs specify exactly where in the TCP conversation the timeout can happen, with real numbers attached — not vague "eventually gives up" language:
Two different timeouts cause HTTP error 522 depending on when they occur between Cloudflare and the origin web server: Before a connection is established, the origin web server does not return a SYN+ACK to Cloudflare within 19 seconds of Cloudflare sending a SYN (the SYN retry backoff scheme is 1,1,1,1,1,2,4,8). After a connection is established, the origin web server does not acknowledge (ACK) Cloudflare's resource request within 90 seconds. — Cloudflare documentation, Error 522
Breaking that down:
- The 19-second handshake window. TCP connections start with a SYN/SYN-ACK/ACK exchange. If Cloudflare sends a SYN and the origin never sends back a SYN+ACK within 19 seconds — even after retrying at the documented backoff intervals (1, 1, 1, 1, 1, 2, 4, 8 seconds) — Cloudflare treats the connection attempt as failed. Nothing about HTTP has happened yet; this is purely "can I even open a socket to you."
- The 90-second post-connection window. If the TCP handshake does succeed but the origin never acknowledges Cloudflare's resource request within 90 seconds, that also produces a 522 — even though a connection technically exists. This is the case worth remembering if your origin accepts connections fine but is too overloaded to service them promptly.
Both scenarios share the same signature: no HTTP response headers ever arrive. That's the line separating 522 from 524 A Timeout Occurred — 524 happens when the origin does start (or is expected to) respond but takes longer than Cloudflare's response timeout. 522 happens earlier, at the connection and request-acknowledgment stage.
Common Causes
Cloudflare's resolution guidance lists the recurring culprits, and the site data lines up closely:
Cloudflare IP addresses are rate limited or blocked in .htaccess, iptables, or firewalls. Confirm your hosting provider allows all Cloudflare IP ranges (most common cause). ... An overloaded or offline origin web server drops incoming requests. Keepalives are disabled at the origin web server. The origin IP address in your Cloudflare DNS app does not match the IP address currently provisioned to your origin web server by your hosting provider. Packets were dropped at your origin web server. — Cloudflare documentation, Error 522
Cloudflare explicitly calls out rate-limited or blocked Cloudflare IPs as the most common cause — the same theme as 521, just manifesting as silence instead of an outright refusal. An overloaded origin that's too busy to accept new connections, keepalive settings that close connections Cloudflare expected to reuse, and a stale origin IP in your DNS records round out the list.
Cloudflare's docs also flag a few platform-specific traps worth knowing if you're on their newer products: Cloudflare Pages projects need a properly configured custom domain and CNAME record, Workers with a Custom Domain will 522 if the Worker fetches its own hostname (their docs suggest using a Route, targeting a different hostname, or enabling the global_fetch_strictly_public compatibility flag instead), and Origin Rules pointing at an unresolvable hostname — such as a Worker route backed by a reserved address — will also produce a 522.
522 vs. 524 vs. 504
| Code | Meaning | Did the origin ever respond with HTTP data? |
|---|---|---|
| 522 Connection Timed Out | TCP handshake never completed, or the resource request was never acknowledged | No — failure is pre-HTTP, at the connection layer |
| 524 A Timeout Occurred | Connection succeeded but the origin didn't finish responding in time | No — but the connection stage succeeded; the response stage timed out |
| 504 Gateway Timeout | The standard-HTTP equivalent: a proxy waited too long on an upstream | Vendor-neutral — same category of failure, not tied to Cloudflare's specific timeout windows |
The practical distinction: a 522 tells you the connection itself is the bottleneck — network path, firewall, an overloaded listener queue. A 524 tells you the connection is fine and the application is what's slow to finish. If you're seeing 522s, don't start by optimizing your slow database query; start by checking whether Cloudflare can even reliably open a socket to your origin.
Diagnosing a 522
- Check the "most common cause" first: firewall and rate-limit rules. Confirm your hosting provider's firewall,
.htaccess, oriptablesrules allow all of Cloudflare's published IP ranges, not a stale or partial subset. - Look at origin load during the timeout window. If CPU, memory, or connection-queue metrics spike around the same time as the 522s, an overloaded listener that can't accept new TCP connections fast enough is a strong candidate.
- Verify keepalive settings. If keepalives are disabled at the origin, connections Cloudflare expects to reuse get torn down, forcing a fresh handshake for every request — under load, that's enough extra latency to blow past the 19-second window.
- Double-check the origin IP in your Cloudflare DNS records against what your hosting provider currently has provisioned. An IP that changed on the hosting side without a corresponding DNS update will silently misroute every connection attempt.
- Get an MTR or traceroute from the origin to a Cloudflare IP that was previously connecting successfully (visible in your origin's access logs) if none of the above explains it — this is the diagnostic Cloudflare support asks for directly.
Common Pitfalls
- Optimizing application code when the problem is the network path. A 522 fires before any HTTP request is even acknowledged — slow database queries and inefficient endpoints are a 524 or 504 problem, not a 522 problem.
- Assuming 19 seconds and 90 seconds are configurable. They're not settings on your side — they're Cloudflare's own connection-establishment and request-acknowledgment timeouts. The fix is making your origin respond within those windows, not requesting a longer timeout.
- Forgetting that Cloudflare's IP ranges change over time. An allowlist that worked at setup can silently start failing months later as ranges are added. Treat the published IP list as something to sync periodically, not a one-time copy-paste.
- Missing the Workers-fetching-its-own-hostname trap. If you're on Workers with a Custom Domain and see 522s specifically on requests the Worker makes to itself, that's a known, documented pattern — not a generic connectivity problem.
Wrapping Up
522 means the TCP-level conversation between Cloudflare and your origin never got far enough for any HTTP data to be exchanged — either the handshake itself timed out, or the origin never acknowledged the resource request. The rules of thumb:
- 522 = pre-response timeout. Handshake window is 19 seconds; post-connection acknowledgment window is 90 seconds, per Cloudflare's documentation.
- Blocked or rate-limited Cloudflare IPs are the most common cause, per Cloudflare's own guidance — check firewalls before anything else.
- 522 is distinct from 524, which happens after a successful connection when the origin is just slow to finish responding.
- Keep your firewall's Cloudflare IP allowlist current — Cloudflare's ranges change over time.
For more, see our pages on 522 Connection Timed Out, 520 Web Server Returns Unknown Error, 521 Web Server Is Down, 523 Origin Is Unreachable, and 524 A Timeout Occurred, plus our 504 Gateway Timeout and 408 Request Timeout posts for the vendor-neutral timeout family.