关键在于逐级信任、逐级剥离、最终还原：nginx通过set_real_ip_from限定可信代理网段，real_ip_header指定头来源，real_ip_recursive开启递归解析，使$remote_addr直接变为校验后的用户真实ip；四层链路须用proxy protocol，后端必须读取$remote_addr而非手动解析x-forwarded-for。
在多层负载均衡架构中，确保每一层都能正确获取并校验客户端真实 IP，关键不是“层层传递 X-Forwarded-For”，而是**逐级信任、逐级剥离、最终还原**。Nginx 本身不负责“传递 IP”，它只负责在可信边界内做安全校验与变量覆盖。错误地依赖头字段链式解析，反而会引入伪造风险。
明确可信代理范围，用 set_real_ip_from 限定源头
只有被显式声明为可信的上游代理（如云厂商 SLB、CDN 回源 IP 段、内网 LB 地址），其发来的 X-Forwarded-For 或 Proxy Protocol 才可被信任。例如：
- 阿里云 SLB 四层回源网段常见为 100.64.0.0/10，需写入：
set_real_ip_from 100.64.0.0/10; - 腾讯云 CLB 七层回源 IP 需查文档确认，通常为内网地址段（如 10.0.0.0/8）
- 自建多级 Nginx 时，上一级 Nginx 的出口 IP（非 0.0.0.0，而是具体绑定地址）才应加入
set_real_ip_from
未列入的 IP 发来的 XFF 头一律忽略——这是防伪造的第一道防线。
启用 real_ip_recursive 并指定头来源
当多层代理（如 CDN → SLB → Nginx LB → 应用 Nginx）都添加了 X-Forwarded-For，必须开启递归模式，让 Nginx 自动从左到右剔除所有可信代理 IP，取剩余第一个为真实客户端 IP：
-
real_ip_header X-Forwarded-For;—— 告诉 Nginx 从哪个头读原始列表 -
real_ip_recursive on;—— 启用“剥洋葱”逻辑：每遇到一个set_real_ip_from中的 IP，就从 XFF 列表末尾移除一项，直到剩下一个非可信 IP - 配置生效后，
$remote_addr就是校验后的用户真实 IP，日志、limit_req、geo、map等模块可直接使用，无需改代码
四层链路必须用 Proxy Protocol，不能靠 HTTP 头
如果中间某层是 LVS、F5、或云厂商 TCP/UDP 型负载均衡器（不解析 HTTP），X-Forwarded-For 完全不可用。此时必须：
- 在负载均衡器侧开启 Proxy Protocol v1 或 v2（文本或二进制格式）
- Nginx listen 指令加
proxy_protocol：listen 8000 proxy_protocol; - 配套设置：
real_ip_header proxy_protocol;和仍需set_real_ip_from限制仅接受来自 LB 的连接 - 注意：Proxy Protocol 是 TCP 层协议扩展，要求上下游都支持；HTTP/HTTPS server 块内不可混用
proxy_set_header类指令
后端服务必须读取修正后的 $remote_addr，而非手动解析头
即使 Nginx 配置无误，若后端应用（Java、Python、Node.js）仍用类似 request.getHeader("X-Forwarded-For") 或 $_SERVER['HTTP_X_FORWARDED_FOR'] 手动拆分字符串，就绕过了 realip 模块的安全校验，极易被伪造头欺骗：
- Java Spring Boot：应使用
HttpServletRequest.getRemoteAddr()（前提是容器已正确配置，如 Tomcat 的RemoteIpValve） - Python Flask/Django：依赖 WSGI 服务器（如 Gunicorn/Nginx）传入的
REMOTE_ADDR环境变量，而非请求头 - PHP：
$_SERVER['REMOTE_ADDR']在 Nginx + fastcgi_param REMOTE_ADDR $remote_addr; 正确配置下即为真实 IP
所有手动解析 XFF 的逻辑都应删除，统一交由 Nginx realip 模块完成校验与赋值。
