Hide Your Origin IP and Lock the Origin: Leaks and Fixes

Why does an origin IP leak matter so much?

With a reverse proxy, visitors connect to the proxy, not to your server. The WAF, DDoS mitigation and bot verification all run on that path. If an attacker learns your real server address (the origin IP), they skip the whole path and send requests to an unprotected machine.

That makes the origin IP the weakest link in a reverse proxy setup. The guide what a reverse proxy is shows how traffic flows. This article covers the leak vectors, why "just hiding it" fails, and the lasting fix.

How does the origin IP leak?

Attackers rarely need a clever exploit. They usually find the address by reading public records. These are the most common sources.

• Historic DNS records. Before you moved behind the proxy, your domain pointed at the server. Services that archive DNS history keep that A record.
• Forgotten subdomains. mail., ftp., direct., cpanel. or dev. hosts that bypass the proxy resolve to the origin IP.
• MX and SPF records. If the mail server shares a machine with the web server, the MX record or an ip4: entry in SPF exposes the address.
• Outbound mail headers. The Received header of any message your server sends carries the sender IP. A password reset or notification e-mail is enough.
• Certificate transparency logs. Every certificate is written to public logs together with its domain names, as defined in RFC 9162. A forgotten name such as staging.example.com appears there and may resolve straight to the server.
• Forgotten staging hosts. Test servers that never moved behind the proxy often sit in the same IP range.
• Internet-wide scan data. Services that scan the whole IPv4 space index which IPs present your certificate on port 443. A domain name in the certificate leads to the origin.

Application-level leaks exist too: error pages, phpinfo() output, and response headers that print a server name or internal IP.

Why is hiding not enough?

Even if you clean up everything above, past records persist. You cannot delete archived DNS history or a logged certificate. An address that leaked once stays at risk until you make it useless.

Hiding relies on the assumption that nobody knows the address. The lasting fix assumes they do and makes it irrelevant: the origin accepts requests only from the proxy. You get there with three methods.

Fix 1: Firewall allow-list of proxy IPs

Open ports 80 and 443 on the origin only to the proxy's IP addresses and drop everything else. This works at L3/L4: the attacker's packet is discarded before it reaches the HTTP layer, so SYN floods and similar attacks create no work on your server.

Example with UFW (the IPs are placeholders; use your proxy provider's real addresses):

sudo ufw allow from 203.0.113.10 to any port 80,443 proto tcp
sudo ufw allow from 203.0.113.11 to any port 80,443 proto tcp
sudo ufw deny 80/tcp
sudo ufw deny 443/tcp

Mind the rule order: add the allow rules first. Keep your SSH port open, or you lock yourself out.

Fix 2: Secret header check

The proxy adds a secret header to every request, known only to you and the proxy. Your web server rejects any request where the header is missing or wrong. An attacker who knows the address but not the header gets a 403.

nginx lowercases header names and turns hyphens into underscores, so you read X-NexrenShield-Key-abc123 as $http_x_nexrenshield_key_abc123. The header name and value below are placeholders; on your own site, use the name and value your proxy adds.

server {
    listen 443 ssl;
    server_name example.com;

    if ($http_x_nexrenshield_key_abc123 != "SECRET") {
        return 403;
    }
    # ...
}

Keep in mind:

• Do not commit the value to a repository; load it from an environment variable or a separate file.
• Never echo the header in responses or write it to access logs.
• Rotate the value if it leaks.
• This check is L7: the connection opens, the TLS handshake completes, and only then the request is refused. It does not stop volumetric attacks.

Fix 3: Authenticated origin pulls

A stronger method is mutual TLS (mTLS). The proxy presents a client certificate when it connects, and the origin accepts only that certificate. A header can leak; stealing a client certificate's private key is much harder. Not every proxy provider offers this, and it requires certificate management. Most teams therefore start with the allow-list and the header check.

What should you do after a leak?

If you suspect the address is exposed, work in this order:

1. Find and close the source: the old A record, the open subdomain, the MX entry.
2. Turn on the firewall allow-list and the secret header check.
3. If possible, change the origin IP. Request a new address from your provider and release the old one.
4. Send mail from a separate server or a dedicated sending service so mail headers do not point to the web server.
5. Rotate the secret header value.

Changing the IP alone does not fix anything: if the source stays open, the new address leaks the same way. Order matters: close first, then change.

sudo bash protect-origin.sh --dry-run          # preview the rules without applying them
sudo bash protect-origin.sh --ssh-port 2222    # name your non-standard SSH port
sudo bash protect-origin.sh --revert           # remove the isolation and reopen the ports

Checklist

Finally, test it: curl -I https://203.0.113.50 -H "Host: example.com" --insecure, run against your own origin IP, should return 403 or time out. A 200 means the origin is still open.

Sources

• RFC 9162: Certificate Transparency Version 2.0
• nginx: ngx_http_core_module, embedded variables

Related product pages:Help center Technology