Learning centre

Protection

6 min readUpdated

How to hide your origin IP address

Quick answer

Putting a proxy in front of your site only protects you while attackers do not know the address behind it. If your origin IP is discoverable, an attacker can send traffic straight to it and every protection you are paying for is bypassed. Hiding it properly takes two things: removing the places it leaks from, and firewalling the server so it only accepts traffic from your provider — because the second one keeps working even after the first one fails.

Why this matters more than it sounds

A reverse proxy protects you by being the only reachable path to your application. Traffic goes to the proxy, gets inspected, and only what survives is forwarded. Attackers know this, so the first step of a serious attack is often not sending traffic at all — it is finding the address behind the proxy.

Once they have it, everything downstream is irrelevant. Your WAF rules, rate limits and mitigation capacity are all attached to a path the attacker no longer uses.

The usual ways an origin leaks

Almost every exposure is historical or incidental rather than a live misconfiguration, which is why it survives so long unnoticed.

  • Old DNS records — an A record for a subdomain you stopped using, still pointing at the real server
  • Unproxied subdomains — mail, ftp, cpanel, direct, dev and staging are the classics
  • Certificate transparency logs — every public TLS certificate is logged, so a cert issued directly to the origin reveals its hostname
  • Email headers — mail sent from the same machine carries its address in Received headers
  • Error pages and debug output that print internal hostnames or addresses
  • Historical DNS databases that keep records long after you change them
  • Outbound connections from your server to an endpoint an attacker controls

The step that actually protects you

Everything above reduces the chance of discovery. The measure that survives discovery is refusing traffic from anywhere except your provider.

Configure the origin firewall to accept connections on your web ports only from your provider's published address ranges, and drop everything else. An attacker who learns your address then finds a server that will not talk to them — the leak becomes a piece of trivia rather than a vulnerability.

Default-deny on the web ports, allowing only the proxy
# allow established traffic and loopback first
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

# allow your proxy's ranges (repeat per range)
iptables -A INPUT -p tcp --dport 443 -s <PROVIDER_RANGE> -j ACCEPT
iptables -A INPUT -p tcp --dport 80  -s <PROVIDER_RANGE> -j ACCEPT

# everything else to the web ports is dropped
iptables -A INPUT -p tcp --dport 443 -j DROP
iptables -A INPUT -p tcp --dport 80  -j DROP

A practical checklist

  • Audit every DNS record, including subdomains you forgot about — anything unproxied is a live exposure
  • Send mail through a separate provider so headers never carry your web server's address
  • Avoid issuing public certificates directly to the origin hostname; use DNS validation through the proxy
  • Turn off debug output and verbose error pages in production
  • Restrict the origin firewall to your provider's ranges and verify it by connecting directly
  • Search historical DNS databases for your domain to see what is already published
  • Change the origin address after fixing leaks, not before

For non-HTTP services

A reverse proxy only covers HTTP. Game servers, mail hosts and VPN endpoints need the same protection through routing instead: traffic reaches the provider's addresses, is filtered there, and is delivered to your machine through a GRE tunnel.

The result is the same — the address the world sees belongs to the provider, and your real address never appears in public routing at all.

Frequently asked questions

Last updated