How to Troubleshoot and Fix Cloudflare Error 522

cloudflare web-hosting server-errors

Visiting a website only to be stopped by a branded Cloudflare Error 522 "Connection Timed Out" screen is one of the most frustrating downtime scenarios for website owners and system administrators. Unlike standard HTTP errors like 404 Not Found or 500 Internal Server Error that originate directly from your application code, an Error 522 indicates a structural failure in the network handshake between Cloudflare’s global edge proxy and your origin web server. The domain name resolves properly and Cloudflare successfully receives the visitor's request, but your origin infrastructure fails to complete a Transmission Control Protocol (TCP) connection within the required timeout window. Resolving this issue requires diagnosing firewall rules, server capacity, and network configurations.

Understanding the Network Handshake Behind Error 522

When an internet user visits a site protected by Cloudflare, their browser does not connect directly to your hosting server's public IP address. Instead, the browser establishes an encrypted connection with the nearest Cloudflare edge server. That edge server then opens a secondary TCP connection back to your origin host to retrieve web pages, API responses, or static assets.

Establishing this backend connection requires completing the standard three-way TCP handshake:

  1. SYN: Cloudflare’s edge server transmits a synchronization packet to your origin server's public IP on port 80 or 443.
  2. SYN-ACK: Your origin web server acknowledges the request by sending an acknowledgment packet back to Cloudflare.
  3. ACK: Cloudflare confirms receipt, and application data transmission begins.

Cloudflare enforces a strict 15-second timeout threshold for this initial exchange. If your origin server does not complete the SYN-ACK handshake within 15 seconds, Cloudflare considers the origin unreachable, terminates the pending socket request, and displays Error 522 to the end user.

Primary Cause: Host Firewalls Blocking Cloudflare IP Ranges

The single most frequent cause of Error 522 is aggressive firewall filtering on the origin host.

Because Cloudflare aggregates web traffic from millions of distributed end users, requests funnel into your origin server from a compact, centralized list of Cloudflare IP subnets. To standard host security software—such as UFW, iptables, fail2ban, ConfigServer Security & Firewall (CSF), or hosting provider security panels—this heavy concentration of traffic looks identical to an aggressive distributed denial-of-service (DDoS) attack or a malicious port scan.

The host firewall automatically reacts by dropping incoming SYN packets from Cloudflare edge servers. Because packets are silently discarded rather than rejected with a reset flag, Cloudflare’s connection attempts hang until the 15-second timer expires.

To resolve this, you must explicitly whitelist all Cloudflare IP prefixes within your origin server's firewall rules and web server access lists. Cloudflare publishes an official, authoritative list of its IPv4 and IPv6 routing blocks at cloudflare.com/ips. Ensure that automated banning tools like fail2ban ignore these IP ranges entirely to prevent accidental blacklisting during high-traffic spikes.

Secondary Cause: Origin Server Resource Exhaustion

A web server can drop incoming TCP handshakes even when firewall rules are correctly configured if system resources are entirely exhausted.

When an origin server experiences excessive CPU utilization, out-of-memory swapping, or process deadlocks, its network stack becomes sluggish. In web servers like Apache or Nginx, incoming connections wait in an operating system socket queue known as the backlog listen queue.

If all worker processes or PHP-FPM execution pools are occupied processing slow database queries, the kernel's listen queue fills to maximum capacity. Once saturated, Linux kernels silently discard new incoming SYN packets. Cloudflare’s edge server receives no response, triggering an Error 522.

Inspect your server’s health by connecting via SSH and running top, htop, or uptime to evaluate load averages. Check web server error logs (/var/log/nginx/error.log or /var/log/apache2/error.log) for messages regarding worker process starvation or exhausted socket allocations.

Third Cause: HTTP Keep-Alive Configuration Mismatches

Cloudflare relies heavily on persistent TCP connections using the HTTP Keep-Alive header. Maintaining open, reusable TCP connections between edge data centers and your origin server eliminates the latency penalty of negotiating a fresh handshake for every individual asset.

If your origin web server software has Keep-Alive disabled or configures an excessively aggressive timeout window (such as terminating idle connections after only two or three seconds), network race conditions occur. Cloudflare’s edge proxy may attempt to transmit an incoming HTTP request across what it believes to be an established connection just as your origin server unilaterally closes the socket.

To ensure stability, verify your web server configuration files:

  • In Nginx, ensure keepalive_timeout is set to at least 60s or 75s within nginx.conf.
  • In Apache, ensure KeepAlive On is enabled and set KeepAliveTimeout to at least 15 seconds or higher.

Fourth Cause: Outdated DNS Records and IPv6 Routing Errors

If you recently migrated your website to a new hosting provider, rebuilt a virtual private server, or updated network interfaces, an incorrect IP address in Cloudflare DNS will cause immediate connection failures.

Log into your Cloudflare dashboard, open the DNS settings tab, and verify that the A record pointing to your root domain matches the exact public IPv4 address currently assigned to your origin host.

Furthermore, pay close attention to IPv6 configuration. If your Cloudflare DNS table contains an AAAA record pointing to an IPv6 address, Cloudflare will attempt to establish connections over IPv6 first. If your origin web server is not actively bound to listen on [::]:80 and [::]:443, or if your hosting provider’s upstream gateway drops IPv6 traffic, connections fail. If IPv6 is not properly configured on your server, delete the AAAA record from Cloudflare to force reliable IPv4 communication.

Step-by-Step Diagnostic Workflow

When troubleshooting a live Error 522 incident, follow this systematic procedure to isolate the root cause:

  1. Direct Host Testing via cURL: Bypass Cloudflare entirely from your local terminal to verify that your origin server is running and accepting traffic: curl -Iv https://yourdomain.com --resolve yourdomain.com:443:YOUR_ORIGIN_IP If this direct request fails or times out, the problem resides entirely within your origin server or host provider network.

  2. Review Firewall Drop Logs: Inspect system logs using dmesg -T | grep -i drop or review /var/log/ufw.log to determine if Cloudflare IP ranges are triggering rate-limiting rules.
  3. Verify Upstream Cloudflare Whitelisting: If using shared or managed hosting, contact your infrastructure support team to confirm that Cloudflare's edge proxy subnets are globally whitelisted at the datacenter edge.

Summary

Cloudflare Error 522 is fundamentally an origin connectivity issue, indicating that an edge proxy waited 15 seconds for a TCP handshake that never arrived. By whitelisting Cloudflare’s IP blocks across all host firewalls, tuning web server Keep-Alive settings, monitoring server resource utilization, and verifying accurate DNS routing, you can eliminate connection timeouts and maintain reliable website uptime.

← Back to Blog