What is the difference between X-Forwarded-For and Proxy Protocol?
Short answer
X-Forwarded-For carries the client IP with a header added to every HTTP request; it is turned on only on an HTTP vService, in the Details list of the vService, and the traffic works even if the server does not support it (the header is ignored). The PROXY protocol carries the client IP and port with preliminary information sent at the beginning of the connection; on HTTP and L7 TCP vServices, it is turned on in the Proxy field of the Backend Service (Proxy or Proxy v2), it also works with non-HTTP protocols, but if the server does not support it, connections cannot be established.
How Does It Work?
- X-Forwarded-For: TR7 adds the
X-Forwarded-For: <client-ip>header to every HTTP request it forwards to the Backend Service. The source of the connection remains TR7; the server reads the client IP from the header. - PROXY protocol: At the very beginning of every TCP connection it opens to the Backend Service, before the application data, TR7 writes a short piece of preliminary information carrying the client's IP and port and the destination address: in text format (v1) with the Proxy option, and in binary format with the Proxy v2 option. The server reads this preliminary information and then processes the data that follows in the normal way.
Comparison
| X-Forwarded-For | PROXY protocol | |
|---|---|---|
| Layer | HTTP header | Preliminary information at the beginning of the connection |
| Where it is enabled | vService → Details → X-Forwarded-For | Backend Service → Details → Proxy |
| Scope | That vService | All the vServices that use that Backend Service |
| vService type | HTTP only | HTTP, L7 TCP |
| Options | On / off (off by default) | No Proxy (default) / Proxy / Proxy v2 |
| If the server does not support it | The header is ignored, the traffic works | The server takes the preliminary information for application data; connections cannot be established |
| Health check | Not affected | The check does not send preliminary information; an HTTP check fails on a port that expects PROXY (the TCP type or a separate health port is used) |
| Information carried | Client IP | Client IP and port, destination IP and port |
In TR7
- HTTP applications: X-Forwarded-For is the easiest way; the server is only set to read the header (How is X-Forwarded-For enabled; what do I need to do on the backend side (Apache / Nginx / IIS logs)?).
- Non-HTTP TCP protocols (SMTP, IMAP, database): the PROXY protocol, if the server supports it (How do I pass the real client IP for non-HTTP TCP services?).
- Using them together: Both can be turned on at the same time; since one is written to the HTTP header and the other to the beginning of the connection, they do not conflict.
- Network vService: It does not use the Proxy field of the Backend Service; the client IP is preserved with the LB mode (Network vService · LB Mode).
Common Misconceptions
- "TR7 also accepts the PROXY protocol coming from clients." TR7 sends the PROXY protocol to Backend Services; on the vService, there is no option that accepts PROXY preliminary information coming from the client. If there is a proxy in front of TR7, the client IP is resolved with Trusted Proxy.
- "Turning on the PROXY protocol is harmless." If the server is not ready, connections cannot be established; the server is configured first.
- "The PROXY protocol is used on a Network vService." A Network vService does not use this field.
How it is done in the documentation
