Cloudflare Error 522: connection timed out - causes and fixes

What error 522 means

Every proxied request starts with Cloudflare opening a TCP connection to your origin before it can send the HTTP request itself. Error 522 fires when that handshake, the TCP SYN and the expected SYN-ACK back, does not complete within Cloudflare's timeout window. The origin might be too overloaded to accept new connections, a firewall might be silently dropping the packets instead of rejecting them, or the network path between Cloudflare and the origin might be congested.

This differs from error 521, where the origin actively refuses the connection, and from error 524, where the TCP connection succeeds but the HTTP response itself never arrives in time. Error 522 is specifically a failure at the handshake stage, before any HTTP request is even sent.

How error 522 appears

Visitors see Cloudflare's page, "Error 522: connection timed out", with a Ray ID. A curl request against the domain shows the same status after roughly Cloudflare's timeout window:

curl -I https://example.com
HTTP/2 522

Because the TCP handshake never finished, no request reached your application, so application logs are typically empty for the failed period. Look instead at connection-level metrics: server load and CPU at the time of the errors, the number of established and waiting connections (ss -s or netstat -an | grep SYN_RECV), and firewall or load balancer logs for dropped or filtered packets on the relevant port.

What causes error 522

• The origin server is overloaded and cannot accept new connections fast enough. High CPU, a full connection backlog queue, or an exhausted worker pool all produce this.
• A firewall or security group is silently dropping Cloudflare's SYN packets instead of sending a TCP reset. A drop looks identical to a slow or dead server from Cloudflare's side, while a reset would instead produce error 521.
• TCP keepalive is disabled on the origin, which increases connection churn and the odds that a new handshake lands during a moment the server is too busy to accept it.
• The origin's IP address is not correctly allowlisted where the network requires an explicit allowlist rather than a simple firewall rule, so Cloudflare's requests are filtered before they reach the listening socket.
• Network congestion or packet loss between Cloudflare and the origin, more common on origins behind consumer-grade or heavily oversubscribed hosting.

522 vs 524

Both codes are timeouts, but they happen at different points in the request. Error 522 happens before any HTTP request is sent: the TCP handshake itself never completes. Error 524 happens after: the TCP connection succeeds and Cloudflare sends the HTTP request, but the origin does not send back a complete response within 100 seconds. A 524 usually points at a slow application, for example a report generation endpoint, a long database query, or a cron-triggered request that legitimately takes minutes. The fix for a 524 is almost always to speed up the endpoint or move the slow work off the request-response cycle into a background job that the client polls for a result; Cloudflare Enterprise plans can also raise the 100-second limit for specific routes, but that treats the symptom rather than the slow endpoint itself.

How to tell whose fault it is

A 522 almost always originates at or near the origin, since Cloudflare's own network is highly available and rarely the source of a handshake timeout. The useful question is whether the origin is down entirely or just struggling under load from certain regions. The fastest way to check is to run an HTTP check from several locations at once: HostTracker's HTTP check queries the domain from checkpoints in multiple countries and reports each one separately, so a pattern where some locations time out and others succeed points at an overloaded server handling some requests but not all, while a uniform timeout everywhere points at the origin being fully down or a firewall dropping every connection.

How to fix error 522

If you are a visitor

1. Reload after a short wait. A momentary spike in load or a brief network hiccup often clears on its own.
2. Check the site's status page, if it has one, for a known incident.
3. There is nothing to fix on your end. The timeout happens between Cloudflare and the site's own server, not in your browser or your connection to Cloudflare.

If you run the site

1. Check server load and available connection capacity at the time of the failures: CPU, memory, and the web server's configured connection or worker limits (for example nginx's worker_connections).
2. Confirm your firewall or security group allows Cloudflare's published IP ranges on the relevant port, and that it rejects with a reset rather than silently dropping packets, which at least turns a 522 into an easier-to-diagnose 521.
3. Enable TCP keepalive on the origin's web server and any load balancer in front of it, and check the OS-level keepalive settings are not left at defaults that are far longer than the connection actually needs.
4. If your hosting or cloud network requires an explicit IP allowlist separate from the firewall, confirm the origin's IP is on it.
5. Time the raw handshake directly against the origin, bypassing Cloudflare, to see whether the delay is in reaching your server at all:

   curl -v -H "Host: example.com" --connect-timeout 5 https://ORIGIN_IP/

   A connection that hangs here confirms the origin itself is slow to accept connections, not something specific to Cloudflare.
6. For slow individual endpoints rather than a generally overloaded server, move long-running work (reports, exports, batch jobs) out of the request path and into a background job the client polls or gets notified about, and consider a Cloudflare Enterprise timeout increase only as a stopgap for routes you cannot speed up quickly.

How to prevent it

A server that only fails its handshake under peak load will pass every manual check you run yourself, since you are unlikely to test it at the exact moment it is struggling. An HTTP check that runs on a schedule from outside your network catches that failure window even when nobody is watching, and running it from multiple countries shows whether the slowdown is global capacity or a regional network path.

Related errors

• Cloudflare error 520: unknown error - the origin responded, but the response was unusable.
• Cloudflare error 521: web server is down - the origin refused the connection instead of not answering.
• 5xx server errors - the general status code family.
• 502 Bad Gateway - the non-Cloudflare-specific version of an upstream failure.

Frequently asked questions

How long does Cloudflare wait before showing error 522?

Around 15 seconds for the TCP handshake. If the origin has not accepted the connection by then, Cloudflare gives up and returns 522 to the visitor.

Is 522 the same as my server being down?

Not always. It can also mean the server is up but too busy to accept a new connection in time, or that a firewall is dropping the connection attempt without sending a reset.

Why does a firewall drop instead of reject a connection?

Some default firewall or security group configurations silently discard packets that do not match an allow rule instead of sending a TCP reset. That silent drop is what turns what could be a fast, clear 521 into a slower, more ambiguous 522.

Does 522 mean I need to upgrade my server?

Not necessarily. Before scaling up, check whether keepalive is disabled, whether the firewall silently drops Cloudflare's ranges, and whether connection limits in the web server configuration are set lower than the traffic actually requires.

What is the difference between 522 and 524?

522 is a failure to even complete the TCP handshake. 524 is a completed connection where the HTTP response itself takes too long, usually because of slow application logic rather than a network or capacity problem.

Can a single slow database query cause a 522?

Not directly, since 522 happens before any request is sent. A slow query is more likely to produce a 524, where the connection succeeded but the response took too long to arrive.