Hiding Your Origin Server IP

"Should I put a CDN in front of it?" is the first question most people ask after buying an offshore server, and it has no single answer, because it is really two questions wearing one coat. Absorbing an attack and staying unfindable are different problems with different solutions, and the arrangement that solves one can quietly undo the other.

The confusion is expensive in both directions. People put a large American CDN in front of content they chose DMCA-ignored hosting for, and hand a complaints desk back to precisely the kind of intermediary they were avoiding. Others skip everything, get hit by an application-layer flood that network filtering was never designed to see, and conclude the DDoS protection was a lie. This guide separates the two problems, says what each layer genuinely does, and spends most of its length on the part that decides the outcome either way: the six ways an origin address leaks when everything else is configured correctly.

Two problems that look like one

Anything you put in front of a server is doing one of two jobs: keeping an attack away from it, or keeping its address unknown. They overlap enough to be confused and differ enough that solving the wrong one is a waste of money.

Read the last row twice, because it is the one that catches people. Everything else on this page is engineering. That row is not.

What your host already does, and where it stops

Layer 3 and layer 4 filtering is included on every plan we sell, at no extra cost, and it runs at the network edge rather than on your server — which is the only place it can work, since a saturated uplink cannot be fixed by anything running behind it. Bandwidth is unmetered, so an attack does not turn into an invoice. For the large majority of what people call "a DDoS", that is the whole story.

What it cannot see is the other kind. Five hundred requests a second to a search endpoint from forty thousand residential addresses is not malformed traffic; it is traffic. Slowloris connections that trickle a header every few seconds are, individually, polite. A login form hammered with real POST bodies is indistinguishable at the packet level from a busy Monday. No packet filter helps, because there is nothing wrong with the packets.

There is one direction of traffic we do act on, and it is worth stating plainly: attacks and mass spam originating from our network may be null-routed to keep the rest of the infrastructure healthy. That is an operational measure, not a content one — the distinction our DMCA-ignored hosting guide draws in more detail.

What a CDN hides, and the abuse desk you inherit

The mechanism is simple and genuinely effective. Your domain resolves to the provider's addresses, clients connect there, and the provider fetches from your origin. The real address never appears in a client's connection, so it cannot be attacked by anyone who only knows the domain. The same trick is why CDN fronting works for censorship-resistant proxies: a censor sees traffic to an address it cannot afford to block.

Three things arrive with it, and none is hidden in the small print:

• The edge terminates your TLS. Traffic is plaintext inside the provider's network by design — that is how caching and filtering work. Whatever your users type reaches a third party before it reaches you.
• An abuse channel that did not exist before. Complaints can be filed against the CDN directly, and a CDN answers them: by forwarding to you, by naming your hosting provider, or by terminating you. If your reason for being offshore is that complaints go nowhere, putting a US intermediary in front reconnects the chain you paid to break.
• An account. Email address, payment method, often a phone number, tied to your domain and kept indefinitely. More on that below, because it is usually the weakest link in the whole arrangement.

None of that makes a CDN wrong. It makes it a decision with two sides: excellent for a shop or an application with real users and real layer-7 pressure, actively counterproductive for publishing that attracts takedowns. Our own answer to the question on the DMCA-ignored hosting page has always been the short version of this: for takedown resistance, use the network filtering you already have and skip the CDN.

The six ways an origin address leaks anyway

This is the section that matters, because concealment is not a product you buy — it is a property you either maintain or lose, usually within days, to one of six things. Origins are found every day behind perfectly good CDN configurations.

• Certificate Transparency logs. Every publicly trusted certificate issued for your domain is published to public, permanent, searchable logs within minutes. They do not publish your address; they publish your hostnames — staging, mail, vpn, the subdomain you set up once in 2024. Each one is a candidate to resolve, and a single record that does not point at the front ends the exercise.
• DNS history. Passive-DNS services archive every address your domain has ever resolved to. Moving behind a CDN afterwards does not unpublish what was already recorded — concealment has to begin before the domain first resolves, or you need a new address, not a new front.
• Records that cannot be proxied, and the ones you forgot. Mail exchangers have to point at something reachable. So do an AAAA record left behind when you only proxied IPv4, an old FTP or panel hostname, a wildcard, or the "temporary" development host that is now three years old.
• Anything the server sends. Mail from the origin carries its address in the Received headers — a password-reset message is self-service disclosure. Webhooks, outbound image fetches, link previews, pingbacks, update checks and crash reporters all reach out from the real address, and anyone who can make your application talk to a host they control learns it.
• Whole-internet scanning. Every IPv4 address is scanned and indexed continuously by public services, and the results are queryable in seconds. If your origin answers on port 443 with your certificate, or serves your homepage to any Host header, matching it is one query against a body hash, a certificate fingerprint or a favicon hash. This is how most origins are found, and it costs the finder nothing.
• The application talking about itself. Absolute URLs and redirects containing the raw address, status or metrics endpoints left open, verbose stack traces naming internal hosts, headers that reveal the backend, and the default virtual host that cheerfully serves your site to anyone who asks by address.

Locking the origin so only the front can reach it

Concealment that depends on nobody guessing the address is not concealment. The arrangement only holds when the origin refuses to talk to anyone but the front, so that a leaked address is a nuisance rather than an event.

• Default-deny, then allow the front. Accept 80 and 443 only from the provider's published address ranges, and refresh that list automatically — the ranges change, and a stale list fails open or fails closed at the worst moment. Everything else, including SSH, belongs on a tunnel or a management address, as in our first-hour hardening checklist.
• Authenticate the front. Client certificates between the CDN and your origin — usually called authenticated origin pulls — mean that even a correct address plus a correct Host header gets nothing without the certificate.
• Better: no inbound ports at all. An outbound-only tunnel from the origin to the edge, whether the CDN's own connector or WireGuard to a node you run, means the origin never listens on a public interface. Scanning cannot find what does not answer, and this is the single strongest version of the arrangement.
• One virtual host, one Host header. The default server should return nothing useful. If your site loads by address, it will be matched by a scanner within the week.
• Move mail off the web origin. Mail has to be reachable and has to identify itself; keep it on its own machine, as the mail server guide assumes.
• Verify from outside. Every check in this list is meaningless run from the server itself. Test from a network that is not yours.

Your own front node instead of a CDN

The third option gets skipped because it has no marketing budget: a small VPS as the public face, an encrypted tunnel back to the machine that holds the data, and nginx or HAProxy passing traffic between them. From the outside it looks like any web server. The real one is somewhere else, with no inbound ports at all.

What you get is concealment with nobody else in the arrangement — no third-party account, no external abuse desk, no stranger terminating your TLS. You also get a jurisdiction split that is otherwise hard to buy: the front where the users are, the data where the law suits you, chosen from our seven locations. And because no identity was attached at signup, the front is disposable — a burned address is replaced in minutes rather than negotiated.

What you do not get is anycast capacity. One node has the capacity of one node, and while our network filtering protects it exactly as it protects any other server, a genuinely large volumetric attack is a bandwidth contest that a global network wins. The honest positioning: a front node is the right answer for hiding a heavy or expensive backend — a storage array, a GPU box, a mail server, a database — and for splitting jurisdictions. It is not a substitute for a CDN under sustained layer-7 pressure.

Choosing, in one table

The account is usually the weakest link

Consider what happens when the infrastructure is perfect and the paperwork is not. The server was paid for in Monero, with no identity documents and no email address — the arrangement described in our no-KYC hosting pages. Then a CDN account is opened with a card, a personal address and a phone number, listing the domain it protects. That account is a stronger, more durable identity record than anything on the server, held by a company that answers subpoenas, and it undoes the payment privacy entirely.

The fix is not complicated, only easy to forget: if anonymity is the goal, either the front belongs to you, or the account in front of it is as disposable and as unattributable as the server behind it. Server OpSec covers this discipline properly, and our honest answer on offshore anonymity is blunt about which links in the chain usually break first. They are almost never the technical ones.

Auditing your own exposure in ten minutes

Every item below is something an interested party would check in the first few minutes. Run them yourself, from a machine that is not the server, before you need the answers.

• List every hostname you have ever certified. Search your apex domain in a Certificate Transparency search engine and resolve each result. Anything not pointing at the front is a leak, including hosts you no longer use.
• Read your own DNS history. A passive-DNS lookup shows the addresses your domain resolved to before the CDN. If yesterday's origin is still today's origin, the concealment was never real.
• Ask the origin directly. curl -sI --resolve example.com:443:198.51.100.10 https://example.com/ — if the site answers, your firewall is not restricting the front and anyone with a candidate address can confirm it in one request.
• Ask it rudely. curl -skI https://198.51.100.10/ should return nothing recognisable. A default virtual host serving your homepage is the most common single mistake on this page.
• Check every record type, not just A. dig +short AAAA example.com, dig +short MX example.com, and the same for every subdomain the transparency logs revealed. IPv6 left unproxied is a classic.
• Mail yourself from the application. Trigger a password reset and read the full Received chain. If the origin address is in there, so is it in every message you have ever sent.
• Confirm the ports are shut. From an unrelated network, nmap -Pn -p80,443 198.51.100.10 should show filtered, not open.
• Search the scanners. Look up your certificate fingerprint and your homepage's favicon hash in a public internet-scan index. If your origin is indexed, that is how it will be found.

When the address is already burned

Assume it stays burned. An address that has appeared in passive DNS and in scan indexes is in permanent public record, and no configuration change retracts it. The response is mechanical rather than clever.

• Fix the leak first. Rotating to a new address without closing the hole reproduces the situation within days, and you will have spent a migration to learn nothing.
• Then rotate. Deploy a replacement — in a different jurisdiction if the reason was legal rather than technical — restore, and cut over. Because no identity was attached to the first server, this is a fresh start rather than a negotiation, which is the practical, unglamorous payoff of buying servers without an account history.
• Prepare the cutover before the emergency. A short DNS TTL, configuration you can redeploy from a repository and a tested restore turn a bad afternoon into twenty minutes. Nobody arranges this during an attack.
• Retire the old address properly. Do not park the old server on the old address serving the same content; that is a live confirmation for anyone watching, and it keeps the record fresh.

The short version

Network-level filtering handles volumetric attacks, comes with the server and costs nothing extra. A CDN handles the application layer and hides the origin, at the price of an intermediary that terminates your TLS, answers complaints and knows who you are. Your own front node buys concealment without the intermediary, but not global capacity. Jurisdiction decides the legal question and none of the three touches it. And all of them are undone by one unproxied record, one email from the origin, or one default virtual host.

Decide by goal rather than by habit, then spend the ten minutes on the audit — it finds more real exposure than any upgrade. If you want the architecture without the third party, a small VPS as a front and the real work on dedicated hardware behind it is the arrangement we see most often among people who have already been found once.