负载均衡打开PROXY Protocol后，所有HTTPS请求瞬间变成502，后端日志出现“plain HTTP request sent to HTTPS port”或TLS握手乱码。原因通常不是证书突然失效，而是后端把连接开头的PROXY元数据当成了TLS或HTTP业务字节。
PROXY Protocol解决什么问题
四层负载均衡转发TCP时，后端看到的连接来源往往是负载均衡地址。PROXY Protocol在业务数据之前附加原始源地址、目标地址和端口，让后端恢复连接元数据。它不是加密协议，也不会自动验证这些字段真实性。
v1和v2有什么区别
| 版本 | 编码 | 特点 |
|---|---|---|
| v1 | 可读文本行 | 易观察，但功能与长度较有限 |
| v2 | 二进制头 | 紧凑，可扩展更多地址族与TLV |
发送端与接收端必须使用双方支持的版本。接收端如果根本没启用，任何版本都会破坏后续协议。
为什么会表现为TLS失败
正常TLS连接第一个记录有固定格式；启用PROXY Protocol后，前面先出现PROXY头。只有知道这一点的监听器才会先解析元数据，再把剩余字节交给TLS。把普通TLS客户端直接连到强制PROXY的端口，同样会被拒绝。
Nginx或应用监听要对应
接收组件通常需要在具体listen上启用proxy_protocol，并另行配置从哪个变量取真实地址。只开启解析却没有设置真实IP，日志仍可能记录负载均衡地址；只设置real_ip_header但监听未解析，则连接会在更早阶段失败。
健康检查为何也会坏
负载均衡的健康检查可能直接发HTTP或TLS，不带PROXY头，而后端监听强制要求它；反过来也可能检查带头，后端不接受。根据产品能力，让检查使用一致协议，或建立只对负载均衡开放的独立健康端口。
链路上有多层代理怎么办
外层负载均衡发送PROXY Protocol，内层代理终止后如果再连接上游，需要决定是否重新生成元数据。不能把未经验证的客户端字段一路复制。每一跳都要记录直接对端、声明源地址和信任决策。
安全边界比解析更重要
任何能连接后端PROXY端口的主机都可能声明“原始来源是127.0.0.1”或受信地址。通过防火墙、安全组和监听绑定，只允许指定负载均衡连接；应用只信任这些直接对端。真实IP头的通用信任原则可参考多层代理真实客户端IP排查。
与HTTP头如何共存
PROXY Protocol提供连接层地址，反向代理之后还可能生成Forwarded或X-Forwarded-For。应用使用哪一个取决于架构。应由最靠近应用的受信代理规范化HTTP头，避免将连接层与用户提交的同名头混为一谈。
切换如何避免全站中断
- 确认负载均衡和后端共同支持的版本；
- 建立新监听或测试节点，不在原端口直接硬切；
- 验证普通HTTP、HTTPS、长连接和健康检查；
- 限制新端口只接受受信负载均衡来源；
- 灰度切流并对比真实IP、错误率和TLS握手；
- 保留快速回退，稳定后下线旧监听。
排查证据
在授权环境抓取连接最初几十字节，能直观看到是否有PROXY前缀或v2签名。结合监听配置、负载均衡属性、健康检查模式和防火墙来源，比只看应用502更准确。抓包中可能包含真实地址，应限制传播。
结论
PROXY Protocol必须由发送端、接收端和健康检查协同启用。它能传递真实连接地址，但只有在后端端口隔离和可信来源明确时才可靠；配置不对称时，最先坏掉的往往就是TLS或HTTP解析。
