522 Connection Timed Out (Cloudflare) Fix

Problem

Cloudflare returns Error 522: Connection timed out. Cloudflare’s edge sent a TCP SYN toward your origin and waited for the SYN-ACK that completes the handshake. It never arrived. After roughly fifteen to twenty seconds Cloudflare gives up and serves the 522 page. Unlike a 521, nothing refused the connection — there was simply no answer at all.

Symptoms

• Cloudflare’s branded error page shows Error 522.
• The error appears after a long hang, not immediately (this is the key tell that separates a 522 timeout from a 521 reset).
• The site often loads fine when you hit the origin IP directly from your own machine.

Top 3 Causes

1. A firewall is silently dropping Cloudflare’s packets - This is the most common cause. An OS firewall (iptables/ufw), a cloud security group, or a fail2ban-style tool blocks Cloudflare’s IP ranges with a DROP rule rather than REJECT. A drop sends nothing back — no reset, no ICMP — so Cloudflare’s SYN goes into the void and the handshake times out. (A REJECT would instead bounce back instantly as a 521.)
2. The origin is overloaded - The web server is up but cannot accept new connections in time. A full accept queue, exhausted worker processes, or a saturated CPU means the SYN-ACK is delayed past Cloudflare’s timeout. This is why 522 often shows up only at peak traffic.
3. Broken routing or a wrong origin IP - The proxied A/AAAA record points to an IP that is up but on a path Cloudflare cannot complete — asymmetric routing, a misconfigured NAT, or an origin that answers your residential ISP but not Cloudflare’s network. The SYN leaves but the reply never finds its way back.

Diagnose with DechoNet

• Port Check against your origin IP for ports 80 and 443. A timeout here mirrors exactly what Cloudflare sees; an open result means the port works in general and the block is specific to Cloudflare’s source IPs.
• HTTP Check against the origin to confirm whether it responds at all once a connection opens.

Resolution Checklist

• Confirm the server is listening and not just running: ss -tlnp | grep -E ':(80|443)'. Then watch for SYNs arriving but never completing: ss -tn state syn-recv. A pile of SYN-RECV entries means the handshake is stalling on the origin side.
• Test from outside, bypassing Cloudflare: curl -v --connect-timeout 20 http://ORIGIN_IP. A hang ending in Connection timed out (not Connection refused) confirms a 522-class problem.
• Audit the firewall for DROP rules that hit Cloudflare’s ranges. Allowlist the published ranges from cloudflare.com/ips on ports 80 and 443 in every layer — OS, host panel, and cloud security group.
• Because Cloudflare updates its ranges periodically, automate the allowlist (a cron job pulling cloudflare.com/ips) so a future range change does not silently re-break the origin.
• If the error tracks with traffic, check origin capacity: worker/connection limits (nginx worker_connections, PHP-FPM pm.max_children), the listen backlog (net.core.somaxconn), and CPU/memory headroom under load.
• Re-run Port Check on the origin to confirm 80/443 now complete the handshake from outside, then reload the site.

When to Escalate

• If a managed host or platform controls the firewall and you cannot add Cloudflare’s ranges yourself, send the provider the IP list from cloudflare.com/ips and ask them to allow it on 80 and 443.
• Intermittent 522s that survive a clean firewall and a healthy origin can be a path MTU black hole: small packets (the SYN) pass, but the larger packets carrying the actual request stall. Clamp the MSS on the origin’s egress (iptables ... TCPMSS --clamp-mss-to-pmtu) and re-test.