七层用X-Forwarded-For解析最左IP，四层必须启用Proxy Protocol v2；后端需配合realip模块或proxy_protocol指令，并严格配置可信网段，否则易被伪造。
负载均衡接入后，后端服务默认看到的是负载均衡器的 IP，而不是客户端真实地址。要准确获取真实 IP，关键在于匹配负载均衡类型（四层 or 七层）和后端协议，并启用对应的标准透传机制。
HTTP/HTTPS（七层）：用 X-Forwarded-For 头部
ALB、ELB、CLB 等七层负载均衡器默认会在请求中添加 X-Forwarded-For 头，格式为：
X-Forwarded-For: 客户端IP, 代理1IP, 代理2IP
后端服务需解析该字段最左侧的 IP（即第一个逗号前的部分）作为真实客户端 IP。
- 确保负载均衡监听已开启“通过 X-Forwarded-For 获取客户端 IP”（多数云厂商默认开启）
- 后端 Web 服务器（如 Nginx、Apache）不需改连接层变量，只需在日志或业务逻辑中读取该头
- 若有多层代理（如 CDN + ALB），需在每层都信任并追加该头；否则可能被截断或伪造
- 推荐配合 mod_remoteip（Apache） 或 set_real_ip_from + real_ip_header（Nginx） 模块，自动提取并覆盖 $remote_addr 变量，避免业务代码重复解析
TCP/UDP（四层）：用 Proxy Protocol v2
四层负载均衡（如 NLB、TCP 监听的 ALB）不处理 HTTP 头，因此不能用 X-Forwarded-For。必须启用 Proxy Protocol v2，它在 TCP 连接建立初期插入一段二进制头部，携带客户端源 IP 和端口信息。
- 在负载均衡侧开启“Proxy Protocol”支持（部分云平台需手动开启，如 NLB 的监听与后端服务器组需同时启用）
- 后端服务必须主动解析 Proxy Protocol —— 常见方案包括：
- Nginx：配置
proxy_protocol on;并在 listen 指令后加proxy_protocol - HAProxy：默认支持，需在 backend 中配置
option forwardfor配合send-proxy-v2 - 自研服务：使用支持 Proxy Protocol 的 SDK 或库（如 Go 的
github.com/armon/go-proxyproto）
- Nginx：配置
- 注意：Proxy Protocol 必须端到端启用，中间任何不兼容组件（如未配置的防火墙、旧版 Nginx）都会导致连接失败
特殊场景与注意事项
某些组合下，标准方式可能失效，需额外判断：
- IPv6 客户端访问 IPv4 后端：NLB 等四层设备需强制启用 Proxy Protocol，仅靠客户端地址保持无效
-
WAF + 负载均衡串联：优先以 WAF 提供的头为准（如
X-Real-IP或Cf-Connecting-IP），再 fallback 到 X-Forwarded-For - 容器化后端：即使获取到真实 IP，也仅能定位到 Pod 所在节点 IP，无法穿透到容器内部网络（除非使用 HostNetwork 或 CNI 支持）
- 安全风险提醒：X-Forwarded-For 可被客户端伪造，务必只信任来自已知负载均衡或代理网段的请求头；Proxy Protocol 因位于 TCP 层起始位置，相对更难篡改
验证是否生效的小技巧
部署一个简单接口（如 /debug/ip），返回以下内容便于排查：
- 原始连接 IP（如 Nginx 的
$remote_addr） - X-Forwarded-For 头全部值
- 最终提取出的“客户端真实 IP”
- 是否命中可信代理网段（用于判断 real_ip_header 是否触发）
通过 curl 加不同头模拟请求，对比输出，能快速定位是负载均衡未注入、后端未解析，还是信任网段配置错误。
