后端为什么看到的都是中间设备地址
请求经过 NAT、负载均衡、反向代理或 WAF 之后，链路层的源地址已经变成上一跳设备的地址，后端应用日志里全是同一个地址，风控、审计与故障定位都无从下手。解决方式分两类：HTTP 场景通过转发头传递原始地址，非 HTTP 场景使用代理协议在四层携带源地址信息。使用的前提是明确信任边界——转发头可以被伪造。
基本信息
| 适用平台 | nginx、HAProxy 等代理，以及 WAF 与负载均衡设备 |
|---|---|
| HTTP 方案 | X-Forwarded-For 逐跳追加，X-Real-IP 记录最近一跳 |
| 非 HTTP 方案 | PROXY protocol 在四层携带原始源地址 |
| 安全前提 | 只信任已知代理层追加的地址，按代理层数从左或从右取值 |
典型使用场景
- 应用日志分析：需要按真实客户端地址统计来源与访问行为
- 访问控制：安全策略与黑白名单必须基于真实源地址判断
- 风控与限速：按客户端而非按中间设备做频率限制
- 审计留存：合规要求记录真实访问来源，转发头方案是常见落地方式
- 故障定位：定位某个客户端的问题时，需要确认请求确实来自该地址
nginx 传递示例
nginx 传递示例
location / {
proxy_set_header X-Real-IP $remote_addr; # 最近一跳的地址
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 逐跳追加，保留历史链路
proxy_set_header X-Forwarded-Proto $scheme; # 传递原始协议
proxy_pass http://192.168.20.10:8080;
}
# 后端取值规则：按已知代理层数从右往左取，或从可信代理列表中匹配方案对照
| 方案 | 适用协议 | 注意事项 |
|---|---|---|
| X-Forwarded-For | HTTP/HTTPS | 可被客户端伪造，需约定可信层数 |
| X-Real-IP | HTTP/HTTPS | 仅记录最近一跳，多级代理下会覆盖 |
| PROXY protocol | TCP（含 HTTPS 直通） | 两端都要支持，否则握手失败 |
| 网络层方案 | 任意协议 | 改造量大，跨网段实现受限 |
转发头可被客户端伪造，风控与访问控制不要直接信任该头的任意外部值，必须按可信代理层数取值或校验来源。