LiveChat 
Support 
Web Server Is Down (Error 521): What It Means and How to Fix It
If you run a site behind a CDN or proxy and your visitors are suddenly met with a stark message — “Error 521: Web server is down” — it is unsettling, because it sounds catastrophic. The natural reading is that everything has failed. But the web server is down error code 521 is one of the most diagnosable errors you will ever encounter, precisely because it is specific. It does not say “something went wrong somewhere.” It says, very nearly in plain English, “I reached your server, and your server refused to talk to me.” That single sentence tells you where the problem is, who can fix it, and roughly how. The trick, as always, is to stop guessing and read what the error is actually telling you.
This article is part of our complete guide to website error troubleshooting, where you can see how the whole family of 5xx errors fits together and how to approach any of them methodically rather than in a panic.
Key Takeaways
• Error 521 is a CDN/proxy-specific error, not a standard HTTP status. It originates at the proxy sitting in front of your site, not at your visitor’s browser.
• It means the proxy reached your origin server but the connection was refused. Your origin is either down or actively blocking the proxy.
• It is an origin-side problem. Your visitors did nothing wrong, and the proxy is working fine — the issue is your own web server.
• The single most common cause is your origin firewall blocking the proxy’s IP ranges. You asked a CDN to sit in front of your site, then your server treated it as an intruder.
• The fix is owner-side and concrete: confirm the web server is running, allowlist the CDN’s published IP ranges, and verify the origin is reachable on ports 80 and 443.
What does the web server is down error code 521 actually mean?
Error 521 means a CDN or reverse proxy successfully reached your origin web server, but the origin actively refused the connection — so the proxy could not retrieve your page to deliver it. This error is generated by the proxy layer (Cloudflare-style CDNs are where 521 most commonly appears), not by your origin and not by the visitor’s browser. It is the proxy faithfully reporting what it experienced: “I knocked on your server’s door, and the door was slammed in my face.”
That distinction matters enormously for troubleshooting. Many 5xx errors are ambiguous about where the fault lies. A 521 is not. The proxy is telling you three things at once: it found your origin (so DNS is roughly correct), it tried to connect (so the network path exists), and the connection was *refused* rather than timing out (which points to something deliberately rejecting it — a stopped service or a firewall, rather than a slow one).
So the question is never “what’s wrong with the internet?” It is always “why is my own origin server refusing connections from the proxy I put in front of it?”
Who sees a 521 error, and why does it look like the whole site is down?
A 521 error only appears on sites that sit behind a CDN or reverse proxy. If your domain resolves directly to your server with no proxy in the middle, you will never see a 521 — you would see a plain browser-level “connection refused” or a timeout instead. The 521 is specifically the proxy’s branded way of describing a refused origin connection.
Because the proxy fronts *every* request to your domain, when the origin refuses connections, every visitor sees the error simultaneously. That is what makes it feel like a total outage. In reality, the proxy itself is healthy and online — it is your origin behind it that has gone dark or pulled up the drawbridge. The proxy keeps serving the error page reliably, which is the small mercy here: at least your visitors get a clear message instead of a dead connection.
What causes a 521 web server is down error?
Every cause of a 521 reduces to the same root: the origin refused the proxy’s connection. Here are the specific ways that happens, roughly in order of how often I see them.
| Cause | What’s happening | Fix |
|---|---|---|
| Origin firewall blocking the proxy’s IPs | Your server’s firewall sees a flood of requests from the CDN’s address ranges and treats them as suspicious, blocking them. The #1 cause. | Allowlist the CDN’s published IP ranges in the origin firewall. |
| Web server process is down/crashed | Apache, Nginx, or LiteSpeed isn’t running — so nothing is listening on port 80/443 to accept the connection. | Restart the web server (`systemctl restart`). |
| Origin server offline or overloaded | The whole machine is down, rebooting, or so resource-starved it can’t accept new connections. | Confirm the server is up; check CPU/RAM/connection limits. |
| Wrong origin IP in DNS | The proxy is pointed at an IP that no longer hosts your site, so nothing answers. | Verify DNS points to the correct, current origin IP. |
| SSL / port misconfiguration | The origin isn’t listening on the port or protocol the proxy expects (commonly 443/SSL). | Confirm the origin serves on 80 and 443 with valid SSL. |
The thread running through all of these: the proxy did its job, and the origin did not hold up its end. Now let’s fix it.
How do I fix the web server is down error code 521?
These fixes are owner-side — you (or your host) need server access. Work through them in order; the earlier ones are both the most common and the easiest to check.
1. Confirm your web server is actually running
Before anything clever, check that the process that serves your site is alive. A crashed Apache or Nginx is the second most common cause of a 521, and it’s a thirty-second check.
“`bash
sudo systemctl status nginx
sudo systemctl status apache2
sudo systemctl status lsws
sudo systemctl restart nginx “`
If the service won’t start, the status output and the error log will tell you why (a port conflict, a config syntax error, a failed SSL cert). Fix that first — there’s no point allowlisting a firewall for a server that isn’t running.
2. Allowlist the proxy’s IP ranges in your origin firewall — the #1 fix
This is the cause behind most 521 errors, so if your web server is confirmed running, start here. When you put a CDN in front of your site, every legitimate request now arrives *from the CDN’s servers*, not from individual visitors. If your origin firewall is configured to be suspicious of unfamiliar IPs, it sees a high volume of requests from the CDN’s address ranges and blocks them — producing a 521.
The fix is to explicitly allow the CDN’s published IP ranges through your firewall. Your CDN publishes these ranges; add them to your allowlist (here using `ufw` as an example, but the principle applies to `iptables`, `firewalld`, cloud security groups, and host control-panel firewalls alike):
“`bash
sudo ufw allow from 203.0.113.0/24 to any port 443 sudo ufw allow from 203.0.113.0/24 to any port 80
sudo ufw status numbered
sudo iptables -L -n -v “`
Replace the example range with each of your CDN’s actual published ranges. Also check any application-level or host-panel firewall (mod_security, CSF/LFD, Imunify, cloud security groups) — a 521 can come from *any* layer that refuses the proxy.
Here is the insight that makes 521 click. Error 521 is almost always a case of your own security blocking your own CDN. The moment you place a proxy in front of your site, you change who your server talks to. Before, your origin received traffic from thousands of scattered visitor IPs. After, it receives *all* of that same legitimate traffic concentrated into a handful of the CDN’s address ranges. To a firewall configured for the old world, that looks exactly like an attack: a flood of requests from a small set of unfamiliar addresses. So it does its job and blocks them. The proxy then reports, accurately, “I reached your server but it slammed the door.” The fix is not to weaken your security — it’s to teach your origin to recognize its own front door. You explicitly allowlist the CDN’s published IP ranges so your server trusts the proxy you deliberately put in front of it, while still blocking everyone else. A 521 is your origin refusing the very proxy you asked to protect it. Teach the origin to trust the proxy, and the error clears.
3. Confirm the origin is up and reachable on 80 and 443
Verify the server is online and accepting connections on the web ports independently of the proxy. From another machine:
“`bash
ping your-origin-ip
curl -v https://your-origin-ip:443 –resolve yourdomain.com:443:your-origin-ip nc -zv your-origin-ip 443 nc -zv your-origin-ip 80 “`
If `ping` works but the port checks fail, the machine is up but nothing is listening (back to step 1) or the firewall is blocking (step 2). If `ping` itself fails, the server is offline or unreachable at the network level.
4. Check server resources and overload
A server can be “up” yet so overwhelmed it refuses new connections — exhausted RAM, pegged CPU, or hitting its maximum connection limit. Check the load:
“`bash top # live CPU / memory free -m # memory in MB ss -s # socket / connection summary “`
If the box is saturated, the immediate fix is to relieve the load (restart the offending process, kill runaway scripts) and the longer-term fix is more resources or better limits.
5. Verify DNS points to the correct origin IP
If the proxy is configured to reach an IP that no longer hosts your site — after a migration, for example — it will get a refused or dead connection. Confirm the origin record the proxy uses matches your real, current server IP. A stale origin IP produces a permanent 521 until corrected.
6. Check the origin’s SSL and port configuration
If your proxy is set to connect to your origin over HTTPS (full/strict modes), your origin *must* be serving valid SSL on 443. A missing certificate, an expired one, or a web server not listening on 443 will cause the origin to refuse the secure connection. Confirm the origin presents a valid cert on the port the proxy expects.
Why DarazHost makes 521s easy to clear: DarazHost servers are built to sit behind CDNs and proxies cleanly. You get straightforward firewall control to allowlist CDN IP ranges, reliable always-on web server processes that don’t quietly die, and clear, readable error logs so you can tell at a glance whether a 521 is a down origin or a firewall block. And our 24/7 support team will diagnose it with you — confirming whether the proxy is being refused by a stopped service or a security rule, and fixing it at the source. A CDN is only as good as the origin behind it; DarazHost is the dependable origin a CDN needs.
Frequently asked questions about error 521
Is a 521 error my fault or my visitor’s fault?
Neither your visitor nor the proxy. A 521 is an origin-side problem — the server you own (or your host operates) refused the proxy’s connection. Visitors can do nothing to fix it, and refreshing won’t help until the origin is corrected.
Why does the error say “web server is down” if my server is actually running?
Because from the proxy’s point of view, a refused connection is indistinguishable from a dead one — in both cases it can’t get your page. Your server may well be running but *blocking* the proxy at the firewall. That’s why “web server is down error code 521” so often turns out to be a firewall issue, not an actual outage.
How do I find my CDN’s IP ranges to allowlist?
Your CDN publishes its IP ranges in its documentation, usually as a list of CIDR blocks you can fetch programmatically. Add every published range to your origin firewall’s allowlist. Because these ranges can change, it’s worth automating the update rather than pasting them once and forgetting.
Can I fix a 521 from the proxy’s dashboard?
Rarely — and that’s the key insight. The proxy is working correctly; it’s reporting a real refusal from your origin. The fix almost always happens *on the origin*: restarting the web server, adjusting the firewall, or correcting the origin IP. Changing proxy settings only helps in the specific case of an SSL/port mismatch.
How is a 521 different from a 522 or 523 error?
They’re a family of origin-connection errors from the same proxy layer. A 521 means the connection was actively *refused*. A 522 means the connection *timed out* (the origin never answered in time). A 523 means the origin was *unreachable* (wrong IP or routing). The 521’s “refused” specifically points to a stopped service or a firewall block.
The calm way to read a 521
The reason a 521 feels alarming and is actually friendly is that it hands you the diagnosis for free. The proxy reached your server and was turned away. So you don’t investigate the internet, the browser, or the CDN — you investigate why your own origin is refusing connections. Nine times out of ten, the answer is a firewall that doesn’t yet recognize the CDN you put in front of it, or a web server process that needs a restart. Confirm the server is running, allowlist the proxy’s IP ranges, verify it’s reachable on 80 and 443, and the door swings open again. You asked a proxy to guard your front door; a 521 just means you forgot to give it a key.
