How to Hide Your Origin IP Behind a DDoS Proxy, and Keep It Hidden

A DDoS protection proxy works by standing between the internet and your server. Visitors connect to the proxy, the proxy filters the traffic, and only clean requests are forwarded to your origin. It protects exactly one thing: the address the attacker aims at. If an attacker knows your origin's real IP, they send the flood there directly and the proxy never sees it.

So putting a site behind a proxy is two jobs. The first is pointing DNS at the proxy. The second, the one most set-ups skip, is making sure the origin's address cannot be found, and that the origin refuses web traffic from anyone but the proxy when it is found. This guide is about the second job: how to hide origin IP addresses, how to check that you have, and what to do when a leak gets through anyway.

Why the origin address leaks at all

Your origin had a public life before the proxy arrived. It answered DNS queries, sent mail, fetched updates and presented certificates to anyone who asked. Each of those left a record somewhere, and several of those records are searchable. These are the eight leaks, roughly in the order attackers check them.

1. DNS history

When you switch your A record to the proxy, the old record does not disappear. Passive DNS services record historical answers, and anyone can look them up. If your origin keeps the address it had before the proxy, assume that address is already known. The fix is cheap: move the origin to a new IP once the proxy is in place. On a NexonHost dedicated server an additional IPv4 address costs €3 a month.

2. Certificate Transparency

Every publicly trusted TLS certificate is written to public Certificate Transparency logs, and Chrome requires it: in CT-enforcing versions of Chrome, a publicly trusted certificate that is not logged fails validation. Search tools over those logs, such as crt.sh, list every hostname you have ever requested a certificate for. That is how names like origin.example.com, staging.example.com and direct.example.com get found.

Certificates list names, not addresses, but a forgotten subdomain that resolves straight to the origin is a published address. Search your own domain in a CT log search, resolve every name it returns, and make sure each one is either proxied or points somewhere harmless.

3. The certificate your origin serves

Internet-wide scanning services continuously connect to public IPv4 addresses and record what answers, including the TLS certificate presented. If your origin answers anyone who connects by IP and presents your production certificate, a scan database can already map your domain to your origin's address. The proxy never enters into it.

This is the leak a firewall closes completely, as described below. As a second layer, configure the web server's default virtual host to present a self-signed certificate for a meaningless name, so a connection to the bare IP learns nothing.

4. Mail

Mail is the most common leak on small sites. The MX record names your mail server, the SPF record often lists your origin's IP directly, and every message your server sends carries its address in the Received: headers. An attacker who triggers one password-reset email from your site has your origin. Relay outbound mail through a separate host or a transactional mail service, and take the origin's IP out of SPF.

5. Outbound requests

Anything that makes your server connect out to an address an attacker controls reveals the source IP. WordPress pingbacks are the classic case: under the Pingback specification, the receiving server fetches the source page to verify the link, so a stranger can make your origin call their machine on demand. Webhooks to user-supplied URLs, link-preview generators and remote image fetchers do the same. Turn pingbacks off (the WordPress DDoS protection guide covers XML-RPC in more detail) and send unavoidable outbound traffic through a separate egress address.

6 to 8. IPv6, error pages and old code

• IPv6. A proxied A record next to an unproxied AAAA record is a common oversight. Proxy both, or publish neither.
• Headers and error pages. Debug headers such as X-Backend-Server, framework error pages and server-status pages can print internal and external addresses. Turn them off in production.
• Published code. Configuration committed to a public repository, or a page captured by a web archive before the switch, stays public. Treat any IP that has ever been published as burned.

Lock the door, not just the address

Hiding the address is not enough on its own, because leaks are hard to rule out completely. The durable fix is making the origin refuse web traffic from anyone except the proxy. Allow ports 80 and 443 only from the proxy's published address ranges, and drop everything else.

Here is a minimal nftables ruleset. The documentation ranges stand in for your proxy's real ranges, and 192.0.2.10 for your own admin address; apply it from a console session so a mistake cannot lock you out.

table inet origin {
  set proxy_v4 {
    type ipv4_addr
    flags interval
    elements = { 203.0.113.0/24, 198.51.100.0/24 }
  }
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    meta l4proto { icmp, ipv6-icmp } accept
    tcp dport { 80, 443 } ip saddr @proxy_v4 accept
    tcp dport 22 ip saddr 192.0.2.10 accept
  }
}

A dropped connection also tells a scanner nothing about what is running behind it. Once the firewall is in place, restore real visitor addresses at the web server so your logs and rate limits still work; getting real visitor IPs on your backend shows how.

The origin still needs protection against floods that reach it directly, because a firewall rule is evaluated on your server, after the traffic has used your port. On a NexonHost dedicated server, 40 Gbps / 4 Mpps of layer 4 mitigation is included upstream, so an origin whose address does leak is not facing the attack alone.

Test it from the outside

1. From a machine that is not the proxy, run curl -vk --connect-timeout 5 https://ORIGIN_IP/ -H "Host: example.com". It should time out.
2. Search your domain in a Certificate Transparency log search and resolve every name it returns.
3. Look up your MX and SPF records, send yourself an email from the site, and read the Received: headers.
4. Check that no AAAA record points at the origin.
5. Search public code repositories for your origin's IP.

If any of these finds the origin, close the leak first and change the address second. Changing the address before closing the leak just publishes the new one.

Where to start

NexonHost's DDoS protection proxy plans start at €49 a month for 3 TB of clean traffic with 10 Gbps of layer 4 absorption, and go up to unmetered clean traffic with 100 Gbps included, expandable to 1 Tbps, on the €710 Enterprise plan. Remote DDoS protection extends the same protection to servers and applications as well as websites. For the origin itself, a dedicated server with mitigation included and a fresh IP address is the cleanest start. How a DDoS protection proxy works explains the filtering layers, and the new server security checklist covers the rest of the hardening.

Specifications and pricing are as of 28 September 2026 — check the product pages for current figures.

Sources

• RFC 6962: Certificate Transparency, IETF, June 2013; now obsoleted by RFC 9162. Retrieved 28 September 2026.
• Chrome Certificate Transparency Policy, Google Chrome. Publicly trusted certificates must be CT-compliant to validate in CT-enforcing versions of Chrome. Retrieved 28 September 2026.
• crt.sh, Certificate Transparency log search. Retrieved 28 September 2026.
• Pingback 1.0, Stuart Langridge and Ian Hickson. The receiving server fetches the source URI to verify the link. Retrieved 28 September 2026.
• NexonHost store: remote protection plans, additional IPv4 pricing and included DDoS mitigation on dedicated servers. Retrieved 28 September 2026.