Hide Your Origin Server IP: Proxies, CDNs and Leaks

Putting a CDN or reverse proxy in front of a site absorbs traffic and hides the server's address, but only as long as the real IP stays unknown. Attackers rarely break the CDN. They look for the origin directly. This guide lists where origins leak and how to make the origin refuse everything except your proxy.

How origins get found

• DNS history: services keep old records, so an IP you used before adding the CDN is still listed.
• Subdomains: mail., ftp. or dev. records that point straight at the server.
• Email headers: outbound mail from the same host reveals its IP in the headers.
• Certificate transparency and internet scans: scanners match a certificate to every IP that serves it.
• Application behaviour: webhooks, image fetchers and "check this URL" features connect out from the origin.

Step 1: start clean

If the server has already been exposed, the safest fix is a new IP, or a new server and migration. Hiding an address that is already public does not work. Plan the move with the no-downtime migration guide.

Step 2: accept traffic only from the proxy

Allow web ports from the proxy's published ranges and nothing else. With UFW this looks like the following, using the ranges your provider publishes.

sudo ufw default deny incoming
sudo ufw allow OpenSSH
for ip in $(cat proxy-ranges.txt); do sudo ufw allow from "$ip" to any port 443 proto tcp; done
sudo ufw enable

Refresh the list on a schedule, since ranges change. For stronger assurance use authenticated origin pulls (mutual TLS) so Nginx rejects any client without the proxy's certificate.

Step 3: separate everything that can leak

• Send email through a different host or relay, never from the origin.
• Keep non-web subdomains off the origin IP.
• Make outbound fetches from the application go through a proxy or a separate worker.
• Serve a default Nginx server block that returns an empty reply on an unknown Host, so a scan of the bare IP shows nothing.

server {
    listen 443 ssl default_server;
    ssl_reject_handshake on;
}

Step 4: test like an attacker

Search for your domain in DNS history tools, scan your own IP range for the certificate and check mail headers from a test message. If any of them show the origin, change the IP and repeat.

Remember what this does and does not do: it protects availability and privacy of the address. It does not hide who owns the account. For that, read how anonymous hosting really is, and for attacks that get past the network layer see Layer 7 defences.