Correctly Using Proxy Protocol in L4 and L7 Operations

TL;DR

The Proxy Protocol transmits connection information such as the original client IP across a proxy or load balancing connection. Different integration requirements apply in L4 and L7 operations. It is crucial that the backend service expects the protocol, evaluates it correctly, and does not confuse it with regular HTTP headers.

Introduction

A backend does not automatically see the address of the actual client. Once an edge platform establishes a new connection to the target system, the edge initially appears as the communication partner. This is architecturally intended but can become problematic for access control, rate limiting, audit logs, or forensic analyses. The Proxy Protocol solves this problem by having the edge pass connection information to the backend before the actual payload. However, this function is not merely a technical setting on the load balancer: it forms an integration contract between edge and backend. If activated on one side and not expected on the other, it results in faulty connections rather than better logs.

1. What the Proxy Protocol Actually Transmits

The Proxy Protocol supplements a backend connection with metadata about the original connection. This typically includes source and destination addresses as well as the ports used. As a result, the backend can recognize the client IP, even though the TCP connection was technically established by the edge cloud.

It is important to distinguish this from a transparent network connection: the Proxy Protocol does not change the source address at the IP level. It transmits the information within a protocol prefix that precedes the actual application protocol. Therefore, the backend service or a preceding listener must be able to interpret this prefix.

For ayedo Edge Cloud, the Proxy Protocol is a function within the backend connection. The edge continues to handle public traffic ingress, routing, and distribution. The backend receives additional connection information but remains hidden behind the edge. This combination supports backend cloaking without eliminating the need for reliable logging and security information.

2. L4: Connection Information Without HTTP Processing

In L4 load balancing, the edge operates at the transport layer. It distributes, for example, TCP connections without needing to evaluate the application content at the HTTP level. This is relevant for TLS passthrough, databases, proprietary TCP protocols, or other services where the edge should not terminate the application content.

In this scenario, the Proxy Protocol is inserted at the beginning of the backend TCP connection. Therefore, the backend endpoint must anticipate the prefix before the actual protocol handshake. A service that immediately expects a TLS, SMTP, or proprietary handshake may otherwise interpret the connection as corrupted.

The client IP remains available to the backend process, even though the edge forwards the connection. At the same time, the backend infrastructure must ensure that only trusted upstream systems are allowed to deliver proxy information. If a publicly accessible service accepts arbitrary proxy headers, an attacker could forge source addresses and manipulate IP-based rules or logs.

3. L7: Proxy Protocol Before HTTP or TLS

In L7 operations, the edge typically terminates an HTTP or HTTPS connection and then establishes a separate backend connection. Without additional information, the backend only knows the address of the edge. This is true even if the original client IP is known within the edge itself.

The Proxy Protocol can place this information at the beginning of the new backend connection. The backend listener must read the prefix and then forward the expected protocol to the appropriate service. For HTTP, this means: first comes the Proxy Protocol prefix, followed by the request line and headers. For an encrypted backend connection, processing must match the chosen TLS architecture.

Proxy Protocol and HTTP headers like X-Forwarded-For are not the same. Headers belong to the application layer and must be evaluated by the HTTP stack. The Proxy Protocol precedes this and can be useful even if a preceding TCP listener, ingress, or service mesh initially handles the connection at the transport level. Therefore, the decision depends on the actual backend path, not solely on whether the public service uses HTTP.

4. The Integration Contract Between Edge and Backend

Activating the Proxy Protocol is only successful if both sides have the same expectations. Technical coordination must include at least the listener type, protocol variant, transport protocol, port, and the point at which the information is removed or passed on.

A common mistake is activating it on the edge service while the backend service still expects an unchanged HTTP or TLS protocol. The service then interprets the first bytes of the proxy prefix as payload. Conversely, a proxy or ingress listener without Proxy Protocol support will discard a connection if it cannot process the additional preamble.

Health checks must also be considered. A backend may accept regular connections with Proxy Protocol but treat check connections differently. For stable operations, health checks must meet the same relevant connection conditions as the productive traffic. Logging and security systems should also document the trusted source from which the client IP originates. Only then does the information remain reliable across multiple backend connections.

Practical and Operational Scenario

A company operates an HTTPS service on a Kubernetes cluster outside of ayedo Managed Kubernetes. The ayedo Edge Cloud handles TLS termination and forwards requests to an ingress in the cluster. For security logs and IP-based access controls, the ingress must receive the original client IP.

One possible implementation is passing it via HTTP headers. The entire HTTP path must treat these headers as trustworthy. Alternatively, a preceding listener could accept the Proxy Protocol and then forward the connection to the HTTP ingress. This approach can be useful if client information is needed before HTTP processing. It is crucial that exactly one configured entry point processes the prefix. If it is additionally passed to a service not intended for it, the request will fail.

FAQ

Does the Proxy Protocol Replace X-Forwarded-For?

No. The Proxy Protocol transmits metadata before the application protocol. X-Forwarded-For is an HTTP header. Which variant is suitable depends on where in the backend the client IP is needed and processed.

Does Proxy Protocol Work with TLS Passthrough?

Fundamentally, it can be used before a TLS connection. However, the receiving listener must process the Proxy Protocol prefix before the TLS handshake and then correctly forward the connection to the TLS service.

Can Any Backend Directly Evaluate the Client IP?

No. The specific listener, reverse proxy, ingress, or service must support and have the Proxy Protocol activated. Otherwise, the prefix will be treated as unknown or invalid payload.

Conclusion

The Proxy Protocol is not a switch for “better logs” but a binding component of the connection between edge and backend. In L4 operations, it protects client information across transport-based forwarding; in L7 operations, it complements the newly established backend connection after termination. The ayedo Edge Cloud can pass this information to backend connections — but the result is only reliable with a properly configured and secured backend listener.