You built the redirect. The dashboard shows the domain active, the cloud is orange, and the
rule is sitting in the list where you left it. Then someone opens the domain and gets a 522,
or a certificate warning, or a page offering to sell them the name. None of those is your 301.
The redirect did not fail loudly. It is simply not the thing answering, and the dashboard is the wrong place to notice. Three different misconfigurations produce this, each with its own signature, and one request separates them. This is the failure column of the audit script seen up close, and the underside of every way to redirect on Cloudflare: the same methods, and the ways each one goes quiet.
The rule never ran, so Cloudflare called an origin that is not there
A redirect on a parked domain is two parts that look like one. There is a DNS record, an A
record on the apex proxied through Cloudflare, and there is a rule that does the redirecting.
The runbook for parked domains points that record at
192.0.2.1, and Cloudflare’s own note explains why an address that goes nowhere is the right
choice:
This address does not route traffic to an origin server but allows Cloudflare to apply rules, redirects, and Workers to incoming traffic.
The rule is what makes the pattern work. A redirect rule runs at the edge and answers the
request there, so Cloudflare never opens a connection to 192.0.2.1. Take the rule away, scope
it to a hostname that does not match, upload the list to the wrong account, or proxy the record
before the rule exists, and Cloudflare does exactly what the orange cloud tells it to. It
proxies the request to 192.0.2.1. Nothing is listening there, on purpose.
What the visitor gets is a 522. Cloudflare’s definition is literal:
Error 522 occurs when Cloudflare times out contacting the origin web server.
The wait is not instant. Cloudflare sends a SYN and, in the documented case, gives up when the
origin web server does not return a SYN+ACK within 19 seconds, retrying on a backoff of
1,1,1,1,1,2,4,8. So the domain hangs for the better part of half a minute and then shows a
Cloudflare error page. The A record is present, the proxy is on, everything on the DNS tab
looks done, and the one piece that was missing left no mark there.
Swap the dummy address for a real origin and the same missing rule shows up as a different code
from the same family: 521 when the origin refuses the connection, 523 when it is
unreachable, 524 when the connection opens but no response comes back in time. The cause does
not change. The request reached an origin because no edge rule caught it first.
That gives you the tell. A redirect rule that fires never touches the origin, so it cannot time
out against one. Any 52x on a domain that is supposed to redirect is proof that the redirect
did not run for that request.
Full (Strict) turns a redirect at the origin into a certificate error
Not every redirect lives at the edge. Plenty of them are a 301 sent by the origin web server,
with Cloudflare proxying in front. That arrangement only works if Cloudflare can reach the
origin over TLS and accept the certificate it presents, and the SSL/TLS encryption mode decides
how strict it is about that.
Set the mode to Full (Strict) and the certificate has to be one Cloudflare trusts. When the
handshake itself does not complete, the visitor gets a 525:
This error indicates that the SSL handshake between Cloudflare and the origin web server failed.
Cloudflare lists the usual reasons: no valid certificate installed, port 443 closed, no SNI
support, or a cipher mismatch. When the handshake does complete but the certificate does not
check out, the code is 526 instead:
Cloudflare cannot validate the SSL certificate at your origin web server.
That one is paired with Full (Strict) specifically, and it fires on a certificate that has expired, been revoked, carries the wrong name, is missing part of its chain, or was signed by nobody a browser would trust. The redirect the origin wants to send is fine. The visitor never sees it, because the connection that would carry it never finishes.
There is a gentler version of the same problem on a domain you just added. Universal SSL takes time to issue, and it covers one level of subdomain, not two. A request that arrives before the certificate is active, or to a name the certificate does not cover, gets a browser TLS error before any redirect has a chance to run.
The domain never moved, so Cloudflare is not even in the path
The third failure has no Cloudflare error code, because Cloudflare is not involved. You added
the zone, you wrote the rule, and the nameservers at the registrar were never changed to the
pair Cloudflare assigned. The zone sits pending. Everything you configured is real and none
of it is live.
There is a quieter way to land in the same place. Presetting nameservers in bulk before creating the zones, which is the instinct at scale, now backfires:
To prevent domain hijacking, you can no longer preset Cloudflare nameservers at your registrar before creating the respective zone in Cloudflare.
Do it anyway and the zone is assigned a different pair, the registrar points at nameservers that do not serve it, and the domain never activates. Nothing in either interface says why.
While the domain is pending, whatever the registrar serves is what the visitor sees. Often that
is a parking page, sometimes one offering the name for sale, and it usually answers with a
200. A check that only asks whether the domain is up will pass, because something did answer.
It just was not you, and the redirect you wrote is asleep behind a zone that never woke.
One request tells the three apart
Each mode answers a curl differently, which is why the audit reads the status line before
anything else:
curl -sI "https://the-domain/"A 52x on the first line means Cloudflare is in the path and the rule did not fire. A TLS error
before any HTTP status means the handshake to the origin failed, or the edge certificate is not
ready. A 200, or a 302 whose location points at a registrar rather than a 301 to your
target, means the domain is not on Cloudflare at all. The
audit script puts exactly this in its CODE and DESTINATION
columns, which is how you find these across a portfolio instead of one domain at a time.
Where this is less tidy than it looks
A 522 against a real origin can be intermittent rather than constant, usually when the origin
firewall blocks some Cloudflare IP ranges and not others, so the same domain passes and fails by
the hour. On the 192.0.2.1 pattern there is no such ambiguity: the address is reserved and
never answers, so the 522 is every time.
A pending zone is the one case the dashboard actively hides from you, because from inside the account nothing is broken. The rule is valid, the record is valid, the zone is waiting. The evidence only exists outside, in what the domain returns to a request that does not go through Cloudflare.
And a registrar parking page does not always sit still on a 200. Some registrars answer with a
302 to their own parking host, which is a redirect, just not yours. The audit script catches
that by reading where the location points, not merely that a redirect happened. The codes and
definitions here were checked against Cloudflare’s documentation on 23 July 2026.
What one look does not give you
All three of these are green at a glance and only visible from outside, so catching them is a matter of asking every domain the same question on a schedule rather than trusting the dashboard. For a handful of domains, the loop from the audit script on a cron entry is the whole answer, and you should start there.
At the scale where a portfolio carries a long tail of names nobody has opened in months, the question has to be asked continuously, and the answer compared against the last one so a domain that quietly changed raises a flag. That is the part 301.st runs for you: the same probe across the whole portfolio, on a loop, with an alert when a row changes. For twenty domains, the cron entry and the script are genuinely enough.