Error 522: Connection timed out

When you visit a website using CloudFlare, you may receive an error 522. This error occurs because CloudFlare could not connect to the origin web server.

Are you a website visitor?

If you are visiting a website and experience this error, please contact the website owner or webmaster.

Are you the website owner?

A 522 error response is returned when CloudFlare could not establish a TCP connection to the website’s origin server before the request times out. This means that CloudFlare was unable to send the HTTP request to the origin because a network connection to the origin server could not be established.

Common causes for this error response are:

  • Rate limiting incoming connections from CloudFlare's IPs.
  • A process on the webserver is consuming all of one or more resources at the origin.
  • The domain is on a shared hosting platform where traffic or tasks for a separate domain on the same server is taking up one or more resources.
  • Network connectivity issues between CloudFlare and the origin web server.

While the above reasons are the most common, they are not the only reasons why a 522 might be returned when attempting to access your domain.

The TCP Handshake

The timeout limit that triggers a 522 response is 15 seconds. During this time, three TCP SYN packets are sent from CloudFlare’s edge and expects a SYN+ACK back from the origin. If nothing is returned in the response, then a 522 error will occur.

Here is a sample diagram detailing steps for a successful TCP handshake:

Here is an example where the SYN/ACK is not returned from the origin server within 15 seconds, triggering the 522 timeout:

Another condition for the 522 timeout occurs when the origin responds with a SYN+ACK and established a TCP connection, but never responds to the request with an ACK within 90 seconds (A 524 condition ACKs the request, but waits too long to send the response). Here is an illustration detailing this scenario:

Checking for these conditions with your server administrator or hosting provider is the best way to resolve these errors. If there is a network problem, a traceroute or MTR from the site origin can be useful.

If you continue to see 522 errors after ruling out the aforementioned possibilities and troubleshooting the issue, contact CloudFlare Support for further investigation.


When troubleshooting these errors, it is generally good practice to confirm that CloudFlare IPs are whitelisted and not being throttled or blocked by the webserver environment (firewall, load-balancer, net-scaler, etc.), or within the host network (ie router level).

When debugging, One of the most helpful tools in these cases is running an MTR, which is a robust network diagnostic tool that helps to debug and isolate networking issues while providing helpful reports of network status in the route to the specified destination/host.

MTR commands should be run from the website’s origin server to confirm if an issue is occurring in the upstream within a transit provider, ISP, or the host network (between origin and CloudFlare).

When running an MTR from the site’s origin server, the trace should be run against one of the CloudFlare IPs (obtained by running a DNS lookup against the domain -- dig, nslookup, or 3rd party DNS lookup tool) that is assigned to the domain when CloudFlare is enabled on the site:

mtr -rwc 30

The command above will run a report and send 30 packets to each hop in the network path to the CloudFlare IP.

Here is an example MTR output that is showing significant packet loss in the network path to CloudFlare’s edge (showing loss with an upstream provider and timeouts thereafter), which would likely result in a 522 timeout for web requests being proxied to the origin server:

HOST:         Loss% Snt   Last   Avg  Best  Wrst StDev                 0.0% 10     0.5   7.1   0.5  36.1  10.4   10.0% 10     0.3   0.3   0.2   0.3   0.0  80.0% 10     0.3   2.7   0.3  20.3   6.3  50.0% 10    75.7  76.8  74.2  88.0   4.1  40.0% 10    74.2  80.6  74.2 103.4   9.9   10.0% 10    94.0  88.9  81.9  94.7   6.4
???                      0.0% 10     0.0   0.0   0.0   0.0   0.0
???                      0.0% 10     0.0   0.0   0.0   0.0   0.0
???                      0.0% 10     0.0   0.0   0.0   0.0   0.0
???                      0.0% 10     0.0   0.0   0.0   0.0   0.0

In the example above, note the loss percentage seen in the network hops 2-6, and then times out thereafter in the network path. This is a scenario that likely represents the type of packet loss that can cause 522 timeouts or other network related issues to occur.

Impacted users should conduct a CDN trace from their local machine to confirm where they are connecting to within CloudFlare's network. This can be done by going to the /cdn-cgi/trace URL for the site:

*note: replace "" with the domain name experiencing the issue.

Aside from running and requesting MTRs/Traceroutes, running cURL commands (cURL is a command line tool that can be used to send requests using URL syntax) can also be used to confirm origin response and are helpful to obtain further details on the nature of the issue.

In this example, using the ‘time’ command with a cURL can be useful in determining the type of timeout that could be occurring for the request:

time curl -svo /dev/null
* About to connect() to port 80 (#0)
*   Trying
* Connected to ( port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.30.0
> Host:
> Accept: */*
< HTTP/1.1 522 Origin Connection Time-out
* Server cloudflare-nginx is not blacklisted
< Server: cloudflare-nginx
< Date: Mon, 02 Feb 2015 22:16:15 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=d0978ac2b152b4695895bd94ed249f9c21394385360738; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/;; HttpOnly
< Expires: Thu, 01 Jan 1970 00:00:01 GM
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< CF-RAY: 1088eaf894ce0701-SJC
{ [data not shown]
* Connection #0 to host left intact
real 0m15.905s
user 0m0.507s
sys 0m0.009s

From the cURL output, you can see that the request resulted in a 522 timeout due to the request waiting on the TCP connection to be established (as denoted by the time of 15.9 seconds from the time command).

Reference Material

MTR/Traceroute Diagnosis and Usage