通过代理IP访问自有接口时，如果服务端看到的 Host、Via 或 X-Forwarded-For 与预期不同，不要把所有变化都归咎于代理。请求可能经过客户端库、正向代理、反向代理、负载均衡和应用框架，每一层都有机会添加、删除或重写头部；HTTPS 使用 CONNECT 隧道时，隧道内的HTTP头和外层代理请求也不是同一层。
先画出请求链路和信任边界
在自有系统中，至少区分四个角色：客户端、正向代理、入口网关、应用。记录每层能看到的请求ID、连接来源和必要的头部摘要，不要把完整Cookie、Authorization或用户数据写入日志。只有明确某个网关是可信入口，应用才可以把它传入的转发头当作真实来源。
Host与SNI分别解决什么
- Host：HTTP层的目标主机和端口，影响虚拟主机路由。
- SNI：TLS握手中的服务名，影响证书和TLS虚拟主机选择。
- CONNECT目标：HTTP代理请求中要求建立隧道的主机和端口。
HTTPS经CONNECT建立隧道后，代理通常只转发加密字节，不能直接看到隧道内的Host；如果代理终止TLS或使用明文HTTP转发，则责任边界不同。出现证书正确但应用路由错误时，要分别查看SNI、Host和入口网关路由日志。
X-Forwarded-For和Via不能盲信
X-Forwarded-For通常由反向代理追加客户端地址链，Via用于标识消息经过的协议中间层。它们不是天然可信的身份凭证：客户端可以自行发送同名头，未经清洗的公网入口也可能把伪造值传给应用。自有网关应在受信任边界删除外部传入的转发头，再按实际连接地址重新生成，并明确应用只信任哪些网关。
用请求头对照验证责任层
准备一个只返回请求头摘要的自有测试端点，分别使用直连、正向代理和反向代理访问。固定请求方法和目标URL，只比较以下字段：
- 客户端发送的原始Host和自定义请求头。
- 正向代理入口收到的CONNECT或HTTP请求。
- 反向代理转给应用的Host、Via、X-Forwarded-For和请求ID。
- 应用最终记录的连接对端地址和可信代理链。
如果变化只发生在某一层，就在该层修正配置；不要在应用里用字符串替换“看起来不对”的头部。
常见错误与风险
- 把客户端传入的X-Forwarded-For直接当作真实用户IP。
- 修改Host后忘记同步入口路由或TLS SNI，导致证书或虚拟主机错误。
- 正向代理和反向代理重复追加Via，日志难以还原链路。
- 为测试“匿名性”关闭所有审计头，破坏自有系统的追踪能力。
代理IP能改变网络出口，但不会自动让HTTP头、TLS特征和应用身份策略消失。正确做法是建立受信任边界、清洗不可信头，并用分层日志验证实际路径。
验收清单
- 记录每层的请求ID和头部摘要，敏感值全部脱敏。
- 明确Host、CONNECT目标和SNI分别在哪一层产生。
- 只信任指定网关生成的X-Forwarded-For和Via。
- 直连、正向代理、反向代理三组对照结果一致且可解释。
- 应用日志能够同时关联入口、代理和目标请求，而不依赖客户端自报地址。
