Correct Use of Proxy Protocol in L4 Load Balancing

TL;DR

In L4 load balancing, the original client connection often terminates at the edge. The backend initially only sees the IP address of the load balancer. The Proxy Protocol transmits the original connection data as preliminary metadata. For this to work reliably, the edge, target protocol, and backend must have the same expectation regarding format, position, and trust boundary.

Introduction

An L4 load balancer can accept a TCP connection and then establish a new connection to the backend. From the backend’s perspective, the direct communication partner is no longer the original client but the load balancing layer. This means a central piece of information is missing for logging, access control, rate limiting, or forensic analysis: the original client IP.

The Proxy Protocol solves this issue not by changing the actual application protocol but by adding a connection header before its payload. This is also its main limitation: the recipient must expect and correctly process this header. If the handover is activated only on one side, the connection fails, or the protocol is interpreted as invalid payload.

1. What Information the Proxy Protocol Transmits

In traditional L4 load balancing, transport connections are considered separately. The edge accepts the client’s connection, decides on a backend based on routing and health check information, and establishes its own backend connection. TCP does not automatically transmit the original source address across this boundary.

The Proxy Protocol therefore adds connection metadata at the start of the backend connection. This typically includes source and destination addresses, the ports used, and the transport protocol. This allows the backend to distinguish between the actual client IP and the IP address of the edge.

It is important to differentiate from HTTP headers like X-Forwarded-For: these work on Layer 7 and require an HTTP proxy to understand the request. Proxy Protocol is transmitted before the actual protocol and is therefore suitable for TCP-based services or TLS passthrough. However, it does not replace application authentication and is not an independent security control.

2. The Protocol Boundary Between Edge and Backend

The Proxy Protocol is not part of TCP itself. It is transmitted as additional information at the beginning of the connection established by the load balancer to the backend. The first recipient on the backend path must read this information before processing the actual protocol.

This creates a clear compatibility requirement. A web server, database service, ingress, or upstream proxy must be configured for Proxy Protocol . If the service directly expects a TLS handshake, HTTP data, or another binary protocol, the additional header may appear as faulty payload. This is particularly relevant for TLS passthrough: the backend TLS endpoint must accept the proxy header before the ClientHello.

The variant used must also match. Text-based and binary versions differ in format and parsing behavior. The edge and the immediately receiving service must therefore support the same variant. A downstream proxy must not inadvertently pass the header again as normal payload.

3. Client IP, Logging, and Security Boundaries

The forwarded client IP is only trustworthy if the backend controls the source of the connection. A publicly accessible service that accepts Proxy Protocol headers from any clients can adopt manipulated origin data. Backend cloaking and appropriate network rules are therefore important accompanying measures: the application should ideally only accept connections from the designated edge systems.

For logging, it must be clearly defined which address is documented. The transport peer IP remains the address of the edge and can be relevant for network and connection diagnostics. In contrast, the address contained in the Proxy Protocol describes the original client. Both values should not be semantically mixed.

Additionally, downstream components should only reuse the information within the intended trust zone. An application may use the client IP for audit data or policy decisions but should not automatically treat it as an authenticated identity. If multiple proxies are chained, it must be clear which hop generates the header and which evaluates it.

4. Operation and Integration in L4 Load Balancing

Activating Proxy Protocol is an end-to-end change for the backend connection. A single listener or a single backend cannot be considered in isolation. In failover, rolling updates, and parallel backend pools, all potential targets must meet the same expectation. Otherwise, switching to another pool leads to hard-to-explain protocol errors.

A step-by-step approach is recommended for commissioning: first, document the actual connection path, then identify the receiving service, and finally test the header processing specifically. A packet capture or connection-level debugging can show if the header arrives; however, the application settings decide whether it is correctly interpreted.

The ayedo Edge Cloud supports Proxy Protocol as part of its L4 load balancing. This allows the original connection information to be passed to the backend even with provider-independent use in self-managed or other provider-operated Kubernetes clusters. It remains crucial that the respective service or ingress supports the chosen handover and is only accessible from the trusted edge zone.

Practical Scenario: TCP Service Behind a Distributed Edge

A company operates a TCP-based service in two Kubernetes clusters from different providers. The ayedo Edge Cloud distributes incoming connections via Anycast to the appropriate backend pool. Without Proxy Protocol , the service logs only the edge connection as the source address. This is insufficient for capacity analysis and abuse investigations.

With Proxy Protocol enabled, the first TCP-capable recipient reads the header and then forwards the actual payload to the service. Both clusters must accept the same variant; direct test access without a header must be excluded or handled separately. If a pool fails, the failover path must also be compatible. The architecture thus gains usable client metadata without having to rebuild the application-side protocol itself.

FAQ

Is Proxy Protocol only suitable for HTTP?

No. It operates before the application protocol and can also support TCP services or TLS passthrough. However, the respective backend endpoint must be able to explicitly process the header.

Does Proxy Protocol replace X-Forwarded-For?

No. X-Forwarded-For is an HTTP or Layer-7 mechanism. Proxy Protocol transmits connection data already at the Layer-4 boundary and is not dependent on HTTP.

Does every backend need to support Proxy Protocol ?

Every first recipient of such a backend connection must support it or remove it beforehand. Otherwise, the service interprets the header as invalid protocol data.

Conclusion

Proxy Protocol is a precise solution for a typical problem of separate TCP connections: the backend receives information about the original client, even though the edge must terminate and rebuild the connection. The benefit arises only with a consistent trust chain of edge, protocol variant, backend, and network access. In the L4 load balancing of the ayedo Edge Cloud, this handover is particularly relevant when services are operated independently of the compute provider and still need to evaluate their client IP.