PROXY Protocol solves a common problem in proxied network architectures: the transport connection reaching an application does not necessarily identify the original client. A load balancer can accept a client connection and establish another connection to a target, making the load balancer appear to be the source. PROXY Protocol adds metadata describing the original connection, typically including source and destination addresses and ports. It conveys this information to the receiving application without changing the source address in the backend connection's IP packets.
The two main versions have different encodings. Version 1 uses a human-readable text line, while version 2 uses a binary header and supports optional type-length-value fields for additional metadata. For TCP connections, the sender places the header at the beginning of the backend connection, before application data. The receiver must explicitly support the version being sent and consume the header before handing the remaining bytes to its application-protocol parser.
For example, an organization might place a TCP load balancer in front of an NGINX or HAProxy fleet serving a custom application. If targets see only the load balancer's source address, client-based audit records and rate limits become misleading. Enabling PROXY Protocol on the load balancer and its backend listener lets the proxy recover the reported client address. The application or proxy must then be configured to use that recovered address rather than automatically treating the socket peer address as the end user.
In AWS, Network Load Balancer supports PROXY Protocol version 2 through the target-group attribute proxy_protocol_v2.enabled. Classic Load Balancer supports version 1 through a policy associated with the relevant backend ports for TCP or SSL listeners. Application Load Balancer instead provides HTTP client-address information through headers such as X-Forwarded-For; it does not provide PROXY Protocol support. For exam questions, distinguish the load balancer type, supported protocol version, backend compatibility, and whether native client IP preservation already meets the requirement.
PROXY Protocol is not an HTTP header and does not require HTTP inspection. With TLS passthrough over TCP, its header precedes the TLS ClientHello on the backend connection. The backend must therefore parse the PROXY header before starting TLS processing. Sending it to a listener that expects TLS or application data immediately commonly causes handshake failures or malformed-request errors. Conversely, a listener requiring the header can reject ordinary connections that omit it.
The metadata is not inherently authenticated or encrypted. Restrict access to PROXY-aware backend listeners to trusted senders, using appropriate security groups, firewall rules, and network isolation. Otherwise, a client that can connect directly may supply forged client-address information. The reported address also does not change what security groups or network ACLs observe in packet headers.
Validate health checks and application traffic separately during deployment. For Network Load Balancer, enabling version 2 also adds PROXY headers to health-check connections, but those headers do not carry client connection information. Finally, do not confuse this option with cross-zone load balancing, sticky sessions, or routing algorithms: those control traffic distribution, while PROXY Protocol communicates connection identity and metadata.
Amazon EC2