Cloudflare Error 521: Web Server Is Down (Complete Fix Guide)
You just opened your site in a browser and got hit with a big "Error 521: Web server is down" page from Cloudflare. Your heart sinks. Your users are seeing this too. Let us walk through exactly what is happening and how to fix it, step by step.
Error 521 means Cloudflare tried to connect to your origin server and the connection was actively refused. Three things to check right now:
- Is your web server running? SSH in and run
systemctl status nginx(orapache2) - Is port 80/443 open? Run
curl -sI http://localhostfrom the server itself - Are Cloudflare IPs whitelisted? Your firewall must allow all Cloudflare IP ranges
What Does Cloudflare Error 521 Actually Mean?
Before you start changing things, let us understand what is really going on. When a visitor requests your website, the request does not go directly to your server. It goes to Cloudflare first. Cloudflare then makes a separate connection to your origin server to fetch the content.
Error 521 means that second connection failed. Cloudflare reached out to your server, and your server said "no." Or more accurately, your server did not respond at all. The connection was actively refused.
This is different from other Cloudflare errors. With a 522 error, the connection times out (the server is alive but not responding fast enough). With a 523 error, the server is completely unreachable. But with a 521, something on your end is actively refusing the connection. That is actually good news because it means the machine is running, and the problem is usually fixable in a few minutes.
If you have been troubleshooting Cloudflare WAF 403 errors before, you know that Cloudflare errors can be confusing because the problem is almost never on Cloudflare itself. The 5xx range in Cloudflare land always points back to your origin.
Step 1: Check if Your Origin Server Is Actually Running
The most common cause of a 521 error is embarrassingly simple: your web server process crashed or stopped. It happens. Apache runs out of memory and gets killed by the OOM killer. Nginx hits a config syntax error after a reload. PHP-FPM fills up its error log and the disk runs full. Whatever the reason, the fix starts with checking the basics.
SSH into your server and run these commands:
# Check if Nginx is running
systemctl status nginx
# Or check Apache
systemctl status apache2
# Check if anything is listening on port 80 and 443
ss -tlnp | grep -E ':80|:443'
# Quick test from the server itself
curl -sI http://localhost
curl -sI https://localhost
If systemctl status shows your web server as inactive or failed, you have found your problem. Check the logs to understand why it stopped:
# Nginx error log
tail -50 /var/log/nginx/error.log
# Apache error log
tail -50 /var/log/apache2/error.log
# Check if OOM killer struck
dmesg | grep -i "out of memory" | tail -10
# Check disk space (full disk kills everything)
df -h
Once you know why it stopped, fix the underlying issue and restart the service:
# Restart Nginx
sudo systemctl restart nginx
# Restart Apache
sudo systemctl restart apache2
# Verify it is running
systemctl status nginx
If the service fails to start, there is likely a configuration error. Run the config test:
# Nginx config test
sudo nginx -t
# Apache config test
sudo apachectl configtest
Fix whatever the config test reports and try starting the service again. Nine times out of ten, a 521 error is just a stopped web server.
Step 2: Check if Your Firewall Is Blocking Cloudflare
This is the second most common cause, and it trips up a lot of people. Here is the scenario: you set up a firewall (good), you locked down ports to only allow known IPs (also good), but you forgot to whitelist Cloudflare IP ranges (bad). Or you updated your firewall rules and accidentally removed them.
When your site is behind Cloudflare, all legitimate traffic comes from Cloudflare IP addresses, not from your visitors directly. If your firewall blocks Cloudflare, it blocks everyone.
Cloudflare publishes their IP ranges at cloudflare.com/ips. At the time of writing, the IPv4 ranges include:
173.245.48.0/20
103.21.244.0/22
103.22.200.0/22
103.31.4.0/22
141.101.64.0/18
108.162.192.0/18
190.93.240.0/20
188.114.96.0/20
197.234.240.0/22
198.41.128.0/17
162.158.0.0/15
104.16.0.0/13
104.24.0.0/14
172.64.0.0/13
131.0.72.0/22
Check your firewall to see if these ranges are allowed:
# Check iptables rules
sudo iptables -L -n | head -50
# Check UFW status
sudo ufw status verbose
# Check if a specific Cloudflare IP can reach port 443
# (test from outside your server)
nc -zv YOUR_SERVER_IP 443
If you are using UFW, here is how to whitelist all Cloudflare IPs:
# Download current Cloudflare IPs and add them
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
sudo ufw allow from $ip to any port 80,443 proto tcp
done
# Reload UFW
sudo ufw reload
If you are on AWS, check your Security Group attached to the EC2 instance. The inbound rules must allow TCP ports 80 and 443 from Cloudflare IP ranges. You can also use the Cloudflare managed prefix list in AWS if your region supports it.
One thing that catches people off guard: Cloudflare rotates and adds new IP ranges occasionally. If you hardcoded the IPs once and never updated them, new Cloudflare data centers might not be able to reach your server. Set up a cron job or automation to periodically pull the latest ranges from the Cloudflare API.
Step 3: Your Web Server Crashed and Needs Attention
Sometimes the web server is "running" according to systemctl, but it is not actually serving requests. This can happen when:
- All worker processes are busy and the server cannot accept new connections
- A segfault or crash loop is happening in a child process
- PHP-FPM is down while Nginx is up (Nginx returns 502 locally, but Cloudflare shows 521 if the connection itself is refused)
- The server ran out of file descriptors
Check whether the server is actually responding to local requests:
# Test from the server itself
curl -sI http://127.0.0.1
curl -sI https://127.0.0.1 -k
# Check how many connections are active
ss -s
# Check open file descriptors for Nginx
ls /proc/$(pgrep -o nginx)/fd | wc -l
# Check PHP-FPM status (if using Nginx + PHP-FPM)
systemctl status php8.2-fpm
If PHP-FPM is the problem, check its logs and restart it:
# PHP-FPM logs
tail -50 /var/log/php8.2-fpm.log
# Restart PHP-FPM
sudo systemctl restart php8.2-fpm
For Nginx with PHP-FPM, remember that Nginx handles the TCP connection and proxies to PHP-FPM via a socket or TCP port. If PHP-FPM dies but Nginx is still running, visitors get a bad gateway error. But if Nginx also hits its connection limit and starts refusing, Cloudflare sees a 521. Check both services, not just one. If you are also dealing with bad gateway issues, our Nginx 502 bad gateway fix guide covers that in detail.
Step 4: SSL Configuration Mismatch
This is a sneaky one. The SSL mode you have set in Cloudflare determines how Cloudflare connects to your origin. Get it wrong and you get a 521.
Here is how the modes work:
- Off: No encryption at all. Cloudflare connects to your origin on port 80 over plain HTTP.
- Flexible: Cloudflare connects to your origin on port 80 (HTTP). Your origin does not need an SSL certificate.
- Full: Cloudflare connects on port 443 (HTTPS). Your origin needs an SSL certificate (self-signed is fine).
- Full (Strict): Same as Full, but the certificate must be valid and trusted (no self-signed).
The 521 problems happen in these scenarios:
- Cloudflare is set to Full or Full (Strict), but your origin server is only listening on port 80 (no SSL configured). Cloudflare tries to connect on port 443, nobody is listening, and you get a 521.
- Your origin only has HTTPS on port 443, but Cloudflare is set to Flexible and tries to connect on port 80, which your server has redirecting to HTTPS or not listening at all.
The fix is to make sure your Cloudflare SSL mode matches what your origin server supports:
# Check what ports your server is listening on
ss -tlnp | grep -E ':80|:443'
# If you see only :80, use Flexible mode in Cloudflare
# If you see :443 (with or without :80), use Full mode
# If you have a valid certificate from a trusted CA, use Full (Strict)
I strongly recommend using Full (Strict) with a free Cloudflare Origin CA certificate installed on your server. This gives you end-to-end encryption without the hassle of managing Let us Encrypt renewals. You can generate an Origin CA certificate in the Cloudflare dashboard under SSL/TLS, and it is valid for up to 15 years.
Use our SSL Checker to verify your certificate is correctly installed and trusted.
Step 5: Origin Server Overloaded
If your server is getting hammered with traffic, it might start refusing new connections even though the web server process is technically running. This usually shows up as intermittent 521 errors rather than a constant outage.
Check the server load:
# Current load and uptime
uptime
# Real-time process view
top -bn1 | head -20
# Memory usage
free -m
# Check for connection limits being hit
ss -s
# Nginx connection count
ss -ant | grep :443 | wc -l
# Check Apache MaxRequestWorkers / MaxClients
apache2ctl -V | grep -i mpm
grep -i maxrequestworkers /etc/apache2/mods-enabled/mpm_*.conf
If the server is overloaded, you have a few options:
- Increase worker limits in your web server config (but only if you have the RAM for it)
- Enable Cloudflare caching to reduce the number of requests hitting your origin
- Scale your server (upgrade the instance, add more RAM, add more CPU)
- Add a CDN caching layer like Varnish between Cloudflare and your web server
- Optimize your application to use fewer resources per request
For Nginx, increase the worker connections:
# /etc/nginx/nginx.conf
worker_processes auto;
events {
worker_connections 4096; # Default is often 768
multi_accept on;
}
For Apache with the prefork MPM, increase MaxRequestWorkers:
# /etc/apache2/mods-enabled/mpm_prefork.conf
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxRequestWorkers 256
MaxConnectionsPerChild 10000
</IfModule>
Step 6: DNS Pointing to the Wrong IP
This sounds basic, but I have seen it happen more times than I can count. You migrated servers, changed hosting providers, or spun up a new instance, and forgot to update the DNS record in Cloudflare.
Check what IP Cloudflare is trying to reach:
- Log into the Cloudflare dashboard
- Go to DNS and find your A record (or AAAA for IPv6)
- Verify the IP address matches your current server
You can also check from the command line:
# Check what Cloudflare resolves your domain to
# (this shows the Cloudflare proxy IP, not your origin)
dig +short yourdomain.com
# To see the actual origin IP, check Cloudflare dashboard
# or use the API:
curl -s -X GET "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records?type=A&name=yourdomain.com" \
-H "Authorization: Bearer YOUR_API_TOKEN" | jq '.result[].content'
If the IP is wrong, update it in the Cloudflare DNS dashboard. Changes propagate within a minute since Cloudflare handles the DNS resolution directly.
Also check that you do not have conflicting records. If you have both an A record and a CNAME record for the same hostname, weird things happen. Clean up any duplicate or stale records while you are in there.
Pro Tip: Test Your Origin Directly
The fastest way to diagnose a 521 error is to bypass Cloudflare entirely and connect to your origin server directly. This tells you immediately whether the problem is on your server or somewhere in between.
# Replace YOUR_ORIGIN_IP with your actual server IP
# Replace yourdomain.com with your actual domain
curl -sI -H "Host: yourdomain.com" http://YOUR_ORIGIN_IP/
curl -sI -H "Host: yourdomain.com" https://YOUR_ORIGIN_IP/ -k
The -H "Host: yourdomain.com" header is important because your server might be hosting multiple sites and needs the Host header to know which one to serve. The -k flag on the HTTPS request tells curl to accept the certificate even if it does not match the IP address.
If you get a response (200, 301, 302, anything), your server is working. The problem is between Cloudflare and your server, which usually means a firewall issue. If you get "Connection refused," the web server is not listening. If you get no response at all, the server might be completely down or unreachable.
Use our Exposure Checker to run a comprehensive check on your domain including SSL, DNS, headers, and more. It can help you spot configuration issues that might be contributing to the problem.
Check Your Server Configuration
SecureBin Exposure Checker tests your domain for SSL issues, DNS misconfigurations, and security header problems that can contribute to Cloudflare errors.
Scan Your Domain FreeCloudflare 5xx Error Codes Comparison
Cloudflare uses several 5xx error codes, and each one points to a different problem. Here is a quick reference so you can diagnose the right issue:
| Error | Meaning | Likely Cause | Fix |
|---|---|---|---|
| 520 | Web server returns unknown error | Origin sent an empty, malformed, or unexpected response | Check origin server logs, fix application errors |
| 521 | Web server is down | Origin refuses connection (server stopped, firewall, wrong port) | Start web server, whitelist Cloudflare IPs, fix SSL mode |
| 522 | Connection timed out | TCP handshake to origin timed out (overloaded, firewall silently drops) | Check server load, ensure firewall allows Cloudflare, increase timeouts |
| 523 | Origin is unreachable | DNS record points to unreachable IP, server completely offline | Verify DNS A record IP is correct and server is online |
| 524 | A timeout occurred | Origin connected but took too long to respond (over 100 seconds) | Optimize slow scripts, increase PHP max_execution_time, check DB queries |
| 525 | SSL handshake failed | SSL/TLS handshake between Cloudflare and origin failed | Install valid SSL certificate, check cipher suite compatibility |
| 526 | Invalid SSL certificate | Origin SSL certificate is expired, self-signed, or wrong hostname (Full Strict mode) | Renew certificate, install Cloudflare Origin CA, or switch to Full mode |
If you are dealing with a 403 error instead, that is a completely different issue. Check our guide on fixing Cloudflare WAF 403 Forbidden errors for that scenario.
Prevention: Stop 521 Errors Before They Happen
Fixing a 521 error is one thing. Making sure it never happens again is another. Here is what I recommend for any production site behind Cloudflare:
Set Up Cloudflare Health Checks
Cloudflare offers health checks that periodically ping your origin server. If the check fails, Cloudflare can send you an alert before your users start seeing errors. Set one up in the Cloudflare dashboard under Traffic, then Health Checks.
Monitor Your Web Server
Use a monitoring tool that checks your origin directly (not through Cloudflare). Tools like UptimeRobot, Pingdom, or a simple cron job that curls your server locally and alerts on failure. If your web server stops, you want to know within seconds, not when a customer complains.
# Simple monitoring script (add to cron, runs every minute)
#!/bin/bash
if ! curl -sf http://localhost/ > /dev/null 2>&1; then
echo "Web server down on $(hostname)" | mail -s "ALERT: Web server down" you@example.com
systemctl restart nginx # Optional: auto-restart
fi
Enable Automatic Restarts
Configure systemd to automatically restart your web server if it crashes:
# Add to your systemd service override
# sudo systemctl edit nginx
[Service]
Restart=always
RestartSec=5
Keep Cloudflare IPs Updated
Automate the process of whitelisting Cloudflare IPs. Run a weekly cron job that pulls the latest ranges and updates your firewall:
# /etc/cron.weekly/update-cloudflare-ips
#!/bin/bash
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
ufw allow from $ip to any port 80,443 proto tcp 2>/dev/null
done
ufw reload
Set Up Proper Log Rotation
A full disk is one of the most common reasons web servers crash unexpectedly. Make sure your log files are being rotated and old logs are cleaned up. Check that logrotate is configured for your web server and application logs.
Common Mistakes That Cause 521 Errors
After years of managing servers behind Cloudflare, these are the six mistakes I see over and over again:
- Hardcoding Cloudflare IPs instead of automating updates. Cloudflare adds new IP ranges periodically. If you set and forget, new data centers cannot reach your origin.
- Using Full (Strict) SSL mode without a valid certificate. If your certificate expires or was self-signed, Cloudflare cannot complete the TLS handshake and you get a 521 or 525.
- Forgetting to open port 443 after installing SSL. You installed a certificate on your server but only port 80 was open in the firewall. Cloudflare tries port 443 and gets refused.
- Changing hosting providers without updating the DNS A record. The old server gets decommissioned, the IP no longer exists, and Cloudflare cannot connect.
- Rate limiting rules that block Cloudflare IPs. If you set up fail2ban or a rate limiter without excluding Cloudflare ranges, legitimate traffic gets blocked when traffic spikes.
- Running the web server as a non-privileged user without capability to bind to port 80/443. After a reboot, the service fails to start because it cannot bind to privileged ports.
Frequently Asked Questions
What is the difference between Cloudflare Error 521 and Error 522?
Error 521 means Cloudflare tried to connect to your origin server and the connection was actively refused. The server is either down, not listening on the right port, or blocking Cloudflare IPs. Error 522 means the TCP connection timed out. The server might be alive but overloaded, or a firewall is silently dropping packets instead of rejecting them. With a 521, you get an immediate "connection refused." With a 522, Cloudflare waits for a response that never comes.
Do I need to whitelist all Cloudflare IP ranges to fix Error 521?
Yes. Cloudflare publishes its IP ranges at cloudflare.com/ips. Your origin server firewall must allow inbound traffic on ports 80 and 443 from all of these ranges. If you miss even one range, some visitors will get a 521 error depending on which Cloudflare data center handles their request. Different visitors route through different data centers, so a partial whitelist causes intermittent failures that are hard to debug.
Can Cloudflare Error 521 happen intermittently?
Yes. Intermittent 521 errors usually point to one of three things: your web server crashing under load and restarting automatically, a rate limiting firewall rule that temporarily blocks Cloudflare IPs after too many connections, or your web server hitting its MaxClients or worker_connections limit and refusing new connections during traffic spikes. Check your server resource usage and web server error logs to identify the pattern. The journalctl -u nginx --since "1 hour ago" command is great for spotting crash-restart cycles.
Is Your Origin Properly Configured?
Run a free scan on your domain to check SSL certificates, DNS records, security headers, and more. Catch misconfigurations before they cause downtime.
Check Your SSL SetupWrapping Up
Cloudflare Error 521 looks scary, but it is almost always one of a handful of simple issues: your web server stopped, your firewall is blocking Cloudflare, your SSL settings are mismatched, or your DNS is pointing to the wrong IP. The pro tip of curling your origin directly is the single fastest diagnostic step you can take.
If you are managing production infrastructure behind Cloudflare, invest the time to set up proper monitoring, automate Cloudflare IP whitelisting, and configure systemd to auto-restart your services. These three things alone will prevent the vast majority of 521 incidents.
And if you just fixed a 521 error and want to make sure the rest of your setup is solid, run a quick check with our Exposure Checker and SSL Checker. They are free, take a few seconds, and might catch something else before it becomes a problem.
Related guides: Cloudflare WAF 403 Forbidden Fix, Nginx 502 Bad Gateway Fix. Related tools: Exposure Checker, SSL Checker, DNS Lookup, Port Lookup, and 70+ more free tools.
Usman has 10+ years of experience securing enterprise infrastructure, managing high-traffic servers, and building zero-knowledge security tools. Read more about the author.