real_ip_recursive on 本身不防绕过审计，仅控制XFF链解析逻辑：off时取最左IP，on时从右往左找首个可信代理IP再取其左侧IP；真正防护依赖set_real_ip_from精准声明可信代理段及proxy_set_header正确覆盖XFF。
调优 real_ip_recursive on 本身不能“防止绕过日志审计”，它只是决定 Nginx 如何解析多层代理传来的 X-Forwarded-For（XFF）链。真正起防护作用的是你是否在可信边界上正确配置了 set_real_ip_from 和 proxy_set_header。错误理解 real_ip_recursive 容易导致信任链断裂，反而放大风险。
先搞清 real_ip_recursive 的真实作用
这个参数控制 Nginx 在遇到多个 XFF IP 时的取值逻辑：
-
off（默认）：只检查 XFF 最左边一个 IP，再比对是否在
set_real_ip_from列表中；匹配则用它替换$remote_addr，否则不替换 - on：从右往左逐个检查 XFF 中的 IP，直到找到第一个属于可信代理段的 IP，然后取它左边那个作为客户端真实 IP
举个例子，XFF 值为 1.1.1.1, 2.2.2.2, 3.3.3.3，且你只信任 3.3.3.3（即它是你直连的 CDN 或 WAF）：
– real_ip_recursive off → 取 1.1.1.1，但不校验它是否可信，直接当作真实 IP（危险！）
– real_ip_recursive on → 从右往左查，发现 3.3.3.3 在可信段内，就取它左边的 2.2.2.2 作为真实 IP（仍可能被伪造，除非 3.3.3.3 是你可控的最外层代理）
关键不在 on/off，而在可信代理段是否精准声明
如果 set_real_ip_from 范围过大（比如写了 0.0.0.0/0 或整个公网段），开启 recursive on 反而会让攻击者通过构造长链 XFF（如 attacker.com, 192.168.1.100, 10.0.0.5）诱导 Nginx 取到伪造 IP。必须做到：
- 仅声明你实际管理的上游代理 IP 段（如 CDN 提供的回源段、WAF 内网出口、LB 内网地址）
- 避免使用宽泛 CIDR（如
10.0.0.0/8应细化为10.10.20.0/24） - 确认这些代理确实会用
$remote_addr覆盖 XFF，而非透传原始请求头
日志审计依赖的是 $remote_addr 是否已还原为真实 IP
审计日志是否可靠，取决于 $remote_addr 在写入 access_log 时是否已是客户端真实出口 IP。验证方法很简单：
- 临时添加一条日志格式：
log_format debug '$remote_addr - $http_x_forwarded_for - $http_x_real_ip'; - 发起真实请求（非 curl 伪造），观察日志中
$remote_addr是否为你本机公网 IP - 若仍是内网地址（如
10.10.20.3），说明real_ip_module未生效，需检查set_real_ip_from是否覆盖了该地址，以及请求是否真从该段来
后端与日志协同才构成完整审计链
光靠 Nginx 日志还不够。攻击者绕过审计的常见方式是让后端应用读错 IP，导致日志和业务逻辑不一致。必须同步做到：
- 反向代理层统一设置：
proxy_set_header X-Real-IP $remote_addr;（注意不是$http_x_real_ip） - 后端代码严格读取
X-Real-IP头，而非X-Forwarded-For或RemoteAddr - 审计系统应同时采集 Nginx access_log 中的
$remote_addr和后端记录的X-Real-IP，二者必须一致才视为有效
