不要直接信任客户端传入的 IP 请求头。梳理代理顺序、限定可信来源，并在日志中保留连接地址用于排查。
网站接入 CDN 和负载均衡后，应用可能只看到代理地址；另一种更危险的情况是应用直接接受客户端自报的 IP。前者会让限速误伤大量用户，后者会污染审计记录。修复的核心是定义谁有资格传递访客身份。
把代理链写成可核对的顺序
先列出“用户—边缘节点—负载均衡—反向代理—应用”的实际路径，标明每一跳保留、追加或覆盖哪些请求头。运维应同时记录正常业务路径和旁路路径，尤其是内部探测、灰度入口与管理接口。
NGINX realip 模块通过 set_real_ip_from 指定可信来源，通过 real_ip_header 选择取值字段；real_ip_recursive 会影响多级代理下取地址的方式。官方文档还提供 $realip_remote_addr 保留原始连接地址。是否启用递归应由真实链路决定，不能把所有地址都列为可信来消除报错。
四项测试能发现哪些问题
- 正常代理路径：应用识别的地址应与边缘观测一致，允许因隐私代理或运营商网络产生合理差异。
- 客户端自带同名头：在授权环境发送带测试值的请求，边缘应按设计覆盖或规范处理，应用不应无条件接受该值。
- 未经信任的直连：不能仅凭一个 HTTP 头获得可信身份；同时检查源站入口限制。
- 多级代理与 IPv6：分别核对解析结果，避免只测一条 IPv4 链路就判定上线成功。
日志与限速一起验收
建议并列记录连接来源、最终识别地址、请求标识和所走入口，并控制访问权限与保存期限。若同一出口的用户突然全部触发限速，应先检查真实 IP 处理是否失效，而不是直接扩大限速阈值。
IP 只能作为风险信号之一，不能证明账号身份。涉及权限的决定仍需服务端身份认证和授权。与本主题配套的源站入口检查，应在代理配置变化后一起复测。
参考：NGINX：ngx_http_realip_module。核对日期：2026年10月4日。
