A10 X-forwarded-for Now

Unlike XFF, which is HTTP-specific, PROXY Protocol prepends a binary header at the transport layer. It preserves the original client IP for any protocol—HTTP, HTTPS, SMTP, or raw TCP. If your backend server supports PROXY Protocol (e.g., HAProxy, Nginx, Apache 2.4.30+), this is a more robust solution than XFF. X-Forwarded-For on A10 Networks devices is a powerful but subtle tool. When configured correctly—preferably with replace mode to block spoofing—it restores end-to-end visibility. However, it shifts responsibility to the backend developer to parse headers securely.

If your backend server reads only the first IP (leftmost) as the client, it will believe the request is coming from 127.0.0.1 (localhost)—bypassing all ACLs. a10 x-forwarded-for

In the modern data center, the Application Delivery Controller (ADC) sits as the gatekeeper. A10 Networks’ Thunder series is a market leader in this space, performing tasks from server load balancing (SLB) and SSL offload to advanced L7 inspection. Unlike XFF, which is HTTP-specific, PROXY Protocol prepends

When configured for L7 load balancing (HTTP mode), the A10 ADC rewrites the HTTP request headers before forwarding the packet to the real server. It typically appends the original client IP address to the existing XFF header. X-Forwarded-For on A10 Networks devices is a powerful

If a backend server receives requests from multiple clients over the same persistent connection from the A10, the XFF header will change per request . Your backend application code must be designed to parse the XFF header on every HTTP request, not just at the TCP connection establishment. Java HttpServletRequest.getRemoteAddr() will still return the A10’s IP; you must explicitly call getHeader("X-Forwarded-For") . Blindly trusting the first XFF value you see is a common and dangerous anti-pattern.

However, by inserting itself between the client and the server, an ADC creates a classic networking paradox: