How your origin server IP leaks even behind a proxy: 6 ways
The premise of DDoS protection looks simple: route traffic through a proxy, the attacker only ever sees the proxy, your real server stays hidden. In practice, protection usually fails not because of the proxy but because the address escapes somewhere else. These are the six leaks that show up most often in the real world.
1. The DNS records you left behind
You put the main domain behind the proxy, but mail, ftp, cpanel, webmail and direct still carry old A records pointing straight at the box. Trying a few hundred common subdomains is the first thing an attacker does — and it usually works.
mail record pointing directly at the origin is close to the default state of the internet.2. DNS history
Before you moved to a proxy, your domain pointed straight at the server, and that record is sitting in passive DNS archives. Cleaning up today's record does not erase yesterday's. If the server is still on that old address, your protection exists only on paper.
There is exactly one real fix: move the server to a new IP address as part of the migration. It is inconvenient. The alternative is protection that does not protect.
3. Certificate transparency logs
Every TLS certificate issued gets written to public Certificate Transparency logs. Those logs do not expose addresses, but they do expose every subdomain you have ever certified. So staging.example.com or panel.example.com, which you assumed nobody knew about, is right there — the attacker does not even need to guess.
4. Email sent from the server
Password resets and order confirmations sent directly from your application server carry the server's real IP in the Received header. An attacker signs up on your site, receives one email, and reads the address off it.
The fix: send outbound mail through a separate email service, never from the application server.
5. Leaving the origin firewall open
This is not a leak so much as the thing that makes every leak matter. You moved to a proxy, but the server still accepts connections on ports 80 and 443 from anywhere on earth. The moment the address gets out, the attacker skips the proxy entirely.
Your server should accept connections only from your proxy addresses. That single rule largely neutralises the first four items on this list: the address can leak and still be worthless.
6. The application giving itself away
Error pages, phpinfo output, status endpoints and some admin panels print the server's own address on screen. In the same family: any feature that makes outbound requests on demand — "fetch image from URL" is the classic — can be pointed at an attacker-controlled address, and that request arrives carrying your origin IP.
Checklist
| Leak | How to check | Permanent fix |
|---|---|---|
| Subdomain records | List every A/AAAA record | Proxy them all, or delete them |
| DNS history | Search passive DNS archives | Move the server to a new IP |
| Certificate logs | Search CT logs for your domain | Use a wildcard certificate |
| Email headers | Send yourself a test message | Use an external email service |
| Open firewall | Try connecting to the IP directly | Allow proxy addresses only |
| Application output | Review error and status pages | Turn off debug output |
With OZELNS the proxy and your DNS live in the same panel, so records that are not behind the proxy are visible on one screen instead of three. If you are just starting, migrating your DNS covers the next step.
Protect your site with OZELNS
Authoritative DNS and reverse-proxy DDoS protection in one panel. Free plan available, no card required.
See plansTalk to us