生产环境真实IP透传需按协议层级匹配方案：七层用X-Forwarded-For并配合set_real_ip_from等可信源验证，四层用PROXY Protocol或LVS TOA；必须逐跳配置、抓包验证、伪造测试，杜绝无条件信任头部。
生产环境配置负载均衡器的真实IP透传，核心在于协议层级匹配和可信链路控制。不能只加一个X-Forwarded-For就认为万事大吉——后端若直接信任该头，可能被伪造；若完全不处理，又丢失溯源能力。关键是在透传与过滤之间取得平衡。
按协议层级选透传方式
四层（TCP）和七层（HTTP/HTTPS）的透传机制完全不同，混用会导致502错误或IP丢失：
-
七层负载均衡（如HAProxy HTTP mode、Nginx proxy_pass）：依赖HTTP头传递真实IP。必须启用
option forwardfor（HAProxy）或proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for（Nginx），并确保后端服务（如应用日志、WAF、数据库连接池）明确从该头读取IP，而非REMOTE_ADDR。 -
四层负载均衡（如HAProxy TCP mode、LVS DR/FullNAT）：无法插入HTTP头，必须用协议级方案。推荐
PROXY Protocol（HAProxy配send-proxy，后端Nginx/TiDB需开启proxy_protocol on）；LVS场景则需在后端服务器加载TOA内核模块解析TCP选项字段。 -
混合架构（如CDN → HAProxy → Nginx → 应用）：每一跳都必须参与透传。CDN回源时应带
X-Forwarded-For，HAProxy需forwardfor追加自身IP，Nginx用set_real_ip_from指定可信代理段，最终由real_ip_header X-Forwarded-For提取最左非代理IP。
后端服务必须做安全过滤
透传只是第一步，不验证来源就信任头部，等于把防火墙钥匙交给攻击者：
-
禁止无条件信任X-Forwarded-For：任何后端Web服务器（Nginx/Apache/Tomcat）都不得直接使用
$http_x_forwarded_for做访问控制。必须配合set_real_ip_from（Nginx）或RemoteIPInternalProxy（Apache mod_remoteip）声明哪些IP是可信代理，再启用递归解析。 -
数据库场景特别注意：TiDB、MySQL等默认只认TCP连接的
peer address。若用HAProxy四层转发，必须开启proxy-protocol支持，并在TiDB配置中显式设置proxy-protocol.networks白名单（如10.2.103.92/32），否则会拒绝连接或记录错误IP。 -
日志与审计分离处理：原始日志保留
REMOTE_ADDR（代理IP）和X-Forwarded-For全字段；分析时通过ETL清洗出真实IP。这样既满足合规留痕要求，又避免运行时误判。
生产上线前必验三件事
配置写完不验证，等于没配：
-
抓包确认协议行为：用tcpdump在后端服务器抓包，Wireshark中查看TCP流是否含PROXY header（十六进制
0D0A0D0A00000000开头）或HTTP请求是否含正确X-Forwarded-For: 客户端IP，排除中间设备（如防火墙、WAF）篡改。 -
模拟伪造头测试防御：curl手动加
-H "X-Forwarded-For: 1.1.1.1"访问，检查后端记录的IP是否仍是真实客户端IP，而非伪造值。若失败，说明set_real_ip_from未覆盖全部代理节点或顺序错误。 -
监控透传成功率：在负载均衡器上统计
proxy_protocol解析失败数（HAProxy的pxcurs指标）或Nginx的realip_failed计数器。持续为0才代表链路稳定。
透传不是功能开关，而是端到端的信任链设计。每增加一层代理，就要多一份set_real_ip_from配置、一次抓包验证、一轮伪造测试。省掉任一环，安全和可观测性都会打折扣。
