Interactive Troubleshooter

Published: Sep 4, 2026

Cloudflare 522 / 523 / 524 Errors Explained

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

An interactive root-cause diagnostic tree to fix Cloudflare 522, 523, and 524 gateway errors. Resolve origin TCP handshake timeouts, DNS routing blackholes, firewall IP blocking, and backend processing delays.

Full Diagnostic Tree & Step-by-Step Overview

Which specific Cloudflare 5xx error screen or timeout behavior is your website displaying?

Error 522: Connection timed out (Cloudflare failed to complete TCP handshake with origin).
Error 523: Origin is unreachable (Cloudflare cannot route traffic to the origin server IP).
Error 524: A timeout occurred (TCP handshake succeeded, but origin took over 100 seconds to respond).
Intermittent 522/524 errors occurring primarily during high traffic spikes or background syncs.

What is preventing Cloudflare edge servers from establishing a TCP connection with your origin server?

Origin firewall (UFW/iptables/Fail2ban/cloud security group) is blocking Cloudflare IP addresses.
Web server process (Nginx/Apache) is offline, overloaded, or SYN backlog queue is exhausted.
HTTP Keep-Alive is disabled or misconfigured on the origin web server.

Whitelist Cloudflare IP Ranges on Origin Server Firewall

Solution:

Root Cause: Origin Firewall Dropping Cloudflare Proxy TCP SYN Packets

When a site is proxied through Cloudflare, all client HTTP/HTTPS traffic hits Cloudflare's edge Points of Presence (PoPs) first. Cloudflare then initiates a TCP connection from its edge IP pools to your origin server IP on port 80 or 443. If your origin firewall (e.g., UFW, iptables, Fail2ban, or AWS Security Group / Azure NSG) treats these concentrated incoming requests as a SYN flood or brute-force attack, it drops the TCP SYN packets. Consequently, the 3-way TCP handshake times out, triggering a 522 Connection Timed Out response from Cloudflare.

Step-by-Step Fix:

1Fetch Current Cloudflare IP Subnets:

Cloudflare publishes its official IPv4 and IPv6 ranges. Download the latest list:

bash
     curl -s [https://www.cloudflare.com/ips-v4](https://www.cloudflare.com/ips-v4) -o /tmp/cf-v4.txt
     curl -s [https://www.cloudflare.com/ips-v6](https://www.cloudflare.com/ips-v6) -o /tmp/cf-v6.txt

2Allow Cloudflare IPs in UFW (Ubuntu/Debian):

Loop through the IP subnets and add explicit allow rules for ports 80 and 443:

bash
     for ip in $(cat /tmp/cf-v4.txt /tmp/cf-v6.txt); do
       sudo ufw allow proto tcp from $ip to any port 80,443 comment 'Cloudflare'
     done
     sudo ufw reload

3Allow Cloudflare IPs in iptables (RHEL/CentOS):

Run the following bash loop to insert rules at the top of the INPUT chain:

bash
     for ip in $(cat /tmp/cf-v4.txt); do
       sudo iptables -I INPUT -p tcp -m multiport --dports 80,443 -s $ip -j ACCEPT
     done

4Configure Security Groups / Cloud Firewalls:

If hosting on AWS EC2, GCP, or Azure, update inbound Security Group rules to explicitly permit TCP ports 80 and 443 from all Cloudflare CIDR blocks.

5Unban Cloudflare IPs in Fail2ban:

Check if Fail2ban jailed any Cloudflare IP addresses:

bash
     sudo fail2ban-client status http-auth

Add Cloudflare CIDRs to the ignoreip directive in /etc/fail2ban/jail.conf to prevent automated blocking.

Restart Web Server & Expand TCP Connection Backlog Queue

Solution:

Root Cause: Dead Web Server Process or Saturated TCP Listen Queue

If Nginx, Apache, or Lighttpd crashes or runs out of worker processes (worker_connections exhausted), incoming TCP SYN requests accumulate in the OS kernel SYN backlog queue. Once the backlog queue (net.core.somaxconn) is full, the operating system drops new TCP connection attempts from Cloudflare, resulting in Error 522.

Step-by-Step Fix:

1Check Web Server Status and System Logs:

Check if Nginx or Apache is active:

bash
     sudo systemctl status nginx || sudo systemctl status apache2

Inspect web server error logs for worker process limits:

bash
     tail -n 50 /var/log/nginx/error.log

2Increase Web Server Worker Capacity (Nginx):

Edit /etc/nginx/nginx.conf and adjust worker settings:

nginx
     events {
         worker_connections 4096;
         multi_accept on;
     }

3Increase Linux Kernel TCP Somaxconn Limit:

Edit /etc/sysctl.conf and increase connection backlog parameters:

text
     net.core.somaxconn = 65535
     net.ipv4.tcp_max_syn_backlog = 65535

Apply changes immediately:

bash
     sudo sysctl -p

4Restart Web Service:

Reload configuration to apply changes:

bash
     sudo systemctl restart nginx

Enable and Configure HTTP Keep-Alive on Origin Web Server

Solution:

Root Cause: Disabled or Low Timeout HTTP Keep-Alive Configuration

Cloudflare relies heavily on persistent HTTP Keep-Alive TCP connections between its edge servers and your origin server to reduce latency and TCP handshake overhead. If Keep-Alive is disabled or set to an extremely short timeout (under 15 seconds) on your origin web server, Cloudflare edge servers trying to reuse an expired TCP connection will hit a closed socket, causing intermittent 522 errors. For additional official information, refer to the Cloudflare Official Troubleshooting Guide.

Step-by-Step Fix:

1Enable Keep-Alive in Nginx:

Open /etc/nginx/nginx.conf or site config block:

nginx
     http {
         keepalive_timeout 65s;
         keepalive_requests 10000;
     }

2Enable Keep-Alive in Apache:

Open /etc/apache2/apache2.conf or /etc/httpd/conf/httpd.conf:

apache
     KeepAlive On
     MaxKeepAliveRequests 500
     KeepAliveTimeout 15

3Test Direct Connection via Curl:

Bypass Cloudflare by testing TCP connection directly to origin IP:

bash
     curl -Iv --connect-timeout 10 https://<YOUR_ORIGIN_IP> -H "Host: example.com"

4Reload Web Server:

Apply changes without dropping active sessions:

bash
     sudo systemctl reload nginx || sudo systemctl reload apache2

What DNS or network routing configuration is causing Cloudflare Error 523?

Cloudflare DNS A/AAAA record points to an incorrect, outdated, or unrouted origin IP.
Origin ISP or host data center is experiencing an active network routing blackhole.
Host provider or cloud firewall is actively null-routing Cloudflare egress subnets.

Verify and Correct Origin A/AAAA DNS Target Records in Cloudflare

Solution:

Root Cause: Outdated or Incorrect DNS A/AAAA Record in Cloudflare Dashboard

Cloudflare Error 523 occurs when Cloudflare edge PoPs attempt to route traffic to the origin IP address configured in your Cloudflare DNS settings, but the IP is unreachable, unassigned, or invalid (e.g., points to a private RFC 1918 address like 192.168.1.1 or 127.0.0.1, or an old server IP after a cloud migration).

Step-by-Step Fix:

1Verify Origin Server Public IP:

SSH into your origin server and determine your external IPv4/IPv6 address:

bash
     curl -4 [https://ifconfig.me](https://ifconfig.me)
     curl -6 [https://ifconfig.me](https://ifconfig.me)

2Audit Cloudflare DNS Management Dashboard:

Log into the Cloudflare Dashboard > select your domain > navigate to DNS > Records.

Locate the A record for @ (root) and www.

Verify that the IP address in the Content column matches your server's true public IP.

3Remove Invalid RFC 1918 Private IPs:

Ensure no records point to 127.0.0.1, 10.x.x.x, or 192.168.x.x unless using Cloudflare Tunnel.

4Flush DNS Cache and Retest:

Test resolution directly against Cloudflare nameservers:

bash
     dig +short example.com @1.1.1.1

Trace Route and Verify Origin Network ISP BGP Connectivity

Solution:

Root Cause: Upstream Provider BGP Routing Failure or Network Blackhole

If your origin server IP is correct in DNS, but Cloudflare edge PoPs cannot establish a route to it, an intermediate ISP or data center upstream provider is experiencing BGP route flap, fiber cut, or packet loss. Because Cloudflare routes traffic from global Anycast locations, a regional routing breakdown between Cloudflare's PoP and your host produces Error 523.

Step-by-Step Fix:

1Run MTR Trace from External Network:

Run a bi-directional MTR traceroute from an external host to your origin IP:

bash
     mtr --report --report-cycles=10 <YOUR_ORIGIN_IP>

Look for 100% packet loss at specific transit ASNs.

2Test Direct HTTP Reachability:

Perform direct cURL request bypassing Cloudflare edge:

bash
     curl -I -v http://<YOUR_ORIGIN_IP> --header "Host: yourdomain.com"

3Contact Hosting Provider Infrastructure Support:

If MTR shows packet loss prior to reaching your origin gateway, submit a high-priority ticket to your host with the MTR output so they can adjust BGP routing paths.

Resolve Provider Null-Routing & Rate-Limiting Blocks

Solution:

Root Cause: Hosting Provider Null-Routing Cloudflare Anycast IPs

Some hosting providers or managed network firewalls implement automated DDoS protection algorithms that misidentify large volumes of proxied HTTP traffic from Cloudflare Anycast IP ranges as an incoming distributed attack. The provider network then null-routes (blackholes) traffic coming from specific Cloudflare egress IPs, causing Error 523.

Step-by-Step Fix:

1Inspect System Kernel Drops:

Check system logs for IP drop events:

bash
     dmesg -T | grep -i "drop"

2Verify Null Routes in Routing Table:

Run ip route to check if any Cloudflare ranges were added to local blackhole targets:

bash
     ip route show type blackhole

Delete unintended blackhole routes:

bash
     sudo ip route del blackhole <IP_ADDRESS>

3Submit Cloudflare Whitelist Notice to Host:

Request your hosting provider network engineering team to permanently whitelist all official Cloudflare IP blocks at their edge router/scrubbing center layer.

What backend bottleneck is causing Cloudflare Error 524 (HTTP Timeout)?

PHP-FPM, Python (Gunicorn), or Node.js process taking longer than 100 seconds to execute.
Synchronous execution of heavy background tasks (file export, database import, reports).
Web server reverse proxy (Nginx fastcgi_read_timeout or Apache ProxyTimeout) killing connection early.

Optimize Backend Code & Database Execution Beyond 100s Limit

Solution:

Root Cause: HTTP Request Processing Exceeding Cloudflare 100-Second Hard Timeout

Cloudflare enforces a non-configurable 100-second HTTP response timeout for all Free, Pro, and Business plan tiers. When Cloudflare proxies a request, it successfully opens a TCP socket to your origin server, but if your backend (e.g., PHP-FPM, Python WSGI, Ruby, Node.js, or SQL query) takes longer than 100 seconds to send back an HTTP response header, Cloudflare closes the client connection and serves an HTTP 524 A Timeout Occurred page.

Step-by-Step Fix:

1Identify Slow Queries and Script Traces:

Enable slow query logging in MySQL/MariaDB (/etc/mysql/mariadb.conf.d/50-server.cnf):

text
     slow_query_log = 1
     slow_query_log_file = /var/log/mysql/slow.log
     long_query_time = 5

Check PHP-FPM slow log (/etc/php/8.2/fpm/pool.d/www.conf):

text
     request_slowlog_timeout = 10s
     slowlog = /var/log/php-fpm/www-slow.log

2Optimize Slow SQL Queries:

Run EXPLAIN on queries identified in slow logs and add missing database indexes.

3Increase Application Thread / Pool Allocations:

If PHP-FPM processes are waiting on available worker threads, increase pm.max_children in your pool configuration.

Decouple Heavy Synchronous Tasks to Asynchronous Job Workers

Solution:

Root Cause: Running Heavy Computational Tasks Synchronously in HTTP Worker

Attempting to run long-running tasks—such as generating large PDF reports, processing high-resolution batch images, running database migrations, or sending mass email campaigns—inside a synchronous HTTP request thread will hit the 100-second Cloudflare threshold.

Step-by-Step Fix:

1Refactor Code to Asynchronous Queue Workers:

Delegate long-running operations to background queue processors like Redis + Celery (Python), RabbitMQ, Laravel Queues, or BullMQ (Node.js).

2Implement Polling Pattern Architecture:

When a user triggers an export action, return an immediate HTTP 202 Accepted JSON response containing a job ID:

json
     { "status": "processing", "job_id": "98234" }

Client-side JavaScript polls a lightweight endpoint (/api/job-status/98234) until processing completes.

3Bypass Cloudflare via Gray-Cloud Subdomain:

Create an unproxied DNS record (gray cloud / proxy status OFF) dedicated to admin long-running tasks (e.g., direct-admin.example.com). Restrict access to this subdomain by IP address via server firewall rules.

Adjust Nginx / Apache Gateway Timeout Directives

Solution:

Root Cause: Upstream Proxy Timeout Dropping Request Prior to Backend Completion

If Nginx sits in front of PHP-FPM, Node.js, or Gunicorn, Nginx's fastcgi_read_timeout or proxy_read_timeout might be set lower than 100 seconds (e.g., default 60s). In this scenario, Nginx terminates the connection to the application server at 60 seconds and sends a 504 Gateway Timeout to Cloudflare, which Cloudflare translates into a 524 error.

Step-by-Step Fix:

1Increase Nginx FastCGI Read Timeout:

Edit /etc/nginx/sites-available/default (or your site configuration file):

nginx
     location ~ \.php$ {
         include fastcgi_params;
         fastcgi_pass unix:/run/php/php8.2-fpm.sock;
         fastcgi_read_timeout 120s;
         fastcgi_send_timeout 120s;
     }

2Increase Nginx Proxy Read Timeout (For Node/Gunicorn/Docker):

Update reverse proxy location block:

nginx
     location / {
         proxy_pass [http://127.0.0.1:8080](http://127.0.0.1:8080);
         proxy_read_timeout 120s;
         proxy_connect_timeout 120s;
     }

3Adjust PHP max_execution_time:

In /etc/php/8.2/fpm/php.ini:

ini
     max_execution_time = 120

4Reload Web Server and PHP Service:

Apply configuration updates:

bash
     sudo systemctl reload nginx && sudo systemctl reload php8.2-fpm

What infrastructure condition causes intermittent 522/524 errors during peak traffic?

Origin server experiences high CPU, RAM, or IOPS exhaustion under load spikes.
Cloudflare Tunnel (cloudflared daemon) or Railgun service disconnection.
Shared hosting environment hitting CloudLinux I/O or entry process (EP) caps.

Remediate Server Resource Exhaustion & High CPU/RAM Saturation

Solution:

Root Cause: CPU/RAM/Disk IOPS Bottlenecks Dropping Active TCP Requests

When server CPU utilization reaches 100% or available RAM is depleted (triggering Linux Out-Of-Memory kernel kills or heavy swap thrashing), the OS cannot allocate socket buffers or process incoming TCP SYN packets fast enough, resulting in intermittent 522/524 errors during traffic surges.

Step-by-Step Fix:

1Monitor System Resource Utilization:

Check real-time process usage using htop or top:

bash
     htop

Check memory and swap status:

bash
     free -h

2Identify Resource-Intensive Processes:

Sort processes by CPU usage:

bash
     ps aux --sort=-%cpu | head -n 10

3Configure Caching at Cloudflare Edge:

Reduce load on origin by creating Cloudflare Cache Rules to cache static assets and dynamic pages where possible.

4Scale Up Cloud Instance Specs:

Upgrade CPU core count and RAM allocation on your cloud server instance (AWS EC2 instance type upgrade, DigitalOcean Droplet resize, etc.).

Restart and Update Cloudflare Tunnel (cloudflared) Daemon

Solution:

Root Cause: Cloudflare Tunnel (cloudflared) Daemon Disconnection

Sites relying on Cloudflare Tunnel (cloudflared) route traffic through outbound connections to Cloudflare's edge without opening public inbound ports. If the local cloudflared daemon crashes, runs out of file descriptors, or loses connection to edge PoPs, incoming web traffic will time out and throw Error 522/523.

Step-by-Step Fix:

1Check Tunnel Daemon Status:

Check if cloudflared service is running:

bash
     sudo systemctl status cloudflared

2Inspect Cloudflare Tunnel Logs:

Check daemon logs for disconnection errors:

bash
     journalctl -u cloudflared -n 50 --no-pager

3Restart cloudflared Service:

Restart the daemon to force re-registration with Cloudflare edge connector:

bash
     sudo systemctl restart cloudflared

4Update cloudflared Binary:

Upgrade to the latest release:

bash
     cloudflared update

Optimize Shared Hosting CloudLinux Entry Process (EP) Limits

Solution:

Root Cause: Exceeding CloudLinux LVE Limits (Entry Processes / NPROC)

On cPanel or DirectAdmin servers running CloudLinux, each user account is restricted by Lightweight Virtual Environment (LVE) quotas. When concurrent HTTP requests hit the max Entry Process (EP) limit or NPROC limit, CloudLinux refuses new connection attempts from Cloudflare, returning intermittent 522 or 524 timeouts.

Step-by-Step Fix:

1Check Resource Usage in cPanel:

Log into cPanel > check Resource Usage under the Metrics section to see if Entry Process or I/O limits were reached.

2Optimize Database and Object Caching:

Install Redis or Memcached object caching to reduce PHP entry process hold times.

3Upgrade Hosting Package or Request LVE Cap Increase:

Request your web host to increase max_entry_processes (EP) from 20 to 50+ or upgrade to a Managed VPS or Dedicated Server.

Related Diagnostic Guides

Windows Update Error 0x80070002 Missing Files Diagnostic Guide

System Restore Failed 0x80070005 Antivirus Conflict Tree

Windows Photo Viewer Not Showing Thumbnails: Codec Diagnostic

Safe Mode Password Not Working With Microsoft Account Fix

Clipboard History Not Working Windows 11: Sync Service Tree

Subscribe to StepDiag

Embed Guide on Your Website