Cloudflare Error 522 can appear even when your origin server is running normally. You may still have SSH access, your hosting dashboard may report that the server is healthy and your web server process may show no obvious problems. Despite those signs, visitors trying to open your website through Cloudflare receive a connection timeout.
The reason is that a running server is not necessarily a reachable server. Cloudflare must establish a working network connection to the origin and that connection can fail without the machine shutting down or the application crashing.
The failure may involve a firewall blocking Cloudflare, an outdated origin IP address, a web server that is not accepting external connections or network conditions preventing the server from acknowledging incoming traffic. Identifying which of these is happening matters more than repeatedly restarting an otherwise operational server.
Why Error 522 Happens on a Running Server
Cloudflare communicates with your origin server over a separate connection from the one visitors establish with Cloudflare. When a visitor requests a page that requires origin access, Cloudflare must connect to the configured origin and send the necessary request data.
According to Cloudflare's official documentation, Error 522 occurs under two specific timeout conditions:
TCP connection timeout: Cloudflare does not receive the expected SYN+ACK response within 19 seconds while attempting to establish a TCP connection.
TCP acknowledgment timeout: Cloudflare establishes a connection but does not receive the expected acknowledgment of its request data within 90 seconds.
Neither condition necessarily means the origin application has stopped running. The first points to a failure during connection establishment, while the second indicates that communication stopped progressing after a connection was established.
This distinction also explains why an ordinary server health check can be misleading. A monitoring service may successfully connect to the server from one network while Cloudflare cannot reach the same machine from its own infrastructure.
For example, SSH traffic on port 22 may work normally while the firewall silently drops incoming HTTPS connections on port 443. From an administrator's perspective, the server looks available but Cloudflare cannot complete the connection required to serve the website.
A successful local test therefore proves only that the tested service responded from that particular location. It does not establish that Cloudflare can reach the public web service.
Four Reasons a Running Server Still Times Out
1. The origin firewall is blocking Cloudflare
A firewall can prevent Cloudflare from reaching the origin without affecting the server's other services. This can happen at the operating-system level, through a hosting provider's network firewall or inside a cloud platform's security group.
Cloudflare connects to origin servers using its published IP address ranges. If those addresses are blocked, rate-limited or incorrectly classified as suspicious, Cloudflare may never receive the TCP response needed to establish a connection.
This situation sometimes develops after a website has operated normally for a long period. An automated security tool may begin blocking traffic after detecting an unusual number of connections from an IP address that belongs to Cloudflare.
The server itself remains operational because the firewall handles the restriction before the HTTP request reaches the application. Restarting PHP, Nginx or Apache does not necessarily change that network restriction.
The useful test is whether Cloudflare's actual source addresses can reach the origin, rather than whether an administrator can connect from an unrelated IP address.
Review the hosting firewall, cloud security groups and intrusion prevention rules for blocked or dropped Cloudflare connections. Compare any affected addresses with Cloudflare's current published IP ranges and correct the specific restrictions that prevent legitimate connections.
Avoid disabling every firewall rule simply to restore access. A targeted correction preserves the server's security while addressing the connection failure.
2. Cloudflare Is Using an Outdated Origin IP
Your origin server may be online while Cloudflare attempts to connect to an address that no longer belongs to it.
This commonly happens after a hosting migration, server replacement or public IP address change. The new server operates normally but the relevant Cloudflare DNS record still points toward the previous destination.
Consider a website that originally used 192.0.2.10 and later moved to 192.0.2.20. The replacement server may respond correctly at its new address but Cloudflare will continue targeting the old address until the relevant configuration changes. These IP addresses are reserved examples rather than real hosting destinations.
The same problem can occur when an IPv4 A record is correct but an IPv6 AAAA record contains an outdated destination. Depending on the configured origin route, the incorrect address can direct connection attempts toward a server that does not respond.
To investigate, open Cloudflare → DNS → Records and compare the configured A and AAAA records with the addresses currently assigned by your hosting provider. If the website uses Origin Rules or a load balancer, check those settings because they can change the effective origin destination.
For a self-hosted website whose internet provider frequently changes its public address, BusinessTally's guide to updating Cloudflare DNS automatically when a home IP changes explains how to keep the stored address synchronized.
The important point for Error 522 is to establish whether Cloudflare is connecting to the correct destination before investigating application performance.
3. The web server is not accepting external connections
A web server process can remain active without accepting connections on the public address and port Cloudflare needs.
For example, an application may respond successfully on 127.0.0.1:8080, while the reverse proxy intended to handle external HTTPS traffic on port 443 is unavailable. Local monitoring can report that the application is healthy even though the public entry point is not working.
A listening configuration can also cause the problem. If a service listens only on the loopback interface, applications running on the same machine may reach it while external connections can not use that listener.
This is particularly relevant after changes to Nginx, Apache, reverse proxy configurations, containers or hosting network interfaces. The application may continue running but the public connection path no longer leads to a service accepting the expected traffic.
The correct investigation should therefore examine the actual listening address and port rather than simply checking whether the application process exists.
A connection that is actively refused may produce Cloudflare Error 521. If packets are silently dropped and the connection never completes, the timeout can instead result in Error 522.
4. The server can not handle connections consistently
A server may remain online while temporarily losing the capacity to accept or acknowledge additional connections.
High connection counts, exhausted file descriptors, memory pressure or an overloaded TCP connection queue can interrupt communication even when the web server process has not terminated.
This can explain intermittent Error 522 responses. The website may work normally during quiet periods but begin timing out when incoming connection volume increases.
A useful distinction is whether the failure consistently affects every connection or appears mainly under load. If errors increase during traffic spikes, connection capacity deserves closer examination than a DNS record that has remained unchanged.
There is another possibility when ordinary resource usage appears healthy. Packets can be dropped somewhere between Cloudflare and the origin because of hosting infrastructure, network filtering or routing problems.
In that situation, the origin may respond normally to local requests and connections from some external networks. However, Cloudflare may still fail to receive the response required to complete its connection.
Cloudflare also identifies disabled origin keepalives as a possible contributor to Error 522. When address configuration, firewall permissions and server capacity appear correct, the origin's connection-handling behaviour deserves investigation.
How to Identify the Actual Connection Failure
The most reliable approach is to examine the connection in the order it must succeed. First confirm that Cloudflare has the correct destination, then verify that the destination accepts public connections and finally determine whether Cloudflare's own traffic reaches the origin.
Verify the public listener before restarting anything
If you administer a Linux server, inspect its listening ports using:
sudo ss -lntp | grep -E ':(80|443)\b'
The output identifies processes listening on the usual HTTP and HTTPS ports. It also helps distinguish a service bound to a loopback address from one configured to accept connections on an external interface.
For example, a listener bound only to 127.0.0.1:443 can not directly accept connections arriving at the server's public IP address. A listener bound to 0.0.0.0:443 generally accepts IPv4 connections through available interfaces, although firewall rules and other network restrictions can still prevent access.
If the expected listener is missing, inspect the relevant web server or reverse proxy configuration. If the listener exists, continue investigating external accessibility rather than assuming the connection must work.
Test the origin without changing Cloudflare DNS
You can send a request directly to your origin while preserving the website hostname. This makes it possible to test the destination without turning off Cloudflare proxying for actual visitors.
From another machine outside the origin network, run:
curl -v --connect-timeout 5 \
--max-time 15 \
--resolve example.com:443:203.0.113.10 \
https://example.com/ -o /dev/null
Replace example.com with your hostname and 203.0.113.10 with your origin's actual public address. The command directs the request toward that origin while retaining the hostname used for HTTPS.
Pay attention to where the request fails. If the TCP connection times out before it can be established, investigate the public listener, firewall and network path. If the connection succeeds and the request produces an HTTP response, the origin is reachable from that testing location.
An SSL certificate verification error requires separate interpretation. For example, a Cloudflare Origin CA certificate may not be trusted by a normal external client, even though the underlying TCP connection succeeds.
A successful direct-origin test does not completely eliminate the possibility of Error 522. Your testing machine and Cloudflare use different source addresses, so the origin firewall or network provider may treat their connections differently.
The test is useful because it narrows the problem. If direct-origin connectivity succeeds but Cloudflare continues timing out, investigate restrictions or network conditions specifically affecting Cloudflare's traffic.
Compare Cloudflare failures with server-side evidence
When the origin IP and public listener are correct, examine what happens to connection attempts from Cloudflare.
Cloudflare's Origin Analytics can help identify TCP connection failures when the feature is available for your zone. Compare the failure period with hosting firewall events, server resource measurements and any network-related warnings.
Ordinary web server access logs may contain no entries for failed connection attempts. That is expected when the TCP connection fails before Cloudflare can deliver an HTTP request to the application.
A network-level investigation can provide more useful evidence because it examines whether the connection packets reach the origin at all.
For an administrator with permission to inspect the server's network traffic, a targeted packet capture during an actual failure can help distinguish three situations.
| Network observation | What it suggests |
|---|---|
| Cloudflare's SYN packets do not reach the origin interface | Upstream filtering, routing or an incorrect destination may prevent delivery. |
| SYN packets arrive but the server does not send SYN+ACK responses | Local firewall restrictions, listener problems or connection-capacity issues deserve investigation. |
| SYN+ACK responses leave the server but Cloudflare still can not establish the connection | Return-path packet loss or filtering may be affecting the exchange. |
These observations are diagnostic clues rather than automatic proof of a single cause. A packet capture must cover the relevant network interface and connection attempt and the complete traffic path may require help from the hosting provider.
The distinction is valuable because it separates failures occurring before the server receives a connection from failures caused by the server's own response behaviour.
Determine whether the problem follows traffic load
If Error 522 appears intermittently, compare the timing of failures with connection-related server measurements.
Look for increases in active connections, exhausted file descriptors, unusually high memory usage, dropped packets or warnings that the listening service cannot accept additional connections. A recurring relationship between these events and 522 responses provides evidence of connection-capacity problems.
For example, suppose the website handles ordinary traffic successfully but starts returning occasional 522 errors during sharp increases in incoming connections. If connection counts reach their configured limits at the same time, the evidence supports a capacity investigation.
Now consider the opposite situation. If the server has substantial unused resources but only connections from certain Cloudflare addresses fail, increasing application capacity is unlikely to address the underlying restriction.
This comparison helps avoid changing settings based solely on the presence of a timeout. The timing and location of the failed connection should determine which configuration needs attention.
Fix the Failed Cloudflare Connection
If the origin IP is outdated, update the relevant Cloudflare record or routing configuration. If a firewall drops Cloudflare traffic, correct the blocking rule while keeping unrelated restrictions in place.
If the web server is bound to the wrong interface, restore the intended public listener or reverse proxy configuration. If connection-capacity limits cause failures under load, examine the exhausted resource and adjust the relevant configuration or infrastructure based on measured demand.
For suspected network packet loss, collect the affected connection times, Cloudflare Ray IDs, and relevant server-side observations. Share that evidence with your hosting provider so it can investigate network filtering or routing outside your direct control.
Repeatedly restarting a healthy application is not a reliable substitute for any of these corrections. A restart may temporarily clear accumulated connections or release resources, but it cannot repair an outdated destination or an upstream network restriction.
Cloudflare's published TCP connection and acknowledgment timeout limits are also not ordinary settings that website owners can increase. The practical fix is to restore reliable communication between Cloudflare and the origin rather than attempting to extend the time available for a failed connection.
Verify that the same connection failure no longer occurs
After correcting the suspected cause, test the website through its normal Cloudflare-proxied hostname. Confirm that Cloudflare can reach the origin and that the website returns its expected response.
For an intermittent issue, a single successful request is not sufficient verification. Compare the results with the circumstances that previously caused the error, including traffic levels, affected Cloudflare locations or specific firewall events.
If the failure previously occurred during busy periods, confirm that the website continues accepting connections under comparable demand. If Cloudflare addresses were blocked, check that those connections now succeed without removing unnecessary security restrictions.
A running origin server becomes a reliable origin only when Cloudflare can consistently complete the required connection. That is the central difference between confirming server uptime and actually resolving Error 522.
