DEV Community

禾
禾

Posted on

Proxy Protocol vs Forwarded Headers: Preserving the Real Client IP Behind SafeLine WAF

#proxy #clientip #reverseproxy #checklist

Every WAF that runs as a reverse proxy faces one hidden data problem: the moment a connection passes through an intermediary, the source address that the protected application sees can change. SafeLine is a self-hosted WAF built on nginx that acts as an HTTP/HTTPS reverse proxy. It receives traffic for your origin website, cleans the malicious requests, and forwards only safe traffic to the original application (Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication). When you add an application in the console, you configure the domain, the port SafeLine listens on, and the upstream address where traffic is forwarded (Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication). What that dialog does not tell you is which side of the chain should be treated as the source of truth for the client IP.

This is a comparison between two common placement and configuration choices for keeping that client address accurate.

Choice A: SafeLine terminates connections directly

In this setup the traffic path is client -> SafeLine -> origin server. SafeLine is the first hop in your infrastructure, so it terminates the connection itself and is the endpoint that sees the original source address. The WAF logs, rate limiting, and blocking decisions all observe the real client IP without any extra header processing. This is the simplest path and matches the documented deployment model, in which clients pass through the WAF before reaching the server and you resolve your domain to the machine where SafeLine runs (Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

The tradeoff is architectural: SafeLine must be reachable directly, which can limit your ability to place a cloud load balancer, CDN, or network address translation layer in front of it. When a second proxy is introduced, the address SafeLine sees becomes the proxy address unless you deliberately carry the original address forward.

Choice B: SafeLine behind a load balancer or CDN

Here the path is client -> load balancer/CDN -> SafeLine -> origin server. The front proxy terminates the public connection, so by default SafeLine sees the front proxy IP rather than the client IP. To preserve the address you must choose how to carry it across that hop.

One option is the HTTP-layer approach: the front proxy appends a forwarded header such as X-Forwarded-For and the WAF is configured to trust that header only from known proxy addresses. This is easy to read and debug, but it is HTTP-specific and depends on a trust model, because an untrusted client can forge the header if the WAF accepts it from arbitrary sources.

Another option is Proxy Protocol, a small line-based preamble sent before the actual connection data. It preserves the original source and destination addresses at the transport layer and works even when the connection is a raw TCP stream. The tradeoff is that both ends must agree on the protocol, and misconfiguration can corrupt the handshake or leak addresses.

The supplied SafeLine documents describe SafeLine as an nginx-based reverse proxy and do not document a dedicated Proxy Protocol toggle or the exact header trust settings in the web console. For product-specific configuration, verify the current options in the official docs and console before enabling any of these mechanisms (Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

How to decide

  • Prefer Choice A when SafeLine is the only entry point: the client IP is correct by default and you avoid the header trust problem entirely.
  • Use the HTTP-layer forwarded header when the front proxy is HTTP/HTTPS only, when you can restrict which upstream addresses the WAF trusts, and when operators need visible, debuggable headers.
  • Use Proxy Protocol when you need transport-layer accuracy, when the hop between the front proxy and SafeLine must remain protocol-agnostic, or when header injection by untrusted clients is a concern.
  • Do not mix both without a clear policy. If the front proxy sends Proxy Protocol and the WAF is not configured to expect it, the connection fails. If the WAF accepts untrusted forwarded headers, attackers can spoof addresses and weaken logging, rate limiting, and access control.

Does SafeLine see the real client IP automatically?

When SafeLine terminates the connection directly, yes. It is the endpoint of the client connection and observes the source address natively. When another proxy sits in front, SafeLine sees that proxy address unless forwarded information is configured and trusted (Source: https://docs.waf.chaitin.com/en/home).

Should I use Proxy Protocol or X-Forwarded-For?

Choose X-Forwarded-For for simple HTTP-only chains where you can trust only known proxies. Choose Proxy Protocol when you need Layer 4 accuracy, when the connection may not be HTTP, or when you want the source address preserved independently of application headers.

Where do I enable these settings?

The official documents describe adding an application through Domain, Port, and Upstream fields in the web console (Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication). They do not document a specific Proxy Protocol setting, so confirm the supported mechanism for your installed version in the official documentation before enabling it.

What breaks if the client IP is lost?

Logs will record the proxy address instead of the client, rate limiting may group many users under one address, and any access control that relies on the client IP can make wrong decisions. Fixing the address path matters before those controls become critical.

Is trusting forwarded headers risky?

It can be. If the WAF accepts X-Forwarded-For from untrusted sources, a client can send a spoofed value and the WAF will log and act on a fabricated address. Always restrict the accepted header to known proxy addresses, or use Proxy Protocol so the address is delivered outside the HTTP request itself.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

Top comments (0)