What Is a Reverse Proxy? TLS, Real Client IP and Security

What is a reverse proxy?

A reverse proxy is an intermediary that stands between clients and your server and speaks on behalf of the server, not the client. When a browser connects to example.com, it meets the proxy, not your application. The proxy takes the request, does the filtering and transformation it needs to, forwards the request to the server behind it (the origin) and returns the response to the client.

The model is not new. Software such as nginx and HAProxy has played this role for years. Security services such as Nexren Shield offer the same model as a service, together with layers such as a WAF and DDoS mitigation.

Forward proxy vs reverse proxy

A forward proxy controls how an employee on a company network reaches the internet. A reverse proxy takes requests arriving from the internet before they reach your servers. The client side often does not know which proxy sits behind.

What does the DNS change do?

The one required step to put a reverse proxy in place is DNS. Normally your example.com record resolves to your server's IP. With a reverse proxy, you point that record at the proxy's address:

example.com.   300   IN   CNAME   edge.proxy-provider.example.net.

From then on, the world sees the proxy's IP for example.com. Only the proxy knows your real server's IP (the origin IP). That makes attacks aimed straight at your server harder, but only if the origin IP has not leaked another way. We cover this in origin IP hiding and Origin Lock.

The DNS change takes time to propagate; during that time some clients go to the old address and some to the new. A low TTL shortens the switch.

TLS termination

To inspect HTTPS traffic, the proxy has to decrypt it. This is called TLS termination. TLS runs between the client and the proxy; the proxy decrypts the request, inspects it, then forwards it to the origin either re-encrypted or as plain HTTP.

Practical consequences:

• The proxy needs a valid certificate for your domain. Automatic SSL with Let's Encrypt shows how that happens automatically.
• You should encrypt the connection between proxy and origin too; otherwise traffic travels in the clear on that leg.
• Termination puts the proxy where it manages the TLS handshake, which makes it possible to observe the TLS stack a client uses.

Caching

A reverse proxy can store static responses (images, CSS, JS) and serve them without asking the origin. Origin load and response time drop. Watch for one thing: personalized content must not slip into the cache. Restrict the cache rule explicitly for responses that carry a session cookie, and make sure you can purge the cache when content changes.

Security model: gains and costs

Gains

• One control point. WAF rules, rate limits and bot verification run in one place; you do not set them up in every application.
• The origin stays hidden. The server's IP and topology can stay closed to the outside.
• The proxy absorbs connection load. It manages slow clients and the TLS handshake. DDoS attack types explains what that does against attacks such as slowloris.
• Error masking. Detailed error pages can be scrubbed before they leave.

Costs

• A new dependency. If the proxy goes down, your site becomes unreachable too. Make sure you can accept that.
• Extra latency. Each request takes one more hop.
• Transferred trust. The proxy provider decrypts your traffic, so you have to trust that provider. Read what it stores in its privacy notice.
• The real-IP problem. The origin now sees the proxy, not the client. We cover that next.

Real client IP and X-Forwarded-For

On the origin, logs and application code always show the proxy's IP. The real client IP travels in an HTTP header. The common one is X-Forwarded-For; its standardized counterpart is the Forwarded header in RFC 7239.

The trap: a client can send this header itself. If you trust it blindly, an attacker writes a fake IP and slips past your rate limit or IP allowlist. The fix is to trust the header only on connections that come from your proxy. In nginx:

# Trust X-Forwarded-For only on connections from the proxy
set_real_ip_from 203.0.113.10;
real_ip_header X-Forwarded-For;

Replace 203.0.113.10 with your proxy's real egress addresses (it is an example TEST-NET address here). If you run a chain of proxies, also read the real_ip_recursive option in the ngx_http_realip_module documentation.

WebSockets

A WebSocket connection starts as a normal HTTP request and turns into a long-lived channel through the Upgrade header (RFC 6455). If a reverse proxy does not pass these headers, the connection fails. Long-lived connections can also run into the proxy's idle timeout; if you have a live chat or notification feature, test it before you cut over.

When is a reverse proxy unnecessary?

Not every site needs a reverse proxy. If you publish only a public, static page and your server already sits behind a CDN or hosting provider's protection, an extra proxy adds only latency and complexity. A reverse proxy earns its place when you have an exposed and critical surface: an admin panel, an API, a payment flow, or an application whose updates can lag.

Locking the origin to the proxy

The benefit of a reverse proxy depends on an attacker being unable to bypass it. Two measures work together: open ports 80 and 443 on the origin firewall only to proxy addresses, and verify at the origin a secret header the proxy adds to every request. Origin IP hiding and Origin Lock walks through both step by step.

Sources

• RFC 7239: Forwarded HTTP Extension
• RFC 6455: The WebSocket Protocol
• MDN: X-Forwarded-For
• nginx: ngx_http_realip_module

Related product pages:Technology Help center