Understanding HTTP 522
Problem
A site behind Cloudflare intermittently or persistently returns HTTP 522, "Connection timed out," to visitors, even though the origin server appears to be running fine.
Symptoms
- Visitors see Cloudflare's own 522 error page, not anything served by the origin
- The issue may be constant or may only appear under load
- Origin server access logs show no incoming request at all for the timestamps of the failed attempts
Observed
- Cloudflare classifies 522 specifically as being unable to complete a TCP connection to the origin within its timeout window — distinct from 524, which means the connection succeeded but the app didn't respond in time
- Origin web server access logs had zero matching entries for the timestamps of the failed requests in Cloudflare's own logs — if the origin had even accepted the TCP connection, some log entry would typically exist
- The origin's firewall or security group only allowed inbound traffic from a stale or incomplete copy of Cloudflare's published IP ranges, and the origin's TCP listen backlog was undersized relative to traffic spikes
Root cause (working theory)
We believe the most common cause here was the origin firewall not allowing the full, current Cloudflare IP range list, so a fraction of edge-to-origin connection attempts — from ranges not yet added to the allow list — were silently dropped at the network layer before ever reaching the web server process. A secondary contributor we consider likely for the load-correlated cases is TCP backlog exhaustion at the origin during traffic spikes.
Why the obvious fix failed
The instinctive fix is usually to restart or scale the origin web server, assuming it's overloaded or hung. That occasionally helps as a side effect, by clearing a saturated connection backlog, but it doesn't address a firewall rule silently dropping a subset of Cloudflare's edge IPs — so the errors return as soon as traffic shifts toward the blocked ranges again.
Fix
Confirm the origin firewall or security group allows Cloudflare's complete, current published IP range list rather than a hand-copied or outdated subset, and increase the origin's TCP listen backlog if the timing correlates with traffic spikes rather than being constant.
Verify
Cross-reference a sample of Cloudflare Ray IDs and timestamps for 522 responses against the origin's own connection-level logs after the firewall update, confirming the connection attempts now reach the origin. Then watch the 522 rate for the hostname in Cloudflare's traffic analytics over the following 24 to 48 hours.
Takeaway
A 522 means Cloudflare's edge couldn't even establish a TCP connection to your origin, so investigation belongs at the network and firewall layer first — Cloudflare's IP ranges, security groups, and backlog limits — not the application layer. That's also the fastest way to tell it apart from a 524, which means the connection succeeded but the app was too slow to respond.