TL;DR
Proxy Protocol transmits connection information from a proxy or load balancing layer to the backend. This allows applications to evaluate the original client IP and other transport data. Prerequisites include a coordinated protocol, compatible listeners, and consistent configuration across the entire backend pool.
Introduction
Proxy Protocol is not an optional detail in load balancing but an integration contract between the edge and backend. When activated on the ayedo Edge Cloud, every target system in the corresponding backend pool expects the additional protocol line before the actual application communication. A standard TCP or HTTP listener cannot automatically interpret this data. The result can be rejected connections, incorrect client IP evaluation, or hard-to-trace differences between individual backends. Therefore, it is crucial not only whether Proxy Protocol is generally supported but whether the edge, protocol type, listener, and application share the same assumptions about the connection setup.
1. What Information Proxy Protocol Conveys
A proxy terminates the original TCP connection of the client and establishes a new connection to the backend. Without additional metadata, the backend initially sees the source address of the edge system. For access controls, rate limits, audit logs, or forensic analysis, this information may be insufficient.
Proxy Protocol supplements the new connection with connection information from the original session. This typically includes source and destination addresses as well as the ports used. The backend can thus distinguish between the edge connection and the original client without having to derive this information from application-specific headers.
It is important to differentiate from HTTP headers like X-Forwarded-For: Proxy Protocol operates at the transport layer and is therefore relevant for TCP services as well. However, it does not replace authentication and does not prove that the transmitted data comes from a trusted source. The backend should only accept Proxy Protocol on the designated, controlled entry.
2. The Backend Pool as a Protocol Contract
Activating Proxy Protocol is a feature of the interaction between edge and backend pool. The ayedo Edge Cloud can forward connections via Proxy Protocol to backends. Whether these connections are successfully processed then depends on the listener of the respective target system.
A backend pool should therefore not only be modeled based on reachability, port, and health check. The expected connection form is also part of the pool definition. All targets of a pool must fulfill the same protocol contract: They must accept Proxy Protocol at the used listener and correctly pass the subsequent data to the service.
A common mistake is mixing incompatible targets. A pool might contain an Ingress configured for Proxy Protocol and additionally a direct TCP service. The load balancer can technically reach both targets, but only one understands the connection initiation. Health checks can be misleading if they use a different listener or testing methodology than the actual traffic. Protocol compatibility must therefore be explicitly tested.
3. Protocol Compatibility Along the Connection
Proxy Protocol is transmitted before the actual payload. The receiving listener must recognize, process this information, and then pass the original data stream to the application. If the listener is designed exclusively for unaltered TLS, HTTP, or proprietary TCP data, it interprets the proxy header as invalid payload.
This affects multiple layers: the external listener of the Ingress, a possible sidecar or reverse proxy, and the actual application process. Even a single incompatible intermediate component can terminate the connection. With TLS, it is particularly important that Proxy Protocol arrives before the TLS handshake and that the TLS listener supports this order. Proxy Protocol does not encrypt the metadata itself.
The variant used must also match. The text-based and binary variants differ in structure and parser behavior. If an edge expects a variant that the listener does not support, there is no reliable fallback. Therefore, protocol variant, transport type, and listener behavior belong in the technical interface description of the service.
4. Systematically Avoiding Operational Errors
The most common errors arise from configuration changes without considering the entire pool. If Proxy Protocol is activated at the edge but only part of the backends are adjusted, outages initially appear as random health or network problems. In reality, availability then depends on which target the load balancer selects.
For operations, separate pools with clear protocol behavior are usually more robust than a mixed pool. Migrations should proceed step-by-step: first provide a compatible listener, then test with realistic connections, and only then add more targets. Logs must make the connection setup at the listener, the recognized client address, and possible parser errors visible.
Special attention should be paid to the trust boundary. A backend should only use the source address contained in Proxy Protocol for security decisions if only known edge paths can reach this listener. If the same port is directly accessible from the internet or uncontrolled networks, an attacker can inject false connection information. Proxy Protocol thus improves transparency but does not replace network segmentation and access control.
Practical and Operational Scenario
A company operates an HTTPS service on Kubernetes and a TCP-based legacy service on virtual machines. Both should be accessible via the ayedo Edge Cloud. For the HTTPS service, an Ingress is used whose listener understands Proxy Protocol. The legacy service, on the other hand, continues to use a standard TCP listener.
It would be wrong to manage both target systems in a common backend pool: the ayedo Edge Cloud would deliver the same connection setup to different listeners. Instead, separate pools with appropriate protocol agreements are defined. The HTTPS pool processes Proxy Protocol up to the compatible Ingress; the legacy pool only receives connections whose target system actually supports the agreed transport. A separate health check per pool additionally checks the correct listener and not just the host's reachability.
FAQ
Is Proxy Protocol only relevant for HTTP services?
No. Proxy Protocol operates at the transport layer and can also provide TCP services with original connection information. However, the respective listener must explicitly support the protocol.
Can Proxy Protocol be replaced by HTTP headers?
In HTTP, forwarding headers can transmit client information. However, this is not equivalent for TCP services and requires trust in the header chain. Proxy Protocol lies below the application layer.
Why do health checks work despite faulty Proxy Protocol?
A health check can use a different port, listener, or connection setup than the productive traffic. Reachability alone does not confirm that the backend service processes Proxy Protocol correctly.
Conclusion
Proxy Protocol is a clearly definable integration point between edge proxy and backend service. The technical question is not only whether client IP information is needed, but which listener processes it in which form and under what trust boundary. In the ayedo Edge Cloud, this decision is part of the backend pool coordination. Cleanly separated pools, compatible listeners, and appropriate health checks prevent a small protocol deviation from becoming an intermittent operational problem.