How to Resolve Cloudflare Error 521: Web Server is Down

A Cloudflare 521 error signifies that the Cloudflare network cannot establish a TCP connection to your origin server on port 80 or 443. This typically results from crashed web server software like Apache or Nginx, firewalls blocking specific Cloudflare IP ranges, or your hosting provider taking the server offline entirely.

Emergency Stop-Gap: If you need to restore access immediately while we work on finding the root cause, you can bypass the proxy. Log into your Cloudflare dashboard and change the “Proxy Status” of your DNS record from “Proxied” (orange cloud) to “DNS Only” (grey cloud). This removes the Cloudflare layer and connects visitors directly to your server’s IP address.

Before You Start

Get your safety net in place by backing up both your website files and database before you modify any server configurations or firewall rules. A single typo within a .htaccess file or an error in a firewall script can lock you out of your own server immediately, cutting off your access entirely. If you currently use SSH to manage your site, ensure you have an alternative entry point—such as a web console from your hosting provider—to regain access if the firewall rules fail and block your connection.

Related guide: Fix Cloudflare Error 522 Connection Timed Out

What are the symptoms of a 521 error?

I’ve seen this specific error enough times to know exactly how unsettling it feels when your visitors start reporting a broken site. However, a 521 error is actually a very specific diagnostic signal; it tells us that while Cloudflare’s network is functioning perfectly, they are unable to establish a connection with your origin server. In plain terms: the request successfully reaches Cloudflare, but when Cloudflare tries to “knock” on your server’s door to fetch your content, there is no response from your hosting environment.

This communication breakdown typically stems from one of three specific technical failures:

1. Your web server software (such as Nginx or Apache) has stopped running or crashed.
2. Your firewall is actively blocking or rejecting connection attempts that originate specifically from Cloudflare’s IP addresses.
3. The physical hardware or virtual instance hosting your site is completely offline or unreachable over the public internet.

Related guide: Fix .htaccess Redirect Loop: Guide to ERR_TOO_MANY_REDIRECTS

Why does my site show a 521 error?

I know how unsettling it is when your website suddenly goes dark with an error code, especially when you’re trying to run a business. It feels like a total failure, but I can tell you right now that a 521 error is a specific hurdle we can clear.

The root cause of this error is a failed TCP handshake. To put that into plain terms: Cloudflare acts as a bridge between your visitors and your server. Because you are using Cloudflare, every request hitting your site is coming from a Cloudflare IP address first. If your origin server doesn’t recognize those specific IPs, or if the software responsible for handling those requests isn’t active, the “handshake” fails and the connection is dropped before it ever reaches your content.

There are three primary technical reasons why this happens:

• Service Crashes: Your web server—whether that is Nginx or Apache—might have stopped running entirely. This often happens due to a memory leak or a specific plugin conflict that overwhelms the system, causing the software to stop listening on ports 80 (HTTP) or 443 (HTTPS).
• Firewall Blocks: Security layers like ufw or iptables, or even hardware-level firewalls, are designed to protect you. However, they can sometimes be over-eager. If your firewall sees a high volume of traffic coming from Cloudflare’s IP range, it might mistake that legitimate traffic for a DDoS attack and automatically block those packets.
• Port Misconfiguration: Your server might be configured correctly for standard web traffic on port 80, but the configuration for the standard HTTPS port (443) might be missing or broken. If Cloudflare tries to connect via SSL and the server isn’t listening on 443, the connection will fail instantly.

Related guide: How To Fix A 500 Internal Server Error Website

Is my web server actually running?

It is incredibly stressful when your site suddenly goes dark, but we can figure out exactly what is happening under the hood. The first step in our recovery process is determining if your web server software—the engine that serves your pages to the world—is actually active. You can check this status by logging in via SSH or by navigating to your hosting control panel, such as cPanel or Plesk.

To check the status of Nginx:

systemctl status nginx

To check the status of Apache (on most systems):

systemctl status apache2

If you see that the service is “inactive” or has “failed,” we need to force a restart immediately to get things moving again:

systemctl restart nginx

OR

systemctl restart apache2

In the event that the service refuses to start after these commands, it usually indicates that there is a typo or a syntax error hidden within your configuration files. You can pinpoint and identify these specific errors by running:

nginx -t

OR*

apachectl configtest

Is my firewall blocking Cloudflare’s IP addresses?

If you are staring at a 521 error on a live site, the most likely culprit is that your server’s security layer is misidentifying Cloudflare as an intruder. In production environments, this is the primary cause of such errors. Because Cloudflare operates as a proxy, every visitor’s request passes through their network first; your server sees those specific IP ranges instead of individual user IPs. If you haven’t explicitly told your firewall (such as ufw or iptables) to trust these addresses, the system will assume the traffic is hostile and block it automatically.

You must ensure that the official Cloudflare IP ranges are whitelisted within your server’s security layers.

If you are using ufw, you need to create a specific rule to allow Cloudflare’s traffic:

# Example of allowing a single range (Replace with actual Cloudflare ranges)
ufw allow from 103.0.0.0/8 to any port 443

How do I whitelist Cloudflare IPs in my firewall?

When your site goes dark and you see an error page, it’s incredibly stressful to figure out where the connection is breaking. Often, this happens because your server’s security system sees a high volume of traffic from Cloudflare and assumes it’s a cyberattack, effectively locking its own front door. To fix this, we need to identify exactly where your firewall rules are managed—whether that’s at the OS level (Ubuntu/Debian), within a control panel, or on a hardware firewall provided by your hosting company.

Using UFW (Common on Ubuntu/Debian)

If you are running a Linux server using the ufw (Uncomplicated Firewall) tool, start by checking your current status:

ufw status

If the status shows it is active, your primary goal is to ensure ports 80 and 443 remain open for everyone while specifically prioritizing the Cloudflare range. If you have a “fail2ban” service running in the background, it might be aggressively blocking Cloudflare IPs because they are hitting your site’s endpoints too quickly. Whitelisting these specific IPs ensures that your security software recognizes them as trusted partners rather than threats.

Using iptables (Lower-level Linux firewall)

If you manage your server using iptables directly, the system requires explicit instructions to allow traffic from Cloudflare’s specific IP blocks. You need to insert a rule that tells the server to accept these packets:

# Example for one published Cloudflare range; repeat per line for the full list
iptables -I INPUT -p tcp --dport 443 -s 173.245.48.0/20 -j ACCEPT

Note: Add one rule per range. The authoritative, current list is published at cloudflare.com/ips.

Using cPanel/WHM (Common for Shared Hosting)

If your environment is managed through a control panel like cPanel, you likely won’t be editing raw configuration files manually. Instead, look for the “ConfigServer Security & Firewall” (CSF) module. You need to add Cloudflare’s IP ranges into the csf.allow file or use the built-in “Allow” feature within the graphical user interface to bypass the block.

Audit Pillar	Technical Actions	Business Value
Service Availability	Restart Nginx/Apache; Run configuration tests.	Ensures your site is accessible to all visitors immediately after a crash or update.
Firewall Integrity	Whitelist Cloudflare IPs in ufw or iptables.	Prevents your security software from “attacking” its own proxy provider and blocking legitimate traffic.
Port Accessibility	Verify ports 80 and 443 are open via netstat.	Confirms the server is actually listening for incoming web traffic requests from the outside world.

How do I check if my port is open?

In many cases, a service may be running perfectly well in the background, but it isn’t actually “listening” on the specific ports required to accept incoming traffic. You can verify exactly which ports your server is currently listening on by using the net_stat or ss command.

ss -tunlp | grep -E '80|443'

If the output does not show results for both 80 and 443, your web server isn’t bound to those ports correctly. You will need to update your configuration file (for example, /etc/nginx/sites-enabled/default) and ensure the listen directive explicitly includes both:

server {
    listen 80;
    listen 443 ssl;
    ...
}

How do I check for a “Zombie” process?

It is incredibly frustrating when your dashboard shows everything is “online,” but your customers are hitting a wall of loading screens. This often happens because the server has entered what we call a “zombie” state—the system thinks the service is active, but the software itself is effectively paralyzed and isn’t processing new incoming traffic.

To get eyes on what’s actually happening under the hood, you need to identify the Process ID (PID) of your web server. Running this command will pull up a list of the current processes:

ps aux | grep -E 'nginx|apache'

When you look at the output, pay close attention to the instances listed. If you find multiple entries that aren’t responding or seem to be hanging in place, we can resolve this by performing a full restart of the service or by specifically “killing” those unresponsive processes to force them to clear out.

What are common mistakes that make this worse?

Mistakes made during a 521 crisis often turn a manageable configuration hiccup into a total site lockout. When you are in the middle of an outage, it is tempting to try things quickly, but these specific actions can make your situation significantly harder to resolve:

1. Restarting services without checking logs: If Nginx fails to start because of a syntax error or a configuration typo, restarting the service repeatedly will never fix the underlying problem; it just fills your system logs with failed attempts and wastes valuable time. You must always run nginx -t before attempting a restart. This command acts as your diagnostic tool, pinpointing exactly where the configuration is broken so you can fix the specific line of code rather than guessing why the service won’t stay up.
2. Blocking IPs based on “Bad Traffic”: It is common to see high volumes of traffic from Cloudflare IP ranges in your server logs and assume these are bot attacks or malicious actors. If you block these IP ranges to “stop” the bots, you are inadvertently blocking every single visitor coming through Cloudflare. Because Cloudflare acts as the gateway between the user and your server, blocking their IPs effectively shuts the front door on your entire audience.
3. Incomplete Whitelisting: A common oversight is whitelisting only IPv4 addresses while neglecting IPv6. Depending on how a user’s ISP routes their connection through Cloudflare, they may be connecting via an IPv6 address. If you haven’t accounted for both protocols, you will see “intermittent” 521 errors where some users can access the site and others cannot—making it very difficult to diagnose until both types of addresses are properly whitelisted.

How do I troubleshoot this if I use a managed host?

If your site is hosted under a “Managed WordPress” or “Managed VPS” plan, the situation changes because the hosting provider handles the underlying server infrastructure. In these cases, you likely won’t have direct SSH access to the server. This means the breakdown is almost certainly located within their internal firewall configurations or a core service that has crashed on their end of the environment.

1. Open a ticket: To get past their basic support scripts and reach a technician who can actually fix this, be very specific. Tell them: “I am receiving a Cloudflare 521 error. Please verify that your firewalls are not blocking Cloudflare IP ranges and that Nginx/Apache is running on ports 80 and 443.”
2. Check the Control Panel: If you have access to an administrative dashboard like cPanel or Plesk, navigate to the “Service Status” section. This will allow you to see if Apache or Nginx is currently flagged as active (usually indicated by a green status light).

When to call a professional?

There are moments when the issue moves beyond simple configuration errors and into the complexities of server infrastructure. You should reach out to a systems administrator or a site reliability engineer if:

• The nginx -t or apachectl configtest commands return errors that you cannot interpret. These failures usually indicate fundamental conflicts within your core configuration files.
• You have whitelisted Cloudflare IPs, yet the 521 error persists. This specific scenario often points to a deeper routing conflict involving your ISP.
• Your server is reporting high “Load Average” numbers that prevent services from starting. This indicates the system is overwhelmed at the hardware or OS level and requires professional optimization.
• You are unable to access your own server via SSH or FTP after making changes to your firewall. At this point, you are essentially locked out of the system and need a specialist to regain entry.

A specialist can perform an exhaustive audit of the syslog and /var/log/nginx/error.log files to pinpoint exactly why a connection is being dropped at the kernel level—a task that is often impossible for non-technical owners to diagnose without specialized tools.

Related Guides

• How to Configure Nginx for SSL
• Securing Your Server with UFW and Fail2Man
• Optimizing Cloudflare DNS Settings