Cloudflare Error 522: Connection Timed Out

What’s actually happening

The whole site goes down behind Cloudflare while the origin may still respond if you hit its IP directly. Visitors see the orange Cloudflare interstitial with the origin column marked as Error. It often comes and goes under load, then becomes permanent once the box is fully saturated or the firewall rule lands.

Common causes

• Origin firewall, security group, iptables, or .htaccess blocking Cloudflare's published IP ranges — this is the single most common cause.
• Origin web server is overloaded (CPU pegged, max worker/PHP-FPM processes hit) and silently dropping new connections.
• The A record in Cloudflare DNS points at a stale or wrong IP after a server migration.
• Keepalives disabled at the origin, so Cloudflare can't reuse connections and trips the timeout under concurrency.
• Packet loss or a routing problem between Cloudflare's edge and the origin (Cloudflare sends a SYN, never gets SYN+ACK within ~19 seconds).

How to fix it

1. Allowlist every Cloudflare IP range at the originPull the current list from cloudflare.com/ips (both IPv4 and IPv6 CIDRs) and allow them in your cloud firewall, security group, iptables, and any WAF/fail2ban rules. Don't allowlist a handful — the ranges change and partial lists cause intermittent 522s. On a host running ufw: `ufw allow from 173.245.48.0/20 to any port 443` for each block, scripted from the published list.
2. Confirm the origin is actually answering on the IP and port Cloudflare usesFrom a machine outside your network: `curl -v --connect-to example.com:443:ORIGIN_IP:443 https://example.com`. If that hangs, the problem is at the origin or in transit, not Cloudflare. Cross-check the IP against the A record in the Cloudflare DNS dashboard — a mismatch after a migration is a frequent culprit.
3. Check origin load and worker limitsLook at `top`/`htop`, and your web server's busy-worker count. For nginx check `worker_connections`; for Apache check MaxRequestWorkers; for PHP-FPM check `pm.max_children` and watch for 'server reached max_children' in the FPM log. A box that's out of workers accepts the TCP connection late or not at all, which reads as a 522.
4. Enable keepalives at the originIn nginx set `keepalive_timeout 75;` (and a `keepalive` directive in any upstream block); in Apache make sure `KeepAlive On`. Disabled keepalives force a fresh handshake per request and make 522s far more likely once traffic ramps.
5. If it's intermittent, capture an MTR before opening a ticketRun `mtr --report --report-cycles 100 ORIGIN_IP` from the origin toward a Cloudflare edge IP and the reverse from a VPS. Packet loss that starts mid-path points at a network/routing issue your host needs to chase; clean MTR plus a confirmed allowlist is what Cloudflare support will ask for.