Cloudflare Error 522 — "Connection Timed Out" — means Cloudflare's edge tried to open a TCP connection to your origin server and the SYN it sent out never got a SYN-ACK back within the configured window. No request was made. No HTTP exchange happened. The proxy never even got to the part where it could ask "is the origin up?" — the network handshake before that step failed. That distinction is what makes 522 different from every other 5xx in Cloudflare's family.
The literal definition ¶
522 lives one layer below the entire HTTP conversation. When Cloudflare's edge wants to reach your origin, it goes through this sequence:
- Resolve the origin hostname (or the configured origin IP).
- Open a TCP socket: send SYN, expect SYN-ACK back, send ACK.
- If HTTPS to origin: TLS handshake.
- Send the actual HTTP request.
- Receive and forward the response.
522 fires when step 2 doesn't complete inside Cloudflare's window (about 15 seconds at the edge). The SYN went out; the SYN-ACK never came back. From Cloudflare's perspective, the origin is either offline, blocking inbound, or unreachable across the network — and crucially, none of these can be diagnosed from response-headers data because no response ever happened.
522 vs 520 vs 523 vs 524 ¶
| Code | What Cloudflare saw | Layer it fails at |
|---|---|---|
| 521 Web Server Is Down | TCP connection actively refused — RST or ICMP unreachable came back fast. | Origin actively rejecting (port closed, firewall block). |
| 522 Connection Timed Out | TCP SYN sent, no SYN-ACK received within ~15s. | Network path or origin's accept queue, silent drop. |
| 523 Origin Is Unreachable | Cloudflare couldn't determine where to send the request at all — DNS lookup failed or origin's IP isn't routable from Cloudflare's network. | Resolution / routing. |
| 524 A Timeout Occurred | TCP connection established, HTTP request sent, response never finished within the 100s window. | Application slowness — origin too slow to respond. |
| 520 Unknown Error | Origin responded, but response wasn't parseable HTTP. | Origin sent malformed bytes. |
Quick mental shortcut: 521 = origin said no. 522 = origin didn't answer at all. 523 = couldn't find origin. 524 = origin took too long to send the response after the connection worked. 520 = origin replied but with garbage.
Six real-world causes of 522 ¶
1. Cloudflare's IP ranges are blocked at the origin firewall
The most common cause. Someone tightened the security group, edge firewall, or fail2ban policy on the origin to block "all inbound except trusted IPs" — and Cloudflare's edge IPs were the obvious unintentional casualty. The origin silently drops the SYN; Cloudflare sees timeout. The fix is to explicitly allowlist Cloudflare's published IP ranges at every firewall layer between the public internet and the origin. cloudflare.com/ips-v4 + /ips-v6 are the canonical lists.
2. The origin's accept queue is saturated
Linux maintains a per-port queue of TCP connections waiting for the application to accept them. Default sizes (net.core.somaxconn, application-level backlog) are typically 128 — fine for low traffic, catastrophic during a viral spike. When the queue is full, new SYN packets get silently dropped. From Cloudflare's perspective: timeout. The application doesn't even know connections are being attempted. ss -ltnp on the origin shows current queue depth.
3. The origin's network path is congested or broken
BGP route flap, ISP-level packet loss between Cloudflare's edge POP and the origin's data center, asymmetric routing where the SYN reaches the origin but the SYN-ACK goes a different way and gets lost. None of these are visible from the origin side because no application-layer interaction happened. The diagnostic is mtr / traceroute from one of Cloudflare's POPs (which non-Enterprise customers don't have direct access to, hence the difficulty).
4. The origin VM / pod was rotated and Cloudflare still has the old IP
Cloudflare caches DNS resolutions for origin hostnames according to TTL. If you rotate origin servers and the new IP isn't in Cloudflare's cache yet — or worse, if Cloudflare is hitting the old IP that's now unallocated — every connection times out until the TTL expires. Fix: lower the origin DNS TTL before any rotation, and let Cloudflare's "Argo Tunnel" / Cloudflare Tunnel handle the address opacity if that's an option.
5. The application crashed but the port is still bound
Less common but distinctive: the origin process died in a way that left the listening socket half-open. Nothing is accepting connections, but the OS still reports the port as "in use" so systemd doesn't restart the service. SYN packets get dropped because there's no accept queue. Restarting the application clears it; an upgrade to a properly-supervised process manager prevents recurrence.
6. SSL Full (Strict) mode + origin port is HTTPS but cert is on a different name
Cloudflare's Full (Strict) SSL mode requires the origin's TLS cert to match a name Cloudflare trusts. If the origin presents a self-signed or expired cert, Cloudflare aborts the connection at the TLS layer — and some Cloudflare configs surface that abort as 522 rather than 525 (TLS handshake failed). Misleading but real. Setting SSL mode to Full (without Strict) avoids this if cert validation isn't a hard requirement; otherwise fix the origin cert.
Diagnosing 522 as the site owner ¶
Top to bottom, five steps:
- Check the cf-ray header on the error page. The trailing three letters are the Cloudflare data center attempting the connection. If it's consistently the same POP across requests, you might be hitting region-specific routing. If it changes across requests, the issue is on your origin side, not Cloudflare's path.
- Hit the origin directly from the public internet.
curl -v https://origin-direct-host.example.com/from a non-Cloudflare-IP source. If you can reach it, Cloudflare is having a routing problem to your origin specifically. If you can't reach it either, the origin is genuinely unreachable from the public internet. - Allowlist Cloudflare's IPs at every firewall layer. Cloud security group, OS-level firewall (iptables / ufw / firewalld), edge firewall, WAF, DDoS protection box. Even if you "haven't changed anything," double-check after any infra event — a cloud provider's automation may have tightened rules silently.
- Check the accept queue depth.
ss -ltnshows Send-Q (current queue) and Recv-Q (max queue). If Send-Q is close to Recv-Q, you're SYN-flood-shaped (intentional or not) and need a bigger backlog + a deeper investigation of why. - Pull the origin's recent logs at the moment of the 522. If the application logs show no connection attempts at all, the SYN never made it. If logs show connections accepted but no response, you're in 524 territory. The log evidence picks between the layers.
Diagnosing 522 as a user ¶
522s are server-side problems. There's nothing on a user's side that produces one. Two useful actions:
- Wait two minutes and try again. Many 522s are short-lived spikes (a cloud rotation, a brief firewall blip). They self-resolve within seconds.
- Note the cf-ray. Same as 520: if you're reporting the problem to the site operator, the Ray ID is the highest-value piece of info they can use to look up the exact failed connection in Cloudflare's logs.
Why this isn't fixable with DNS or browser tricks ¶
Sometimes Reddit answers to "fix Cloudflare 522" suggest flushing DNS, changing browsers, using a VPN, or clearing cookies. None of these touch the TCP-handshake-between-Cloudflare-and-origin layer where the failure lives. Your TCP connection to Cloudflare is fine — that's why you're getting the error page at all instead of a connection failure. The handshake that's broken is in a layer the user can't see or control. Site owner action is the only fix.
FAQ ¶
How is 522 different from 524?
522 fires before any HTTP request happens — the TCP connection itself never completed. 524 fires after the TCP connection succeeded and Cloudflare sent the HTTP request, but the origin never finished responding within 100 seconds. 524 is solidly an application-slowness problem. 522 is a connection-layer problem at the network or firewall or OS level. The two often get conflated because both contain the word "timeout" in their meaning, but they fix differently.
Can Cloudflare itself cause a 522?
Rarely, but it happens during major Cloudflare incidents (routing issues, edge POP outages). Check Cloudflare's status page first when you see widespread 522s on multiple sites. If only your site is affected, it's not Cloudflare.
Why don't I see the Cloudflare IP allowlist as part of standard Linux distro configs?
Cloudflare publishes the lists but most distros leave firewall configuration to the operator. The Cloudflare list also changes occasionally (new POPs, new IP ranges), so you can't bake it permanently into a static config. Most operators set up a cron job or config-management hook to pull cloudflare.com/ips-v4 + /ips-v6 daily and refresh the allowlist.
Does using Cloudflare Tunnel avoid 522?
Yes — Cloudflare Tunnel reverses the connection direction. Instead of Cloudflare connecting inward to your origin, your origin establishes a persistent outbound tunnel to Cloudflare. There's no inbound firewall configuration to get wrong, no public IP to allowlist, no SYN-ACK path to worry about. The trade-off is the tunnel daemon becomes a piece of infrastructure you have to keep running, and you're inside Cloudflare's network harder than before.