关键是要后端原生支持proxy协议解析，因其在tcp层传输、早于http请求，nginx需用listen proxy_protocol启用并用$proxy_protocol_addr提取真实ip，否则后端会因收到“proxy”前缀而返回400错误。
要让后端服务器正确解析 Nginx 通过 PROXY 协议传递的真实客户端 IP，关键不是“解析头部”，而是启用对 PROXY 协议 的原生支持——因为 PROXY 协议本身不是 HTTP 头，而是在 TCP 连接建立初期、HTTP 请求正文之前发送的一段二进制或文本格式的元数据（如 PROXY TCP4 192.168.1.100 10.0.0.1 54321 80）。Nginx 用 proxy_protocol 指令开启该功能，后端服务必须主动启用对应解析能力，否则会把 PROXY 行当作非法 HTTP 请求直接拒绝。
确认 Nginx 正确启用了 PROXY 协议转发
在 Nginx 的 upstream 或 listen 配置中，需显式启用 proxy_protocol：
- 若使用
upstream块转发到后端，需在 server 块的 listen 指令后加proxy_protocol，且后端监听端口也必须支持 PROXY 协议（如 HAProxy、某些 Node.js 框架、或配置了 proxy protocol 的 Nginx 自身） - 典型配置示例：
server {<br> listen 8080 proxy_protocol;<br> location / {<br> proxy_pass http://backend;<br> proxy_set_header X-Real-IP $remote_addr;<br> proxy_set_header X-Forwarded-For $proxy_protocol_addr;<br> }<br>} -
$proxy_protocol_addr是 Nginx 内置变量，仅在启用proxy_protocol时有效，它已从 PROXY 行中提取出原始客户端 IP
后端服务必须原生支持 PROXY 协议解析
多数 Web 应用框架（如 Express、Spring Boot、Django）默认不处理 PROXY 协议，它们只认 HTTP 头。因此不能靠加个 X-Forwarded-For 就完事，而要：
- 使用支持 PROXY 协议的反向代理前置（如再套一层 HAProxy，或用 Nginx 自己做终节点）
- 或选用原生支持的运行时：例如 Node.js 的
http模块需配合proxy-protocol中间件；Go 的net/http需用github.com/pires/go-proxyproto包包装 listener；Java 的 Netty 可集成io.netty.handler.codec.proxy - Tomcat 从 8.5+ 开始支持，在
Connector中设置proxyPort="80" protocol="org.apache.coyote.http11.Http11NioProtocol"并启用remoteIpHeader="x-forwarded-for"不够——必须搭配protocol="org.apache.coyote.http11.Http11NioProtocol"+proxyProtocol="true"
避免常见误区：别把 PROXY 协议和 HTTP 头混为一谈
PROXY 协议与 X-Forwarded-For 等头字段无关：
- PROXY 协议在 TCP 层传输，早于任何 HTTP 数据；HTTP 头是应用层内容
- 如果后端没开启 PROXY 协议支持，收到的第一个字节就是
P（PROXY），会被当作非法 HTTP 请求，直接报 400 错误 -
proxy_set_header X-Real-IP $proxy_protocol_addr是给“不支持 PROXY 协议但信任 Nginx”的后端用的，属于降级方案，不是 PROXY 协议本身的要求
验证是否生效的简单方法
用 telnet 或 nc 手动模拟 PROXY 行，观察后端响应：
echo -e "PROXY TCP4 1.1.1.1 2.2.2.2 12345 80\r\nGET / HTTP/1.1\r\nHost: example.com\r\n\r\n" | nc your-backend-ip 8080- 若返回正常 HTML，说明后端已正确解析；若返回 400 或连接重置，说明 PROXY 协议未启用或配置不匹配
- 也可在后端日志中打印原始 socket 远程地址，对比是否等于 PROXY 行中的客户端 IP
