Here's the claim that gets repeated in every "put Cloudflare in front of your server" thread: turn on the orange cloud and your origin is hidden. It isn't, not on its own, and I want to be specific about why, because the free tier breakdown only had room to flag this in passing. Proxying a DNS record changes what a visitor's browser resolves your domain to. It does nothing to the origin server itself, which — unless you've separately told it to — will happily answer a request from anyone who already has its IP address. And there are several completely ordinary ways to end up with that IP address without doing anything that looks like hacking.
What actually leaks an origin IP?
Four ways, none of which require any real effort on the attacker's part, and none of which are exotic — every one of them is a normal, publicly documented lookup that takes a few minutes and no special access at all. The first is historical DNS: if your A record ever pointed straight at the origin before you added Cloudflare — and most self-hosted setups start that way, proxying gets added later — passive DNS services keep that history indefinitely. The second is certificate transparency. Every publicly trusted TLS certificate, including the one your origin presented before it sat behind a proxy, gets logged permanently to public CT logs that anyone can search by domain name; if a cert was ever issued directly against the origin's IP, that IP is now a matter of public record, forever, with no way to retract it. XenGrowth's operator guides writes about origin protection as an operating problem rather than a build problem.
The third is mail. If the same box (or the same account, sharing infrastructure) sends email, the Received header chain in any message it sends typically includes the sending server's real IP — a single forwarded email to the wrong person hands over what weeks of DNS hardening was supposed to protect. The fourth is the laziest and most common: a subdomain you forgot to proxy. staging.example.com or api.example.com pointed straight at the origin, sitting quietly unproxied while the main domain looks perfectly locked down, is a direct route to the same box.
Historical DNS — passive DNS services archive old A records indefinitely, including ones from before Cloudflare was added
Certificate transparency logs — any cert issued directly to the origin IP is permanently searchable by domain name
Mail headers — a Received header from a shared mail server can name the real IP in a single forwarded message
Unproxied subdomains — staging, api, or admin subdomains left with a direct A record while the main domain is proxied
Beyond those four, there's the option of just scanning. Services that continuously index the entire IPv4 space and fingerprint what's listening on each host let someone search for your exact TLS certificate, response headers, or favicon hash across every IP in a given hosting provider's range — Contabo, Hetzner, DigitalOcean, whichever — without needing your domain name at all. If your origin answers on 443 with the same certificate whether the request came through Cloudflare or not, that fingerprint is exactly what such a scan is built to find.
How do you check whether your own setup already leaks?
Each of the four leaks above has a specific, free way to check it yourself, and doing this once, honestly, is worth more than assuming the orange cloud has you covered. Certificate transparency is checked at crt.sh, searching your domain and every subdomain — anything listing a cert issued before Cloudflare was added, or issued directly rather than through Cloudflare's own certificate pipeline, points at an IP worth checking. Historical DNS is checked through any passive-DNS lookup service that indexes A-record history rather than current state. Mail is checked by sending yourself a test message from whatever's on that box and reading the full header block, not just what your mail client shows by default. And subdomains are checked by listing every DNS record in your Cloudflare dashboard and confirming the proxy status column actually says "Proxied" for each one — not just the ones you remember configuring. The XenGrowth resource library works through the operations side of this in more operational detail.
Leak vector | How to check it yourself | Fix |
|---|---|---|
Certificate transparency logs | Search crt.sh for the domain and every subdomain | Reissue any cert that was ever bound directly to the origin IP; don't reuse it once proxied |
Historical DNS | Query a passive-DNS history service for old A records | Nothing retroactive — this is why the firewall rule matters even after the record is fixed |
Mail headers | Send a test email from the box, read the full Received header chain | Route outbound mail through a separate provider (Resend, SES) instead of the origin itself |
Unproxied subdomains | List every DNS record in the Cloudflare dashboard, check the proxy-status column | Toggle every subdomain that resolves to the origin to Proxied, or firewall it identically |
So what actually hides the origin?
The origin refusing to answer anyone who isn't Cloudflare. That's a firewall rule, and it's the one piece of this whole picture that Cloudflare genuinely cannot do for you, because it lives on your server, not theirs. Cloudflare publishes its IPv4 and IPv6 ranges at a stable, machine-readable URL specifically so origins can build an allowlist from it, and the fix is exactly that: restrict inbound 80 and 443 to those ranges and deny everything else on those ports. Pull the list at setup and again periodically — the ranges do shift over time, and a hand-typed allowlist that never gets refreshed quietly turns back into an open port six months later without anyone noticing.
This is the same ufw mechanism covered for general hardening in how I secure a fresh VPS, pointed at a specific list instead of "allow 80/443 from anywhere." Once it's in place, a direct connection to the origin's IP on port 443 gets nothing back — not a certificate error, not a redirect, nothing. The connection just doesn't complete, which is a materially different outcome than "the site loads a slightly wrong page," and it's the difference between the origin being hidden and the origin merely being fronted.
What do Origin CA certificates add on top of the firewall rule?
A second lock, for the case where the firewall rule has a gap — a missed range, a misconfigured rule, a temporary lapse during a server migration. Cloudflare's free Origin CA issues a certificate that Cloudflare's own edge trusts specifically for the edge-to-origin leg of a request. No browser anywhere trusts Origin CA's root, which means that same certificate is useless to anyone who reaches the origin directly: their browser throws a certificate warning immediately, because as far as any public trust store is concerned, this certificate was never issued by anyone real. It doesn't stop the TCP connection from completing the way the firewall rule does, but it does stop that connection from ever looking like your site to whoever made it. XenGrowth on governed AI marketing workflows covers the AI agents and marketing automation side of this.
Authenticated Origin Pulls goes further and actually closes the connection rather than just making it look wrong. It's mutual TLS: Cloudflare presents a client certificate on every request to your origin, and the origin is configured to check for it and refuse anything that doesn't have it — meaning a request that isn't coming from Cloudflare's edge doesn't get a response at all, valid IP or not. It requires Full or Full (strict) SSL mode, since Cloudflare has to actually complete a TLS handshake with the origin to present that certificate in the first place, and it's available at the zone level, globally, or per hostname depending on how granular you need the rule to be.
Worth being precise about which SSL mode you're actually running, because "Full" and "Full (strict)" get used interchangeably and they're not the same guarantee. Full mode encrypts the edge-to-origin leg but accepts any certificate the origin presents, self-signed included — better than Flexible, which doesn't encrypt that leg at all, but it doesn't verify the origin is who it claims to be. Full (strict) requires the origin's certificate to be valid and trusted, which is exactly what an Origin CA certificate is for: it gives you something Cloudflare's edge will validate as genuinely trusted, without needing a publicly trusted cert on a box that the public should never be hitting directly in the first place.
And once the firewall rule is in place, verify it the same way you'd verify any firewall change: from outside the box, not from the box itself. A curl straight at the origin's IP on port 443, run from a different machine on a different network, should hang or refuse outright — no certificate warning, no wrong page, nothing. If it connects at all, the allowlist has a gap somewhere, and that's a more reliable signal than reading back your own ufw rules and assuming they're being enforced the way you wrote them. On AI search, GEO and discovery specifically, XenGrowth on building one SEO and GEO content system is worth reading.
Layer | What it actually stops | What it doesn't stop |
|---|---|---|
Orange-cloud proxying alone | A casual visitor from seeing the origin IP in DNS | Historical DNS, CT logs, mail headers, unproxied subdomains, direct IP scans |
Firewall restricted to Cloudflare's IP ranges | Any direct connection attempt on 80/443 from outside those ranges | A stale allowlist if the ranges change and you never refresh it |
Origin CA certificate | A direct connection from ever presenting as a valid, browser-trusted version of your site | The TCP connection itself — it still completes, it just can't pass a real TLS check |
Authenticated Origin Pulls (mTLS) | Any connection, valid IP or not, that can't present Cloudflare's client certificate | Nothing meaningful, if configured correctly — this is the strongest layer here |
Which of these do I actually need, and which is overkill?
The firewall rule isn't optional if "hidden origin" is a claim you actually want to make — everything else is a hedge against that rule having a gap, not a replacement for it. Origin CA plus Full (strict) SSL mode is cheap enough, and simple enough to set up, that I don't think there's a good reason to skip it once the firewall rule exists: it costs nothing and it means a misconfigured allowlist doesn't immediately become a working direct connection with a certificate warning as the only tell. Authenticated Origin Pulls is the one I'd call genuinely optional for a single small VPS running a handful of apps — real protection, but it adds a mutual-TLS configuration step on the origin that has its own failure mode if you get it wrong (Cloudflare can no longer reach your origin at all), and for most one-person setups the firewall rule plus Origin CA already closes the gap that actually gets exploited in practice.
None of this is a reason to skip proxying in the first place — unmetered DDoS protection and a managed WAF ruleset in front of a small origin are real, and I'm not walking that back. The point is narrower: "proxied" and "hidden" are two different claims, and most write-ups on this topic use the first word and mean the second one without ever doing the work that makes them the same thing. The firewall rule is that work. Skip it and the orange cloud is decoration, and a scanner indexing hosting-provider IP ranges for a matching TLS fingerprint doesn't care which word you used to describe your setup.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on governed AI marketing workflows — what you'll learn: how the teams running AI marketing agents keep them governed and measurable.
XenGrowth on building one SEO and GEO content system — what you'll learn: how search and AI-answer visibility get run as a single content system.
Where this work meets go-to-market
XenGrowth's marketing operations practice writes for the teams who have to run origin protection day to day.
Four questions on the difference between proxying traffic and concealing a server. Proxying is the easy half; the leaks are the interesting part.
