Why Am I Getting Cloudflare Error 522: Connection Timed Out?

The 522 page is generated at Cloudflare’s edge, not by your application, which is why it appears with a Ray ID and none of your own error handling. That also narrows the problem usefully: the visitor reached Cloudflare without trouble, so whatever is broken sits on the second hop — between Cloudflare and your server. Nothing in your DNS provider, your CDN settings, or the visitor’s network is implicated by an HTTP error 522.

Where a 522 error happens

Cloudflare defines error 522 as timing out while contacting the origin web server, and error 521 as the origin refusing its connections. That difference is the most useful thing on this page. A firewall rule that rejects a packet sends something back, and Cloudflare reports 521; a rule that drops it sends nothing, so Cloudflare keeps retrying until the clock runs out and reports 522. Both are usually the same misconfiguration seen through different firewall policies.

Two deadlines, one error code

The 522 errors Cloudflare returns come from two separate timers on the origin connection, and it is worth knowing which one you hit before you start changing things.

Neither of the 522 limits can be changed; only the 125-second read timeout is configurable, and only on Enterprise zones. The connection limits reference lists all of them together. In practice you can tell the two apart with a stopwatch: a page that fails after roughly twenty seconds never connected at all, while one that hangs for a minute and a half connected and then went quiet — a very different problem, usually load rather than filtering.

The causes, in the order worth checking

Cloudflare’s own list, ordered by how often it turns out to be the answer:

1. Cloudflare IP addresses are blocked or rate limited at the origin — in .htaccess, iptables, or a firewall. Cloudflare calls this the most common cause. Rate limiting deserves its own mention: a rule that permits Cloudflare but throttles it will produce 522s that come and go with traffic, which is far harder to spot than a flat block.
2. The origin is overloaded or offline and drops incoming requests rather than answering them.
3. Keepalives are disabled at the origin. Cloudflare reuses open TCP connections to your server; when the origin refuses to hold them open, connections get reset under load.
4. The address in your DNS record is stale — it no longer matches the IP your hosting provider has provisioned for the server. Worth checking after any migration.
5. Packets are being dropped somewhere between Cloudflare and the origin. This is the residual case, and the one where a traceroute from the origin back to a Cloudflare address is the evidence your host will want.

One nuance on the first item: which port has to be open depends on your encryption mode, because that is what decides whether Cloudflare connects to the origin over HTTP or HTTPS. If you are not sure which one your zone uses, see which Cloudflare SSL/TLS encryption mode you should use.

The 522s that have nothing to do with your firewall

Three documented cases produce a Cloudflare 522 with a perfectly healthy origin, and every generic checklist misses them:

• A Worker on a Custom Domain fetching its own hostname. Per the docs, a fetch from a Worker on a Custom Domain back to that same hostname returns 522. Use a Route, target a different hostname, or enable the global_fetch_strictly_public compatibility flag.
• A Pages project without a custom domain. If a CNAME points at a Pages project that has no custom domain configured for it, the request has nowhere valid to land.
• An Origin Rule pointing at a hostname that will not resolve. Origin Rules override where a request is sent, so a rule aimed at a Worker route whose hostname is an A record on a reserved address such as 192.0.2.0 produces 522 no matter what your real origin is doing.

Narrowing it down

1. Capture the details first. The error code, the exact URL, and the time with timezone are the three things Cloudflare tells you to hand your hosting provider; the Ray ID from the page makes the request findable in logs.
2. Check whether it is everything or some paths. In the dashboard, open HTTP Traffic and add a filter on Edge status code for 522. Error analytics run on a 1% traffic sample, so treat the shape as the signal, not the counts.
3. Allow the ranges rather than checking them. Cloudflare connects from its published IP ranges, and those change over time. An allowlist that was complete two years ago may not be now.
4. Request the origin directly. From a shell, connect to the origin address with the correct Host header. If it answers for you but not for Cloudflare, you are looking at a filter, not an outage — and the fact that it answers you is why an overloaded origin is so often misdiagnosed.
5. Grey-cloud the record briefly. Setting it to DNS only takes Cloudflare off the path: if the site is still unreachable, the origin is the problem. The record exposes your server’s real address while it is grey, so change it back.
6. Look at TCP failures per endpoint. Origin Analytics reports connection failure rates by path, which separates a struggling endpoint from an origin that is unreachable outright.

522 next to its neighbours

The 5xx family Cloudflare generates all describes the same hop, and the codes are easy to mix up:

A rough rule: 520 is a bad answer, 521 is a refusal, 522 is silence, 523 is no route, and 524 is slowness. If you administer more than one zone, the 5xx index is worth a bookmark. And if the error you are actually seeing is a four-digit one, the cause is elsewhere entirely — see error 1000, DNS points to prohibited IP.

FAQ