Cloudflare error 521 means Cloudflare reached out to your origin server and the origin refused the connection. Cloudflare itself is working, the visitor's connection to Cloudflare is working, and the failure is on the last leg: your server is either down or actively rejecting Cloudflare's requests.
Among Cloudflare's 52x family this is the bluntest member. The three siblings map cleanly to three failure modes on the path to your origin: 521 means the origin refused, 522 means the origin never answered, and 524 means the origin answered too slowly. A refusal, as with any connection error, is information: something at your server's address is up enough to say no, which narrows the causes to two, a web server that is not running, or a firewall that rejects Cloudflare specifically. This article is written for the site owner, because visitors can do almost nothing about a 521, and it walks the five checks that resolve nearly every case, then the prevention layer that catches the next one before your visitors name it for you.
The two causes, and how to tell them apart
Cause one is the ordinary outage: the web server process on your origin has stopped. It crashed, a deploy failed, the machine rebooted and the service did not, or the host suspended the account. In this case the origin refuses everyone, not just Cloudflare, and the fastest confirmation is to test the origin directly, bypassing the proxy entirely.
Cause two is subtler and extremely common: the origin is running but a firewall or security layer rejects connections from Cloudflare's IP ranges. Because all visitor traffic to a proxied site arrives from Cloudflare's addresses rather than from individual visitors, any rule that rate-limits, blocks, or fails to allowlist those ranges shuts off the entire site while every local test passes. Hosting providers' own security systems sometimes do this automatically, interpreting the concentrated traffic from a handful of Cloudflare IPs as an attack. The tell for cause two is exactly that split: the site works when tested directly against the origin and fails through Cloudflare.
The five-step fix
Confirm the origin process is running. SSH in and check the service, systemctl status nginx or its equivalent, and restart it if it is down, then read its log for why it stopped. If you cannot reach the machine at all, the incident is at your host, and their console and status page are the next stop.
Test the origin directly, bypassing Cloudflare. Use curl with the --resolve flag to send a request for your hostname straight to the origin IP, or temporarily grey-cloud a test DNS record. If the direct request succeeds while the proxied site shows 521, the origin is fine and the block is aimed at Cloudflare.
Allowlist Cloudflare's IP ranges. Cloudflare publishes its current ranges at cloudflare.com/ips, and every firewall layer with an opinion, the OS firewall, the cloud security group, any host-level security panel, must permit them on ports 80 and 443. This single step resolves the majority of 521s on servers that are demonstrably up.
Check for reject rules and .htaccess denies. Look specifically for deny rules, rate limits, or security modules that reset connections, including ones added during a past incident and forgotten. A rule that rejects, rather than drops, produces 521 rather than 522, which is a useful fingerprint of what you are hunting.
Confirm the origin still listens on the expected port. If you changed ports, disabled HTTPS on the origin, or altered the server's listening configuration, Cloudflare may be connecting to a port where nothing lives. Match the origin's actual listeners, visible with ss -tlnp, against what your Cloudflare SSL mode expects it to connect to.
What visitors can do, and what to tell them
Almost nothing, and it helps to be honest about that. A visitor seeing a 521 is looking at a site whose origin is refusing its own proxy; refreshing occasionally works if the origin is flapping, and clearing caches accomplishes nothing because nothing is cached wrong. The one useful action a visitor can take is reporting the error to the site with the Ray ID printed on the error page, which lets the operator find the exact event in their logs. Everything else is waiting.
For the operator, that asymmetry is the argument for owning the detection. Your visitors will see the branded Cloudflare error page and most will simply leave; the ones who write in are a small, delayed sample of a large, silent loss. A 521 is also invisible to any internal check that tests the origin from inside its own network, which is exactly the failure mode described in Odown's guide to website downtime: the site is only down from where your customers stand.
Common mistakes in fixing Cloudflare error 521
Restarting the web server when the firewall is the culprit. If direct-to-origin tests succeed, no number of restarts will help. Spend the next five minutes on IP allowlisting instead.
Allowlisting Cloudflare in one firewall layer out of three. The OS firewall, the provider's security groups, and any hosting panel each get a veto. The 521 persists until every layer agrees.
Treating the published IP list as permanent. Cloudflare's ranges change occasionally. A hard-coded copy from years ago eventually omits a range, producing intermittent 521s that follow no pattern you can see.
Confusing 521 with 522. Refused and timed out have different causes: 521 points at rejection, a down service or a reject rule, while 522 points at silence, drops and overload. Fixing the wrong one is a common half-day.
Testing only from inside. Local requests to the origin skip the exact path that is failing. Judge the fix by a request that travels through Cloudflare, ideally from more than one region.
FAQ
Is Cloudflare error 521 my fault as a visitor?
No. The failure is between Cloudflare and the website's own server, and nothing on your device contributes to it or can repair it. Refresh later, and if you want to help, send the site the Ray ID from the error page.
What is the difference between error 521 and 522?
521 means the origin actively refused Cloudflare's connection; 522 means the origin never answered at all within the timeout. Refusal suggests a down service or a reject rule; silence suggests dropped packets or an overloaded host.
Why did error 521 start right after a server migration?
Because the new server's firewall does not yet allow Cloudflare's IP ranges, or the origin IP recorded in your Cloudflare DNS still points at the old machine. Both are five-minute fixes once identified.
How long does a 521 last?
Exactly as long as the origin keeps refusing. There is no propagation or cache involved; the moment the service is up and the firewall admits Cloudflare, the next request succeeds.
Closing thought
Error 521 is the origin saying no to its own proxy, and the diagnosis is a fork with two prongs: the service is down, or the firewall rejects Cloudflare. The direct-to-origin test picks the prong in one command, and the fix is a restart on one side or an IP allowlist on the other, with the published Cloudflare ranges applied to every firewall layer that gets a vote.
The uncomfortable property of the whole 52x family is that your own tests from inside the network pass while the public site is dark. Odown checks your site from the outside, through the same front door your visitors use, from 17 locations around the world, and can watch a grey-clouded health endpoint on the origin as well, so the next time the origin and its proxy stop speaking, the first report comes from your monitoring, not your inbox.
