Web Server Is Down Error Code 521: Cloudflare vs Nginx and Other Tools for Troubleshooting Server Connectivity

By
Issabela Garcia
-
0
9

A Web Server Is Down 521 error means Cloudflare can find your site, but your origin server is slamming the door shut. Cloudflare knocks. Nginx, Apache, or another web server does not answer. Or worse, the firewall yells, “Nope.” Your job is to find who is being rude.

TLDR: Error 521 usually means Cloudflare tried to connect to your server on port 80 or 443, but the server refused the connection. For example, if a shop gets 2,000 visits per day and 521 lasts for 30 minutes, around 40 to 60 customers may hit a dead page. Check if Nginx is running, confirm your firewall allows Cloudflare IPs, and test the origin with curl. Start with the server, not the browser.

What Error 521 Really Means

Cloudflare sits between your visitor and your server. Think of it as a polite security guard with a clipboard.

When someone visits your site, Cloudflare asks your origin server for the page. If the origin server rejects the request, Cloudflare shows Error 521: Web Server Is Down.

That message is a bit dramatic. The server may not be fully down. It may just refuse Cloudflare. Classic server behavior. Very helpful. Very annoying.

A 521 error often means one of these things:

  • Nginx is stopped or crashed.
  • Apache is stopped or crashed.
  • The firewall blocks Cloudflare IPs.
  • The server is overloaded and refuses new connections.
  • Port 80 or 443 is closed.
  • DNS points to the wrong origin IP.
  • Fail2ban or security software blocked Cloudflare.

Cloudflare vs Nginx: Who Is the Problem?

This is not really a fight. It is more like a messy group chat.

Cloudflare is the proxy. It receives visitor requests. It filters traffic. It caches files. It hides your origin IP. It also shows the 521 page when it cannot connect.

Nginx is usually the web server at the origin. It listens on ports. It serves files. It passes PHP requests. It may also act as a reverse proxy for Node.js, Python, or other apps.

So when a 521 appears, ask one simple question:

Can Cloudflare connect to Nginx on the origin server?

If the answer is no, you found the problem zone.

Step 1: Check If Nginx Is Alive

Log in to your server with SSH. Then run:

sudo systemctl status nginx

If Nginx is stopped, start it:

sudo systemctl start nginx

Then enable it for future reboots:

sudo systemctl enable nginx

If it fails, test the config:

sudo nginx -t

This command is your truth serum. It finds broken brackets, bad paths, and awkward config mistakes. Honestly, it feels like one missing semicolon can ruin your whole afternoon.

If the test passes, reload Nginx:

sudo systemctl reload nginx

Step 2: Test the Origin Without Cloudflare

You need to know if the origin server answers directly.

Run this from your machine:

curl -I http://YOUR_ORIGIN_IP

For HTTPS, use:

curl -Ik https://YOUR_ORIGIN_IP

A good result looks like:

HTTP/1.1 200 OK

or even:

HTTP/2 301

A bad result may say:

Connection refused

That is 521 territory.

If direct access fails, Cloudflare is probably not the villain. Your origin server is the grumpy one.

Step 3: Check Ports 80 and 443

Nginx must listen on the right ports. Check with:

sudo ss -tulpn | grep nginx

You want to see something like:

:80
:443

If nothing appears, Nginx may not be listening. Your config may be wrong. Or another service may be hogging the port like a raccoon in a trash can.

You can also test from outside:

nc -vz YOUR_ORIGIN_IP 80
nc -vz YOUR_ORIGIN_IP 443

If both fail, check Nginx and firewall rules next.

Step 4: Firewall Rules Can Be Sneaky

Cloudflare connects from its own IP ranges. Your firewall must allow them.

If you use UFW, check status:

sudo ufw status verbose

Quick test:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

If your rules are strict, add Cloudflare IP ranges from the official Cloudflare list. Do not guess. The list changes sometimes.

Check other blockers too:

  • iptables
  • nftables
  • Fail2ban
  • CSF firewall
  • Hosting provider firewalls
  • WordPress security plugins

It drives me crazy that a server can look fine locally, while a provider firewall blocks everything before traffic even reaches it. That can add 10 extra minutes of head scratching.

Step 5: Check Cloudflare DNS

Open the Cloudflare dashboard. Go to DNS. Check the A record for your domain.

Does it point to the correct origin IP?

If your server IP changed, but Cloudflare still points to the old one, you get chaos. The old server may refuse traffic. Or it may belong to someone else now. Fun, right?

Use this command:

dig yourdomain.com

Compare the result with your real server IP. If they differ, fix the DNS record.

Step 6: Read the Logs Like a Detective

Logs are boring until they save your site.

For Nginx errors:

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

For access logs:

sudo tail -n 50 /var/log/nginx/access.log

If Cloudflare requests never appear in access logs, traffic is not reaching Nginx. Check firewall, ports, DNS, or hosting network rules.

If requests appear but errors follow, Nginx may be passing traffic to a broken app.

Common clues include:

  • connect() failed
  • upstream timed out
  • permission denied
  • no live upstreams
  • address already in use

Other Tools That Help

You do not need a giant toolbox. You need the right few tools.

  • curl: Tests HTTP and HTTPS responses.
  • dig: Checks DNS answers.
  • ping: Checks if an IP responds, though many servers block it.
  • traceroute: Shows the path to the server.
  • mtr: Better path testing over time.
  • ss: Shows listening ports.
  • journalctl: Shows service logs.

Try this one:

sudo journalctl -u nginx --since "15 minutes ago"

It shows what Nginx has been doing recently. If it crashed five times in three minutes, you will see it.

Fast Fix Checklist

Use this when your brain is melting:

  1. Check systemctl status nginx.
  2. Run nginx -t.
  3. Test origin with curl -I.
  4. Confirm ports 80 and 443 are open.
  5. Allow Cloudflare IPs in the firewall.
  6. Check Cloudflare DNS records.
  7. Read Nginx error logs.
  8. Restart only after you understand the likely cause.

When It Is Not Nginx

Nginx may be fine. The app behind it may be broken.

If Nginx proxies to another service, check that service too. It may be Node.js, Gunicorn, PHP-FPM, Docker, or something custom that Bob from 2019 left behind.

Check PHP-FPM:

sudo systemctl status php8.2-fpm

Check Docker:

docker ps

Check memory:

free -m

Check disk space:

df -h

A full disk can break logs, sessions, caches, and databases. Then everything acts haunted.

The Simple Rule

Cloudflare reports the 521. Your origin usually causes it.

Start at the server. Check Nginx. Check ports. Check firewalls. Check DNS. Then read logs.

Most 521 errors are fixed by restarting a failed web server, correcting a firewall rule, or updating a bad DNS record. Not glamorous. Very effective.

When the site comes back, save your commands. Future you will be grateful. Present you can finally stop glaring at the error page.