Fix Cloudflare Error 522: 19s Timeout & Server Fixes

How To Fix Cloudflare Error 522

Key Takeaways:

• Error 522 is a server-side timeout issue between Cloudflare and your origin server—Cloudflare itself is rarely the cause
• The TCP handshake must complete within 15 seconds; if your server doesn’t respond, visitors see “Connection timed out”
• Server overload is the most common culprit—check CPU, RAM, and concurrent connections first
• Firewall rules often block Cloudflare IP ranges unintentionally—whitelisting them resolves many cases
• DNS misconfiguration (wrong A record) sends Cloudflare requests to the wrong destination

What Is Cloudflare Error 522?

Error 522, commonly displayed as “Connection timed out,” is an HTTP status code specific to Cloudflare-powered websites. It occurs when Cloudflare’s edge network attempts to establish a TCP connection with your origin server, but the server fails to respond within the timeout window—typically 15 seconds .

Unlike errors where the connection is actively rejected (like Error 521), Error 522 means Cloudflare sent the initial handshake request and simply… waited. No response arrived. The connection never moved past the front door .

Important: Cloudflare itself is rarely the culprit here. The problem almost always lives on your side of the connection—your server, your firewall, or your DNS configuration . Even if you’re using Cloudflare’s free plan, this error can still appear.

For technical accuracy, Cloudflare’s official documentation now specifies **two distinct timeout windows** that produce a 522: **19 seconds** for the SYN+ACK during TCP connection setup, and **90 seconds** for the ACK after a connection is established but before the HTTP request is acknowledged. Many guides still cite “15 seconds” as a shorthand because Cloudflare’s front-end error page has historically described the threshold that way, but the underlying retry backoff and acknowledgment windows are **19s and 90s**. If you are troubleshooting a persistent 522, work with these exact figures when you speak to your hosting provider .

How Error 522 Works: The TCP Handshake Failure

To understand Error 522, you need to understand the TCP three-way handshake that happens before any website content loads :

1. SYN: Cloudflare sends three SYN packets to your origin server requesting a connection
2. SYN+ACK: Your server should reply with a SYN+ACK acknowledgment
3. ACK: Cloudflare sends a final ACK back, and communication begins

If your origin server doesn’t send that SYN+ACK back within 15 seconds, Error 522 triggers and the connection closes. No data is exchanged, no headers are read—the visitor just sees a timeout .

Cloudflare’s SYN retry pattern follows **1, 1, 1, 1, 1, 2, 4, and 8 second intervals**. The cumulative effect is that the connection attempt can stretch beyond a single fixed number before the edge gives up. The **90-second request acknowledgment window** applies only after the TCP connection is established—for example, if the server accepts the handshake but never acknowledges Cloudflare’s HTTP request. This distinction matters because a 522 before connection points to networking/firewall issues, while a 522 after connection points to application or server-resource issues .

What Causes Cloudflare Error 522?

Several conditions can break that TCP handshake. Here are the most common causes, ranked by frequency:

Notice the pattern? The problem sits on your origin server’s side almost every time—not Cloudflare, not the visitor’s browser .

Two additional causes are specific to **Cloudflare-native platforms** and are worth checking if you use Pages, Workers, or Origin Rules. If you are on **Cloudflare Pages**, a 522 can appear when your **custom domain’s CNAME record is not pointed to the correct `*.pages.dev` target**. If you are using **Workers with a Custom Domain**, performing a `fetch` to the Worker’s own hostname will return a 522; the fix is to use a **Route** instead, target another hostname, or enable the `global_fetch_strictly_public` compatibility flag. If you use **Origin Rules**, verify that the resulting hostname resolves—an Origin Rule pointing to a Worker route with an A record on a reserved address such as `100::` or `192.0.2.0` will return a 522 .

3 Different Ways to Fix Cloudflare Error 522

Before diving in, run a quick sanity check. Use a tool like Uptrends or check Downdetector to confirm your site is actually down for everyone, not just you. Then verify Cloudflare’s own status page (cloudflarestatus.com) isn’t reporting an incident .

You can also check **Cloudflare Origin Analytics**. A high **TCP failure rate** on specific Top endpoints suggests a path-specific fault rather than a dead server. If only your visitors see 522 but external probes load the site, the issue may be regional routing or a proxy cohort problem rather than a full outage .

Method 1: Check If Your Web Server Is Working

This is where most Error 522 problems live. Your origin server is either offline or too overloaded to accept new connections .

Step 1: Test Basic Connectivity

SSH into another machine (or use your local terminal) and ping your server’s IP directly:

ping 203.0.113.50

If you get no response, the server is unreachable. Try a traceroute to see where packets die:

traceroute 203.0.113.50

For Cloudflare support tickets, an **MTR (My Traceroute)** is often more useful than a plain traceroute because it continuously combines ping and traceroute data and shows packet loss at each hop. Run an MTR from your origin server to a Cloudflare IP address before contacting support:

mtr --report --report-cycles 10 198.41.128.1

Use a Cloudflare IP that appears in your origin server logs as the most frequent connecting address. Cloudflare support specifically requests an MTR or traceroute from the origin to a Cloudflare IP, along with the Ray ID from the 522 error page, when diagnosing a case .

Step 2: Check Resource Usage

If the server responds to ping, log in and check these metrics :

• CPU usage: Keep it under 80%. Above that, request queuing starts and timeouts follow
• RAM usage: If you’re swapping to disk, everything slows down
• Running processes: Look for runaway scripts, zombie processes, or cron jobs stacking up
• I/O throughput: Disk saturation kills performance as fast as CPU
• Max concurrent connections: Check if you’re hitting hosting plan limits

On Linux, use top or htop commands. Hostinger users can find this in hPanel under Websites → Dashboard → Hosting Plan → Used Resources .

Step 3: Fix Resource Issues

If you’re hitting resource limits :

• Remove unnecessary plugins that hog resources
• Optimize slow database queries (check MySQL slow query log)
• Implement caching to reduce load for repeated requests
• Upgrade your hosting plan—shared hosting may no longer be sufficient

View Cloudflare Official IP Ranges

Method 2: Review Cloudflare DNS Settings

When you onboard a domain to Cloudflare, it imports your DNS records. The A record is critical—it maps your domain to your server’s IP address. If this is wrong, Cloudflare sends requests into a void .

Step 1: Find Your Server’s Actual IP

Your hosting control panel shows this under plan details, server information, or similar. Copy it exactly.

Step 2: Check Cloudflare DNS

1. Log into your Cloudflare dashboard and select the domain
2. Go to DNS > Records
3. Find the A record for your root domain (e.g., example.com)
4. Compare the Content/Value field against the IP from your hosting panel

If they don’t match, click Edit, paste the correct IP, and save. DNS changes can take up to 24 hours to propagate, though it’s usually faster. You can also purge Cloudflare’s cache to speed things along .

A quick way to confirm the mismatch is to query your origin IP directly with a `curl` command that bypasses the proxy:

curl -I --resolve example.com:443:203.0.113.50 https://example.com

If the origin responds to this `–resolve` request but Cloudflare still shows 522, the problem is in the Cloudflare-to-origin path (firewall, routing, or Cloudflare-side configuration) rather than DNS itself. If the origin does not respond to `–resolve`, the server is likely offline or overloaded—go back to Method 1 .

Step 3: Check SSL/TLS Settings

While in the dashboard, confirm your SSL/TLS encryption mode is set to Full or Full Strict. A mismatch between “Flexible” mode and a server expecting HTTPS causes different problems .

An **expired, invalid, or revoked SSL certificate** on the origin server can also contribute to 522 in Full Strict mode, because Cloudflare will not complete the connection to an untrusted origin. If you recently installed or renewed a certificate and 522 appeared afterward, verify that the certificate chain is complete and that the certificate covers the hostname Cloudflare is connecting to. Tools like `openssl s_client` can confirm what the origin is serving:

openssl s_client -connect 203.0.113.50:443 -servername example.com

Method 3: Check Server Configuration & Firewall Rules

Server is online, DNS is correct—and you’re still getting Error 522? Time to dig into configuration .

Step 1: Enable KeepAlive

Cloudflare relies on HTTP KeepAlive headers to maintain persistent connections. If your server closes connections after every request, reconnection overhead stacks up .

On Apache, add this to your .htaccess file:

<ifModule mod_headers.c>
   Header set Connection keep-alive
</ifModule>

On Nginx, ensure keepalive_timeout is set to something reasonable (65 seconds is the default) .

Step 2: Whitelist Cloudflare IP Addresses

If your firewall or security module blocks Cloudflare’s IP ranges, every visitor gets a 522. Cloudflare publishes its full IP list at cloudflare.com/ips . You need to whitelist all of them.

How to whitelist depends on your setup :

• iptables/nftables: Add allow rules for each Cloudflare range
• Server control panel: Use IP manager or firewall section
• .htaccess: Add “allow from” directives for each range
• Security plugins (WordFence, Sucuri): Check firewall settings and add Cloudflare IPs to whitelist
• CSF firewall: Add Cloudflare IPs to /etc/csf/csf.allow

For iptables, a loop over the published ranges is more reliable than manually typing each one:

for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
  iptables -I INPUT -s $ip -j ACCEPT
done

For CSF, you can append ranges to `/etc/csf/csf.allow` and then reload:

csf -r

For `.htaccess`, a minimal allow-list pattern looks like this:

Require ip 173.245.48.0/20
Require ip 103.21.244.0/22
Require ip 103.22.200.0/22

Always verify the current ranges at `cloudflare.com/ips-v4` and `cloudflare.com/ips-v6` before applying, because Cloudflare occasionally adds new ranges. After adding the rules, test with `curl` from a machine that is **not** behind Cloudflare to confirm direct origin access is still working for your own IP while Cloudflare ranges are allowed.
Hostinger users can add Cloudflare IPs via hPanel → Websites → Advanced → IP Manager .

Step 3: Check Hosting Provider Restrictions

Some hosting companies filter Cloudflare addresses at the network level, not your server. If you’ve whitelisted everything and still get 522, contact your provider and ask them to explicitly allow Cloudflare IP ranges .

Step 4: Temporarily Pause Cloudflare

Still stuck? Pause Cloudflare temporarily from the dashboard. This routes traffic directly to your server, bypassing the proxy entirely .

• If the site works with Cloudflare paused → Problem is in the connection between Cloudflare and your origin. Re-check firewall rules and IP whitelist
• If the site is still down with Cloudflare paused → Problem is on your server. Go back to Method 1 and look harder at resource usage and server health

An alternative to fully pausing is to switch the affected DNS record from **Proxied (orange cloud)** to **DNS Only (grey cloud)**. This keeps your DNS in Cloudflare but bypasses the proxy for that hostname. If the site loads with DNS Only, the origin is reachable and the issue is in the Cloudflare proxy-to-origin path. Switch it back to Proxied only after you have fixed the firewall or routing problem, then monitor for recurrence .

Step 5: Consider Cloudflare “Under Attack Mode”

If the 522 is caused by a **DDoS attack or a traffic flood** overwhelming your origin, Cloudflare’s **”I’m Under Attack” mode** can present a challenge page to suspicious visitors and reduce the load on your server. Enable it temporarily from the Cloudflare dashboard under **Security > Settings**. This is a mitigation, not a fix: the underlying cause may still be insufficient origin capacity, but Under Attack Mode can keep the site reachable while you scale resources or block malicious traffic. Do not leave it on permanently for a normal content site, because the interstitial challenge adds friction for every visitor .

Troubleshooting Other Cloudflare Errors

Error 522 isn’t the only Cloudflare 5xx code you’ll encounter. Here’s how its close relatives differ :

What Can Browser Users Do About Error 522?

If you encounter Error 522 while browsing, here’s the reality: HTTP 522 indicates a server-side problem, not an issue with your internet connection or browser plugins .

Your best option is to wait and try again later. The site owner is likely already working on the issue, and it may resolve within minutes or hours .

If the problem persists for days, you can try:

• Contacting the website owner or webmaster directly
• Checking the site on social media to see if others report the same issue
• Using a different network or connection (sometimes routing issues are localized)

But honestly? Most of the time, the fix requires server access you don’t have. Patience is your friend .

When you contact the site owner, include the **Ray ID** shown on the 522 error page. The Ray ID is a unique identifier for that specific request and lets Cloudflare support or the hosting provider trace exactly which edge node attempted the connection and what happened. Without the Ray ID, diagnosis takes longer because the provider has to search logs by timestamp and IP instead of a precise request identifier .

How to Verify Error 522 Is Fixed

The simplest test: open your site in a browser. If it loads without the “Connection timed out” message, you’re likely in the clear .

But don’t stop there:

1. Clear your browser cache or use an incognito window. Cached DNS or stale content can give false positives
2. Test from an external tool like Uptrends or GTmetrix to verify accessibility from multiple geographic locations
3. Check server resources again—ensure CPU/RAM aren’t redlining
4. Verify Cloudflare IPs remain whitelisted (some configurations reset after updates)

If everything loads cleanly and monitoring looks good, the error is resolved. Keep an eye on your logs for the next few hours to ensure it doesn’t return .

Preventing Error 522 Long-Term

Fixing Error 522 once is straightforward. Keeping it from coming back requires discipline :

• Monitor regularly: Use server monitoring tools to track CPU, RAM, and connection metrics. Set alerts for thresholds
• Optimize continuously: Slow database queries, unoptimized images, and bloated plugins accumulate over time. Regular audits prevent overload
• Plan for traffic spikes: If you run promotions or expect viral traffic, ensure your hosting can scale. Consider load balancing or CDN enhancements
• Keep DNS records updated: Every server migration or IP change must be immediately reflected in Cloudflare DNS
• Document your Cloudflare IP whitelist: Make sure any server rebuilds or firewall changes include re-whitelisting these ranges

For high-traffic sites, consider implementing load balancing to distribute traffic across multiple servers. This prevents any single server from becoming overwhelmed .

There is also an **SEO cost** to recurring 522 errors that is easy to overlook. When Cloudflare returns 522 to search engine crawlers, those crawls fail and the affected URLs may be treated as temporarily unavailable. If the pattern repeats over days or weeks, crawl budget is wasted on retries, indexing can be delayed, and rankings for the affected pages may slip. Google treats 5xx errors as server-side issues and will retry later, but persistent 5xx responses are not ignored indefinitely. Use **Google Search Console’s Crawl Stats** report to check whether 522 responses appear in the “Crawl responses” breakdown, and fix the origin before the pattern becomes a ranking problem. This is one more reason to treat 522 as a reliability issue, not just a one-off nuisance .

When to Contact Cloudflare Support

If you’ve tried everything and still see Error 522, it may be time to contact Cloudflare Support .

Before reaching out:

• Check Cloudflare’s status page to rule out their own incidents
• Run an MTR or traceroute from your server to a Cloudflare IP address
• Document everything you’ve checked and tried

Provide these logs when opening a ticket—it dramatically speeds up diagnosis .

You can also read about Cloudflare 521 error here for related issues.

Cloudflare’s support team specifically requests the following when a 522 case is escalated: the **Ray ID** from the error page, the **URL** that produced the 522, the **time and timezone** of the failure, an **MTR or traceroute from the origin to a Cloudflare IP**, and confirmation of **whether the origin is reachable directly** (for example, via `curl –resolve`). Having these ready before you open the ticket avoids a round of back-and-forth and lets support reproduce the exact path that failed .

FAQ: Cloudflare Error 522

Conclusion: Error 522 Is Fixable

Cloudflare Error 522 looks intimidating, but it follows predictable patterns with straightforward solutions. When you see “Connection timed out,” remember:

The problem is almost always your server, not Cloudflare. Whether it’s overloaded resources, a misconfigured firewall, or incorrect DNS, the fix involves checking three core areas :

• Server health and capacity
• DNS accuracy in Cloudflare
• Firewall rules and IP whitelisting