Cloudflare Error 522: Connection Timed Out, How to Fix

Cloudflare error 522 means Cloudflare tried to reach your origin server and the connection timed out. Unlike a 521, nothing refused the connection: your server simply never answered in time. Cloudflare waits 19 seconds for the TCP handshake to complete, and 90 seconds for a response once the connection is open. Miss either deadline and every visitor gets "Connection timed out" with a 522. The cause is almost always one of five things: a firewall silently dropping Cloudflare's packets, an overloaded server, a DNS record pointing at the wrong IP, keepalives disabled at the origin, or packet loss on the path.

What does Cloudflare error 522 mean?

The error page shows a three-box diagram: browser working, Cloudflare working, host error. Cloudflare is telling you it did its part, resolved where your origin lives, opened a socket toward it, and then waited. And waited. Nothing came back.

The word that matters is "timed out", and it is doing more work than most people realise. A timeout is silence. Your server did not send back a rejection, did not close the connection, did not return an error. From Cloudflare's side the packets went into the void. That single fact rules out a large category of causes and points hard at a much smaller one, because a machine that is up and healthy but genuinely busy behaves very differently from a firewall that is dropping traffic without telling anyone.

What causes Cloudflare error 522?

Cloudflare's own documentation splits the error into two distinct timeout scenarios, and knowing which one you hit narrows the search enormously.

Those retry intervals are worth reading twice. Cloudflare does not give up after one attempt, it sends eight SYN packets across 19 seconds. A server that is merely slow to accept connections will usually catch one of them. If all eight vanish, something is deliberately discarding them, and "deliberately" nearly always means a firewall rule.

In practice those two stages resolve into five real causes.

Cloudflare names the firewall case as the most common by a wide margin, and it is also the one that produces the most confusing symptoms. Your server is up. You can SSH into it. You can curl it from your laptop. Every test you run passes, because every test you run comes from an address the firewall likes. Only Cloudflare's ranges are being dropped, and Cloudflare is the only client whose experience you cannot easily reproduce.

What is the difference between error 521 and error 522?

Refused versus ignored, and it is the single most useful distinction in the whole 5xx family.

A firewall can produce either a 521 or a 522 depending on how the rule is written. A REJECT rule sends back an RST packet, the connection is refused, and you get error 521. A DROP rule discards the packet silently, Cloudflare waits out its 19 seconds, and you get a 522. Same rule, same intent, two different error pages, and the difference tells you whether to look for a rejection or a black hole.

How do I fix Cloudflare error 522?

Work through these in order. Each step eliminates a category instead of guessing at a fix.

1. Prove whether the origin answers at all. From any machine that is not behind Cloudflare, connect straight to the origin IP:

curl -sv --connect-timeout 10 --resolve yourdomain.com:443:YOUR.ORIGIN.IP https://yourdomain.com/

If that returns your site quickly, the server is healthy and you are looking at a block or a wrong DNS record. If it hangs and times out the same way, the origin really is unreachable or saturated, and you can stop thinking about Cloudflare entirely.

2. Check that the DNS record points at the right address. This takes thirty seconds and catches an embarrassing number of 522s. In the Cloudflare dashboard, compare the A record for the affected hostname against the origin's actual public IP. Server rebuilds, provider migrations and floating IP reassignments all change the address without changing the record. A 522 that started at a specific moment with no deploy behind it is very often this.

3. Allow Cloudflare's current IP ranges through every firewall in the path. Cloudflare publishes them at cloudflare.com/ips and the list does change, so a hardcoded copy from an old runbook is itself a cause of this error. There is usually more than one firewall involved: the OS firewall (ufw, firewalld, iptables), the cloud provider's security group, and often a control panel's own protection layer. All of them have to allow the ranges. Check fail2ban too, which will happily ban a Cloudflare address that sent a burst of requests to a URL that 404s.

4. Look at whether the server ran out of capacity. The second timeout stage, the 90 second one, is the fingerprint of an origin that accepted the connection and then could not do anything with it. Check the load average, free memory, and the worker pool limits: PHP-FPM's pm.max_children, the database connection ceiling, and any per-process memory limit. A 522 that only appears at your busiest hour and clears on its own is capacity, not configuration, and no amount of firewall auditing will fix it.

5. Make sure keepalives are enabled at the origin. Cloudflare explicitly lists this. Reusing an established connection for subsequent requests avoids a fresh handshake every time, and a server that closes connections aggressively forces Cloudflare to keep reopening them, which multiplies the chance of hitting the 19 second window under load. In Apache that means KeepAlive On with a sensible KeepAliveTimeout. In nginx it is keepalive_timeout inside the http block, commonly set to 75 seconds. Both are off or unhelpfully low in a surprising number of hardened default configurations.

6. Test the path for packet loss. If the first five come back clean, run an MTR from the origin toward a well-known address and look for loss at intermediate hops. Region-specific 522s that nobody can reproduce are usually a network problem between Cloudflare's edge and your host, and at that point you need the host's network team rather than your own config.

How do I fix Cloudflare error 522 on nginx?

The nginx-specific version of this is short. Confirm nginx is listening on the port your Cloudflare SSL/TLS mode requires (443 for Full and Full strict, 80 for Flexible) with ss -tlnp. Set keepalive_timeout 75; in the http block. Then check worker_connections and the open file limit, because an nginx that has exhausted its connection slots stops accepting new ones and produces exactly this error under load while looking perfectly healthy in systemctl status.

If nginx is fronting PHP-FPM or an application server, the 90 second stage points past nginx and into the backend. A full FPM pool makes nginx queue requests it cannot hand off, and from Cloudflare's side that is indistinguishable from a hung server. The nginx error log will say so plainly, usually with a message about connecting to an upstream socket.

Why do I get Cloudflare error 522 with a VPN?

Because the VPN changes which address your traffic appears to come from, and something in the path treats that address differently. Two versions of this are common. Your origin firewall may allow your home or office IP explicitly, so the site works normally and fails through the VPN exit node. Or the VPN's exit address sits in a range your host's intrusion prevention has flagged, and it is being rate limited or dropped.

The useful diagnostic is simple: if the site loads with the VPN off and 522s with it on, the problem is address-based filtering somewhere, not a broken server. That also means other visitors on similar networks are probably seeing it too, which makes it a real outage rather than a personal one, even though your own dashboards look fine.

Why does error 522 come and go?

Intermittent 522s are the most expensive kind, because they are the easiest to dismiss. Three causes produce them.

Capacity is the first: the error appears when concurrency crosses a threshold and disappears when it drops, so it tracks your traffic curve and looks random if you are not watching load at the same time. Automated bans are the second: fail2ban or a host WAF blocks a Cloudflare address for a fixed period, and the error clears by itself when the ban expires, which makes it look like it fixed itself. Packet loss is the third, and it can be genuinely random.

All three share one property. By the time someone looks, the site is working again, so the incident gets logged as "seems fine now" and nothing changes. The only reliable way to catch them is to have something checking continuously and recording the timestamps, because the pattern in those timestamps is usually what identifies the cause. A 522 that only ever happens between 2pm and 4pm on weekdays is a capacity problem, and you cannot see that shape without the history.

How long does Cloudflare error 522 last?

Until the underlying condition changes. Cloudflare keeps retrying and keeps serving the error page. Firewall and DNS causes never resolve on their own. Capacity ones clear when traffic falls, bans clear when they expire, and packet loss clears when the network route settles. That mix is precisely why "it came back by itself" is not a resolution, and why the same 522 tends to reappear at the worst possible time a week later.

How do I stop error 522 from happening again?

Prevention comes down to four habits. Pull Cloudflare's IP ranges from the published source on a schedule rather than copying them once. Update DNS records as part of any server migration, in the same checklist step that changes the server. Watch the capacity ceiling, not just CPU, because worker pool and connection limits are what actually break first. And enable keepalives, which costs nothing and removes an entire class of intermittent failure.

The habit that matters most, though, is knowing when it happens. Every 522 has a gap between the moment Cloudflare starts timing out and the moment a human finds out, and on most sites that gap is however long it takes for a customer to complain. That gap is expensive in ways that surface much later: search crawlers retrying a 5xx across several days will quietly drop pages, and the damage shows up weeks afterward as an unexplained slide in search rankings that nobody connects to an outage that was fixed in an afternoon.

Closing the gap is what external monitoring is for. A check running against your public URL sees a 522 exactly the way a visitor does, which is the only view that counts here, and it catches the two causes that are invisible from inside your own network: the firewall dropping Cloudflare specifically, and the intermittent ban that clears before anyone looks. Uptime monitoring from six regions with second-region confirmation means a single dropped check does not wake anyone at 3am while a genuine timeout does. Because the capacity flavour of this error is invisible to an HTTP check that only looks at status codes, a TCP port check on 80 and 443 is worth running alongside it: it fails at the handshake stage, which is the same stage Cloudflare fails at, and it tells you the server stopped accepting connections before any page can report it.

It is also worth knowing what a 522 costs you against whatever availability you have promised. A single 20 minute timeout has already blown four months of budget at a 99.99% uptime target, and spent nearly half a month at 99.9%. The uptime calculator converts any percentage into the exact allowance, which is a fast way to see how little room one bad afternoon leaves. If you are choosing a tool to do the watching, the best uptime monitoring tools roundup compares thirteen of them on check interval and alerting, and for the wider family of errors, HTTP status codes for monitoring covers which ones should page someone and which ones should not.

The short answer

Cloudflare error 522 means the connection to your origin timed out, not that it was refused. Cloudflare allows 19 seconds for the TCP handshake and 90 seconds for a response. Check in this order: connect directly to the origin IP to prove whether it answers, confirm the DNS record points at the right address, allow Cloudflare's current IP ranges through every firewall in the path, look at capacity limits and worker pools, and enable keepalives. A firewall DROP rule and an overloaded server look identical from the outside, and one curl straight to the origin separates them in under ten seconds.