522 Connection Timed Out

Failed TCP handshakes between Cloudflare and the origin server produce 522 Connection Timed Out. The origin did not return a SYN-ACK within the timeout window.

Table of Contents

Usage

Cloudflare is a content delivery network acting as a reverse proxy between clients and origin servers. The 522 error means Cloudflare attempted a TCP handshake with the origin but received no SYN-ACK within the timeout window (19 seconds).

Common causes include:

  • The origin server is overloaded and unable to accept new connections.
  • A firewall or security group is silently dropping packets from Cloudflare IP addresses instead of rejecting them.
  • Network routing issues between Cloudflare and the origin.
  • The origin's IP address in the Cloudflare DNS settings is incorrect.
  • A Workers script fetches its own custom domain, creating a self-referencing request Cloudflare terminates with a 522.
  • A Pages project's custom domain is misconfigured, so requests never reach a working deployment.
  • An Origin Rule resolves the request to a reserved address such as 100:: or 192.0.2.0, which Cloudflare answers with a 522.

Example

A client sends a request through Cloudflare. The origin server does not respond to the TCP handshake within the timeout period, and Cloudflare returns a 522 error.

Request

GET /products HTTP/1.1
Host: www.example.re
Accept: text/html

Response

HTTP/1.1 522 Connection Timed Out
Date: Mon, 02 Mar 2026 10:25:00 GMT
Content-Type: text/html
Server: cloudflare
CF-RAY: 8a1b2c3d4e5f6-ORD

<html>
<head><title>522 Connection Timed Out</title></head>
<body>
<h1>Error 522</h1>
<p>Connection timed out</p>
</body>
</html>

The two timeouts behind 522

Cloudflare applies two separate limits, and knowing which one expired narrows the cause considerably.

Before the connection exists, Cloudflare waits 19 seconds for a SYN+ACK, retrying at 1, 1, 1, 1, 1, 2, 4, and 8 second intervals. Once the connection is established, Cloudflare waits 90 seconds for acknowledgment of its request.

Neither limit is configurable, on any plan including Enterprise. Raising a timeout at the origin changes nothing, because Cloudflare stops waiting first.

A silent firewall is the usual explanation for the 19-second case. Dropping packets produces no reply at all, so Cloudflare exhausts the retry schedule and reports 522. Refusing the connection outright sends a reset instead, which Cloudflare sees immediately and reports as 521. Reading the codes backwards narrows the search: a 522 points at a rule discarding traffic silently, while 521 points at nothing listening or an active refusal.

Errors appearing from some regions and not others narrow the search further, since the pattern indicates one Cloudflare address range missing from an allowlist rather than a general connectivity failure.

Connection reuse adds a subtler case. Cloudflare holds idle connections to an origin for up to 900 seconds, which depends on the origin keeping them open too. Origin keep-alive defaults sit far below the Cloudflare window, at 75 seconds in nginx and 5 seconds in Apache, so an origin closing a connection Cloudflare still considers usable produces intermittent failures under load rather than a steady outage.

How to fix

Cloudflare retries the TCP handshake with a backoff sequence of 1, 1, 1, 1, 1, 2, 4, and 8 seconds before giving up. The origin must return a SYN-ACK within this window, and acknowledge the resource request within 90 seconds after the connection opens.

Allowlist all Cloudflare IP ranges in iptables, security groups, or the hosting provider's firewall. Silent packet drops (as opposed to TCP RST rejections) are the most common cause of 522 errors. Retrieve the current list from cloudflare.com/ips.

Enable HTTP keepalives on the origin web server. In Apache, set KeepAlive On with a KeepAliveTimeout of at least 60 seconds. In Nginx, set keepalive_timeout 75s;. Cloudflare reuses persistent TCP connections, so disabled keepalives force repeated handshakes, increasing the chance of a timeout.

Confirm the origin IP address in the Cloudflare DNS settings matches the current server. A stale A or AAAA record pointing to an old IP address causes silent connection failures.

Run an MTR or traceroute from the origin to the Cloudflare IP shown in the origin's access log. This identifies routing problems or packet loss between the two networks. If the origin is overloaded, add capacity or reduce connection concurrency so the TCP backlog does not fill up.

Review Origin Analytics in the Cloudflare dashboard to correlate 522 spikes with origin-side errors. The analytics view shows when Cloudflare reached the origin and which responses came back, narrowing the fault window for log review.

For Workers deployments, check the script for fetch calls targeting its own custom domain. Route those requests to a separate hostname or service binding instead. The global_fetch_strictly_public compatibility flag makes such self-requests loop back through Cloudflare's front door, so leaving the flag off keeps same-zone subrequests routed to the origin server. For Pages, confirm the custom domain is attached to the project and its DNS record follows the Pages custom-domain setup.

See also

Last updated: August 17, 2026