Origin exposed: how to confirm it and how to close it

The warning means one thing: your own server answered us directly. How to confirm that yourself, the three usual reasons, and what closing it takes.

You will know whether the door is really open, which of the three usual reasons put it there, and exactly what to ask for so that only Cloudflare can reach your server.

The warning on your dashboard is a measurement rather than an opinion. We asked your server directly, from outside Cloudflare, and it answered.

That is the whole finding. It does not mean anyone has attacked you, and it does not mean anyone has noticed. What an exposed origin is covers why this happens at all and how the address gets out. This page starts from the warning already being on your screen.

This is not an emergency, and we are not going to describe it as one. It is an open door on a building that may or may not be interesting to anyone. Worth closing, on a normal working day.

What the warning actually measured

We call your origin address, the machine your website really runs on. We do not call your website name: the name goes through Cloudflare on purpose, so it answering proves nothing here. If the difference between the two is not obvious yet, how it works draws the path.

We try HTTPS first, and only if that stays completely silent do we spend a second request on plain HTTP. A server that is closed on port 443 can still be wide open on port 80, and asking only over HTTPS would tell that server it is fine when it is not.

Any answer at all counts as open, and we do not filter by status code. A 403 means the packets arrived, the connection was accepted, and the software at that address chose to reply. What someone can attack is that software, not the number it sent back.

From the request we keep the status code, the address that finally answered, and how long it took. We never keep what your server sent back. What every check is allowed to store is written down, and the contents of your pages have no field to go in.

Step 1: confirm it yourself

You do not have to take our word for it, and checking by hand takes about a minute.

Find your origin address. It is the address of your own machine, the one your hosting company gave you, and the same value you entered when you added the website here.
Ask for your site at that address instead of at your domain name. Any tool that lets you choose the address will do.
Do it twice, once over HTTPS and once over plain HTTP. Those are two separate doors and they are often locked separately.

Anything that comes back means the door is open. A redirect counts. An error page counts. The hosting company default page counts. All of them say the request arrived and something at that address replied to it.

A certificate warning is not a closed door. Asking for HTTPS at a bare IP address usually produces one, because the certificate was issued for your name and not for the number. Your server still answered, and it got far enough to hand you a certificate.

The one result that is genuinely closed is a refused connection. If the request instead hangs until it gives up, you have learned less than it looks: a server that drops requests without a word and a server that is simply overloaded look identical from outside.

Step 2: work out which door was left open

Three reasons cover almost every case we see.

Nothing was ever set up to stop it. This is the ordinary state of a web server and by far the most common answer. Pointing your name at us changed where the name goes. It never touched the machine.
A rule exists, but it only covers part of the way in. Port 443 is filtered while port 80 is not, or IPv4 is filtered while the same machine still answers on IPv6. Both halves have to be covered, and the second half is the one people forget.
A rule existed and quietly stopped applying. The server was rebuilt, moved to a different address, or a panel update reset it. A list of addresses copied out by hand goes stale as well, because the published list is the one that gets updated and yours is not.

Which of the three it is decides who does the work. The first is a request to whoever runs your server. The other two are usually a rule that already exists, sitting in the wrong place or out of date.

Step 3: close it

The result you are after fits in one sentence: your server accepts connections on ports 80 and 443 only from Cloudflare address ranges, and refuses everything else. That has to hold for IPv4 and IPv6 alike, and Cloudflare publishes both lists.

Where the rule lives depends on what you run: a setting in a hosting panel, a firewall rule, or a few lines of web server config. Whoever runs your server can usually do it if you send them that sentence, and it works the same whether you use us or you moved your nameservers to Cloudflare yourself.

The step by step version, including where people usually lock themselves out, is in how to lock your server to Cloudflare addresses only.

Test it before you walk away. A rule that shuts out Cloudflare along with everyone else takes your website offline, and it does so quietly if you were only checking through the proxy.

Moving your server to a fresh address is not a fix on its own. Old addresses stay in public DNS history, and the address someone already wrote down is the one that matters.

Step 4: wait for the warning to clear

The checks run every ten minutes, on every website in your account. Once your server stops answering us, the next run says so and the warning goes.

Read the time on the dashboard before you change anything else. Every result there says when it was measured, and a warning measured before your rule was in place is describing the world as it was ten minutes ago.

Expect one outcome that looks wrong and is not. If your rule drops requests without answering rather than refusing them outright, our request runs out of time instead of coming back refused, and we report that as not determined rather than as a pass. We would rather say we could not tell than call a silence a clean bill of health.

When the warning appears once and then vanishes

This one deserves its own section, because it looks like our system misfiring and it is not.

Each round of checks decides whether to look at your server at all using what it knew at the end of the round before. So in the ten minutes right after your website stops going through the shield, say the record was deleted or your DNS moved to a different provider, one round can still go and look, still find your server answering, and still raise this warning.

The round after that knows the website is no longer behind anything, stops looking, and the answer turns into not determined instead. From the outside it reads as a red warning that flashed once and disappeared on its own.

So if that is what you saw, the thing to check is not your server. Check that your website is still pointing at us at all.

When we say we cannot tell

Not determined is a real answer on this check, and it never quietly becomes a pass. It reads differently from both the green and the red, and we always say which way we got there.

Your website is not behind the shield yet. A server that answers the whole internet is the normal state of a website nobody has put behind anything, so while a site is still being set up we do not look and we do not judge.
The request ran out of time. Silence after a timeout does not mean the door is closed.
Your origin address could not be resolved, so no request was made at all.
Our own safety check refused to probe the address. That is a decision on our side, not a measurement of your server.

The rule underneath every one of them is the one this check exists to respect: an answer we do not have is not the same as an answer of no. Every check we run works that way, and this is the one where the difference costs the most.

All guides