Explains why backend instances may become unhealthy when enabling PROXY Protocol on Vultr Load Balancers without proper backend configuration
When you enable the PROXY Protocol on a Vultr Load Balancer, the load balancer adds a header containing the original client’s IP address and port before forwarding traffic to your backend instances. If the service on the instance is not configured to parse and accept PROXY protocol headers, it interprets the extra data as invalid and responds with errors, often 400 Bad Request. This causes the health checks to fail, and the instance is automatically marked unhealthy and removed from the routing pool.
To resolve this, configure your backend service to support PROXY protocol if you require the client’s real IP. The exact steps depend on your software stack:
proxy_protocol directive on the listening socket.accept-proxy option on the bind line.RemoteIPProxyProtocol directive.If your application stack does not support PROXY protocol, leave the feature disabled on the Vultr Load Balancer. You can still obtain the client IP from the standard X-Forwarded-For header, which the Vultr Load Balancer inserts by default.
For detailed configuration steps, refer to the official documentation for your web server or proxy software. See NGINX Proxy Protocol configuration, Apache RemoteIPProxyProtocol directive, and HAProxy accept-proxy usage.