real_ip_recursive on的核心目标是让nginx从右往左逐个剔除可信代理ip，取第一个不在set_real_ip_from列表中的ip作为真实客户端ip，从而防伪造；off则直接取x-forwarded-for最左ip，不校验可信性。
调优 real_ip_recursive 的核心目标，是让 Nginx 在多层代理环境下，准确提取出**第一个不可信的、真实的客户端 IP**，而不是被攻击者伪造的头字段干扰。它不是“开或关”的简单选择，而是要匹配你实际的代理链路结构。
先搞清 real_ip_recursive on 和 off 的真实行为差异
这个参数决定 Nginx 解析 X-Forwarded-For 时的遍历方向和终止逻辑：
-
real_ip_recursive off（默认）：直接取
X-Forwarded-For头最左边的 IP（即逗号分隔后的第一个），不管它是否来自可信代理。适合 CDN 单层透传且严格保证首 IP 为客户端（如 Cloudflare）的场景。 -
real_ip_recursive on：从
X-Forwarded-For最右边开始，逐个向左检查每个 IP 是否在set_real_ip_from列出的可信段中；一旦遇到**不在可信段中的 IP**，就立即把它当作真实客户端 IP 并停止查找。这才是防伪造的关键机制。
为什么开启 on 才能有效防绕过
攻击者常这样伪造：X-Forwarded-For: 1.1.1.1, 192.168.10.5, 10.0.0.1
其中 192.168.10.5 和 10.0.0.1 是你配置过的可信内网代理 IP 段，而 1.1.1.1 是恶意填写的假 IP。
- 若用
off：Nginx 直接取最左的1.1.1.1→ 被绕过。 - 若用
on：从右往左查，10.0.0.1在可信段 → 跳过；192.168.10.5也在可信段 → 跳过；下一个1.1.1.1不在任何可信段 → 立即采纳为真实 IP？错！这里关键点来了：Nginx 只信任由**可信代理主动添加**的 XFF 值，而不会把客户端自己发来的整个头全盘接收。所以真正起作用的是——你必须配合set_real_ip_from仅允许来自可信代理的请求携带该头，外网请求即使带了 XFF 也会被忽略。
必须同步做的三件事，否则 real_ip_recursive 再怎么调都没用
-
精确填写所有上游代理出口 IP 段：包括 CDN（如 Cloudflare、阿里云 CDN）、WAF、SLB、自建 LB 的真实回源 IP 段，一个都不能漏。例如：
set_real_ip_from 173.245.48.0/20;<br>set_real_ip_from 100.64.0.0/10; # 阿里云 SLB<br>set_real_ip_from 192.168.5.0/24; # 内网网关
-
确保 real_ip_header 指向正确的头字段：多数公有 CDN 用
X-Forwarded-For，自建反代常用X-Real-IP。如果 CDN 同时传两个头，优先配real_ip_header X-Real-IP，因为它的值更单一、不易被污染。 -
禁止后端直接读原始 X-Forwarded-For：Nginx 修正后的 IP 已存入
$remote_addr，后端应只用这个变量做限流、日志、黑白名单。PHP 中弃用$_SERVER['HTTP_X_FORWARDED_FOR']，Java 中禁用request.getHeader("X-Forwarded-For")。
验证是否真正生效的实操方法
在 http 块中临时加一段日志格式：
log_format debug_ip '$remote_addr | $realip_remote_addr | $http_x_forwarded_for';
access_log /var/log/nginx/debug.log debug_ip;
然后用 curl 模拟伪造请求：curl -H "X-Forwarded-For: 9.9.9.9, 192.168.10.5" http://yourdomain.com/
观察日志输出：
✔ 正确结果：9.9.9.9 | 9.9.9.9 | 9.9.9.9, 192.168.10.5（说明 realip 模块已识别并覆盖 $remote_addr）
✘ 错误结果：123.123.123.123 | 123.123.123.123 | 9.9.9.9, 192.168.10.5（说明 set_real_ip_from 或 real_ip_header 配置未命中）
