Error 522: Connection Timed Out and Whose Fault It Is

Error 522 is an edge server reporting that it could not get a usable connection to the origin. Everything else follows from that one sentence.

A site behind a CDN is served by two machines, not one. The edge, a reverse proxy in front of the site, accepts your request, then opens its own connection to the origin, the server that actually holds the website. When that second connection never becomes usable, the edge has nothing to relay, so it writes an error page itself and returns 522. Cloudflare's own definition is shorter: the error occurs when Cloudflare times out contacting the origin web server.

The detail most other pages gloss over is authorship. The origin did not send this error, and in most 522s it never saw your request at all. That is why a site's access logs can be empty during an outage its visitors are watching in real time, and why "nothing in the logs" is a clue rather than a mystery. In the recorded lab behind this article, with the origin stopped, the edge answered 522 by itself and the visitor received nothing the origin had written, because it had written nothing.

The recorded run, exactly as the lab printed it:

$ node verify-edge-refusal-lab.mjs   # Node v24.14.0
PASS  healthy origin → 200 through the edge  (status=200)
PASS  origin down → edge answers 522 (the visitor never sees an origin error)  (status=522)
PASS  origin accepts then stalls → 522 at the edge deadline  (status=522 after 1015ms)
PASS  access rule matched → 1020-style refusal produced at the edge  (status=403)
PASS  1020-style refusal carries no Retry-After (unlike 1015)  (Retry-After absent)
PASS  criterion satisfied → 200 (the rule, not the visitor, is the variable)  (status=200)
PASS  522 is visitor-independent (same result with the rule satisfied)  (status=522)

checks passed: 7/7

Two things follow. A site's custom error pages cannot appear during a 522, because the application is not in the conversation, and no edge setting repairs it either. One cleanup: 522 is a vendor number, not a standard HTTP status, so a "522" in a spreadsheet or a reader app is an unrelated product reusing three digits.

The short answer has two halves: if you are visiting, almost never; if you run the site, almost always.

If you are a visitor, there is nothing on your machine to fix. A 522 is decided between the edge and the origin, on a connection your device is not part of. The lab makes that mechanical rather than merely reassuring: the failing request was repeated with the visitor's headers changed, and the answer was the same 522. No cookie, address, or browser version takes part in the hop that broke.

If you run the site, then yes, and Cloudflare's documented cause list sits entirely on the origin side. The useful version is more precise than "statistically the origin". Here "the origin" means everything between the edge and your application, and the failure is more often a firewall, a security appliance, or a load balancer in front of the web server than the web server itself. The gap between a healthy server and a reachable server is where most debugging time on this error is lost.

If you are calling the site from code, it is not your client either. A 522 is upstream unavailability, not a rejection of your request, so no header or credential you send changes it.

The honest list is short. Wait a minute and reload once, then come back in ten minutes, because most 522s accompany an outage somebody is already being paged about. If it persists, report it to the site and quote the reference identifier printed on the error page, which lets support find that exact request.

What does not work, roughly in the order the internet recommends it: clearing the cache, flushing DNS, changing resolvers, disabling extensions, reinstalling the browser, and switching a VPN on. Every one of those acts on the connection between you and the edge, and that connection demonstrably worked. You are reading an error page the edge delivered to you.

That also answers the question people ask next, which is how to get around it. There is nothing to get around. A 522 is not a refusal aimed at you, it is a report that two other machines could not reach each other, and no change on your side puts them back in contact. Changing networks, exits, or identities does not make an unreachable origin reachable.

If you are calling the site from code, treat 522 as transient upstream unavailability and retry with capped exponential backoff and jitter, never a tight loop that piles load onto an origin the moment it recovers. If the browser hangs and never shows a page at all, that is a different failure, and the connection timeout guide covers it.

One number covers two mechanically different failures, and they take different fixes, so separate them before changing anything.

In the first shape no connection ever forms: the edge sent a connection request and heard nothing back. Cloudflare's documented threshold is no SYN+ACK returned within 19 seconds. That figure is the one number the rest of the internet quotes, and it is half the mechanism. The second shape is the other half: the connection is established and then stops being usable, with a documented window of 90 seconds for the origin to acknowledge the request. Something at the origin is alive and accepting, but the exchange never finishes, which is why the server looks healthy from its own console while every visitor sees an error.

The lab reproduces both on loopback against a deliberately short connect deadline of 1000 milliseconds. With the origin stopped, the edge answered 522. With an origin that accepted the TCP connection and then never completed the exchange, the edge still answered 522, but only once its own deadline expired: 1015 milliseconds on the recorded run, just past the 1000-millisecond deadline. That lag is the finding: the error is timed to the edge's deadline rather than to anything the origin said, because the origin said nothing.

Two corrections, because both send owners to the wrong layer. A slow application is usually not a 522: an origin that accepts the connection and does eventually answer, only too late, produces Cloudflare's 524, listed as "a timeout occurred" in its 5xx error index, so tuning a slow page will not clear a 522. And an origin that actively refuses the edge is not a 522 either, because refusal is 521, "web server is down" in the same index. At the TCP layer a rule that rejects sends a reset while a rule that drops sends nothing, the distinction the connection refused guide works through. A reject produces 521. A drop produces 522. The number already tells you whether anything answered.

The origin firewall is dropping the CDN's addresses. Cloudflare names allowing all of its IP ranges as the most common cause. It happens without anyone editing a rule: once a site sits behind an edge, all its traffic arrives from a small set of addresses, so a security plugin or cloud security group sees thousands of requests per address and reacts as designed. Dropping rather than rejecting is why the symptom is a timeout. The scoped fix is to permit the ranges published on Cloudflare's IP ranges page, which calls itself the definitive source. Do not switch origin security off to make the error disappear, because that trades an outage for an exposure.

The origin is unreachable or the web server is stopped. Powered off, mid-reboot, or behind a broken route. Apply the discriminator above: if the host is up and only the web server process died, the kernel usually answers with a reset and visitors see 521, so a clean 522 points at the network layer rather than the process.

The origin is overloaded and its accept queue never drains. The process is up, the port is open, connections are accepted, and the exchange never finishes inside the edge's window. Almost nobody names this one, because from outside it is indistinguishable from a firewall drop while from inside the server looks fine. What proves it: an accept queue sitting at its limit, load matching the minute of failure, and intermittent rather than total failures. The fix is capacity.

Keepalives are disabled at the origin. The edge reuses connections, and an origin that closes every one forces a fresh handshake for every object. Cloudflare lists this explicitly, and it is the classic intermittent 522 nobody can reproduce, because it only fails under real traffic.

The origin address is stale. Cloudflare lists an origin address that no longer matches the provisioned one, the classic leftover from a migration: a DNS record aimed at a machine that stopped serving the site, or a load balancer pointed at a dead backend.

Resource exhaustion below the web server. Worker pool saturation, file descriptor limits, ephemeral port exhaustion, or a full disk, any of which stops new sockets being created while the service looks alive. These track traffic peaks and clear on their own, which is why they get misfiled as CDN flakiness.

Every cause above is selected by an observation. Three checks, in this order, pick one.

First, ask your origin the question the edge is asking, with the edge out of the path. Pin the hostname to the origin address so virtual hosting and TLS still behave, using the --resolve option from the curl manual:

curl -sS --resolve www.example.com:443:203.0.113.10 \
  -o /dev/null -w 'code=%{http_code} connect=%{time_connect}\n' \
  https://www.example.com/

Read the connect time, not only the status. An instant refusal means nothing is listening on that port, the 521 shape. A hang that ends in curl's own timeout means packets are being discarded silently: a firewall, a security group, or a full accept queue. A fast connect means the origin is healthy from where you stand. Run it from the origin and from a machine outside your network: a local success with an outside hang isolates the path in one contrast.

Second, check whether the origin logged the failing request at all. This is the check that decides everything and the one most guides skip, because it produces nothing worth a screenshot. No line in the access log means the request never arrived, and every application level theory dies at once: not the framework, not the database, not a slow query. Absence of a log line is evidence, not missing evidence.

Third, read the firewall's counters rather than its configuration. A rule listing shows what somebody intended; counters show what is being discarded now. On Linux, iptables -L -n -v and nft list ruleset print per-rule packet counts, and a managed host can tell you what their protection did. Look for drops from the CDN's published ranges timestamped to the outage. ss -ltn reports the accept queue depth and its limit per listening socket, which catches the overload case that looks like a firewall from outside. One warning on the way past: pausing the CDN publishes your origin address, so it is a diagnostic rather than a resting state.

These five arrive from roughly the same place and mean entirely different things. Reading the number correctly keeps you from fixing the wrong layer.

The pair that genuinely confuses people is 522 and 1020, because both arrive as a full page error branded by the same network. One tell settles it: a 1020 is about you specifically, so a colleague on another network loads the page normally, while a 522 refuses everyone identically. The lab separated the two on one edge: with the access rule's criterion satisfied the gated path returned 200, while the dead origin path still returned 522 for that same request, and the refusal carried no Retry-After, because time is not the remedy for a policy decision. That is a diagnostic distinction and not an instruction: a rule that deliberately refused you is the site's decision, and the way forward is its administrator.