Cloudflare error 522 means the connection between Cloudflare and your origin server timed out. Cloudflare tried to open a TCP connection to your server, waited roughly 19 seconds for a handshake that never completed, and gave up. Your visitor reached Cloudflare fine; Cloudflare could not reach you.
Where its sibling 521 is an active refusal, 522 is silence, and the distinction drives the whole diagnosis. Silence between a proxy and an origin comes from a short list: a firewall dropping Cloudflare's packets instead of rejecting them, a server too overloaded to complete handshakes, an origin IP in your Cloudflare DNS that points at the wrong or a dead machine, or a network path between Cloudflare's edge and your host that is genuinely broken. This article decodes the timeout, walks the owner-side checks in the order that finds the cause fastest, and places 522 in the 52x family so the error code itself tells you where on the path to look.
The 19-second rule, and what has to fail
Two timers govern this error, and Cloudflare documents both. The TCP handshake with your origin gets 19 seconds, the sum of Cloudflare's SYN retry backoff of 1, 1, 1, 1, 1, 2, 4, and 8 seconds, and once a connection is established, the origin gets 90 seconds to acknowledge Cloudflare's request; failing either produces a 522. Nineteen seconds is a long time in network terms, thousands of times longer than a healthy handshake, so a 522 is never a near miss. Something consumed the entire window: packets silently discarded by a firewall configured to drop, a server so saturated its kernel cannot accept new connections, or a route that leads nowhere.
The drop-versus-reject distinction is the fingerprint worth memorizing across the whole family. A firewall that rejects produces 521 instantly; a firewall that drops produces 522 nineteen seconds later. Security tooling often defaults to dropping, which means the most common 522 on a healthy server is a well-intentioned rule silently discarding traffic from Cloudflare's IP ranges while every test you run from inside the network sails through.
The owner-side checklist
Verify the origin IP in your Cloudflare DNS. In the Cloudflare dashboard, confirm the proxied record points at your server's current address. After migrations this is the classic cause: Cloudflare faithfully connects to the old IP, where either nothing lives or a stranger's firewall drops the packets.
Audit every firewall for drop rules against Cloudflare's ranges. Allow Cloudflare's published IP ranges through the OS firewall, the cloud security groups, and any provider-level protection, on ports 80 and 443, and look specifically for rate-limiting rules, since Cloudflare concentrates all your visitors into a small set of source IPs that naive rate limiters read as an attack.
Check the server's headroom. A host at the edge of CPU, memory, or connection capacity completes some handshakes and lets others starve, which surfaces as intermittent 522s during traffic peaks. Look at load averages, memory pressure, and the web server's connection and worker limits at the timestamps of the errors.
Test the path from outside. Request the site directly against the origin IP from an external network, using curl with --resolve. Success there, with failure through the proxy, points back at the firewall and IP checks above; failure there too means the origin or its network is genuinely unreachable and your hosting provider joins the investigation.
Enable keepalives and be patient with your host. Origins that aggressively close idle connections can trip the post-handshake side of the timeout under load, so leave HTTP keepalive on at the origin. If everything on your side checks out and 522s persist, the remaining suspect is the network between Cloudflare's edge and your host's data center, which is a support-ticket conversation with evidence attached: timestamps, Ray IDs, and your direct-test results.
Reading 522 against its siblings
The 52x family is a map of the proxy-to-origin path, and reading the codes together is faster than reading any one alone. 521 means the origin answered with a refusal, so the machine is up and the block is explicit. 522 means the origin never answered, so the suspects are drops, overload, and dead addresses. 524, covered in Cloudflare error 524, means the connection and the request both succeeded and the application simply took longer than 120 seconds to respond, moving the blame from the network layer to the application's own speed. If your errors alternate between 521 and 522, suspect a flapping service or a firewall with mixed rules; if 522s shade into 524s as traffic grows, the story is capacity, an origin sliding from slow to unreachable, which is the trajectory described in Odown's guide to website downtime as the slowdown that precedes the outage.
Common mistakes in fixing Cloudflare error 522
Skipping the origin IP check. It feels too simple to be the cause, which is why it survives. Thirty seconds in the DNS tab rules out the single most common post-migration 522.
Concluding the server is fine from an inside test. Requests from the server to itself, or from its own network, never traverse the firewall layer that is dropping Cloudflare. Only an outside test through the proxy counts as evidence.
Fixing one firewall layer of three. As with 521, the OS firewall, the provider's security groups, and hosting-panel protections each get a veto, and the timeout persists until Cloudflare's ranges pass all of them.
Ignoring intermittence as a clue. Random-looking 522s that cluster at traffic peaks are capacity, not configuration. Match error timestamps against load graphs before rewriting firewall rules.
Raising application timeouts to fix a connection timeout. The 19-second window is about the handshake, not your code's speed. Application-side tuning belongs to 524; here it changes nothing.
FAQ
What does Cloudflare error 522 mean in one sentence?
Cloudflare tried to open a connection to your origin server and heard nothing back within its window, roughly 19 seconds for the handshake, so it reported the origin as unreachable.
Is error 522 caused by Cloudflare or by my server?
Almost always by the origin side: a firewall dropping Cloudflare's packets, an overloaded host, or a wrong origin IP. Genuine Cloudflare-to-host network faults happen but are the rare case, pursued after the local checks pass.
Why do I get 522 errors only sometimes?
Intermittent 522s usually mean the origin completes handshakes when it has headroom and starves them when it does not. Check load, memory, and connection limits at the error timestamps; the pattern will match your traffic.
What is the difference between 522 and 524?
522 fails while connecting, before your application ever sees the request. 524 fails while waiting, after the request was delivered, because the application exceeded 120 seconds to respond. One is a network-layer silence; the other is application slowness.
Closing thought
A 522 is nineteen seconds of silence on the last leg to your origin, and the checklist mirrors that: the address Cloudflare dials, the firewalls that might drop it, the headroom to answer, and only then the network between. The drop-versus-reject fingerprint, 522 versus 521, tells you whether you are hunting a silent rule or an explicit one, which is half the diagnosis before you open a terminal.
Timeout errors also arrive with a warning most teams never see: response times that drift upward for hours before the first handshake fails. Odown tracks your response times continuously from 17 locations and alerts on both the slowdown and the eventual failure, so the capacity problem behind most intermittent 522s appears on a chart in your Slack before it appears on a Cloudflare error page in front of your customers.
