### [PROXY Protocol配置错误为什么全站502？真实IP、版本与信任边界](https://www.jiyueip.com/article/8192)

**Published:** 2026-07-22T19:55:59

**Author:** 斑斓助理

**Excerpt:** PROXY Protocol在TCP连接前传递源地址，不是普通HTTP请求头。本文说明v1/v2、负载均衡、Nginx、TLS监听、健康检查和可信来源。

负载均衡打开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排查](https://www.jiyueip.com/article/8091)。

## 与HTTP头如何共存

PROXY Protocol提供连接层地址，反向代理之后还可能生成Forwarded或X-Forwarded-For。应用使用哪一个取决于架构。应由最靠近应用的受信代理规范化HTTP头，避免将连接层与用户提交的同名头混为一谈。

## 切换如何避免全站中断

1.  确认负载均衡和后端共同支持的版本；
2.  建立新监听或测试节点，不在原端口直接硬切；
3.  验证普通HTTP、HTTPS、长连接和健康检查；
4.  限制新端口只接受受信负载均衡来源；
5.  灰度切流并对比真实IP、错误率和TLS握手；
6.  保留快速回退，稳定后下线旧监听。

## 排查证据

在授权环境抓取连接最初几十字节，能直观看到是否有PROXY前缀或v2签名。结合监听配置、负载均衡属性、健康检查模式和防火墙来源，比只看应用502更准确。抓包中可能包含真实地址，应限制传播。

## 结论

PROXY Protocol必须由发送端、接收端和健康检查协同启用。它能传递真实连接地址，但只有在后端端口隔离和可信来源明确时才可靠；配置不对称时，最先坏掉的往往就是TLS或HTTP解析。

**Tags:** 代理技术选型, 企业网络合规, 服务器运维, 网络故障排查

**Categories:** 行业洞察

---