多级代理下Nginx获取真实客户端IP的关键在于信任链与头传递一致性：一级代理用X-Forwarded-For $remote_addr写入原始IP，后续各级用$proxy_add_x_forwarded_for追加，配合set_real_ip_from精确配置可信网段、启用real_ip_header X-Forwarded-For及real_ip_recursive on，后端须取X-Forwarded-For首项非私有IP。
多级代理下 Nginx 获取不到真实客户端 IP，本质不是“没传”，而是“传了但没信”或“传了但传歪了”。关键在信任链断裂、头信息污染和解析逻辑错配。排查要聚焦三点：X-Forwarded-For 是否完整可信、real_ip 配置是否匹配代理层级、后端读取方式是否与 Nginx 解析一致。
确认 X-Forwarded-For 头是否被正确拼接和透传
多层代理中，X-Forwarded-For 必须逐级追加，而非覆盖，否则最外层真实 IP 会丢失。
- 一级代理（最外层）用 proxy_set_header X-Forwarded-For $remote_addr —— 此时写入原始客户端 IP
- 二级及后续代理统一用 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for —— 它会自动在原有值后追加当前代理的 $remote_addr，并用逗号分隔
- 检查 access_log 中 $http_x_forwarded_for 字段：应形如 203.0.113.45, 10.1.2.3, 172.18.0.5，最左边才是真实客户端 IP；若只看到单个内网 IP 或空值，说明某一级漏配或覆盖了该头
验证 real_ip 模块是否启用且可信网段配置准确
Nginx 不会自动信任 X-Forwarded-For，必须明确告诉它“谁是可信代理”，否则拒绝覆盖 $remote_addr。
- 确保 http 块中启用了 real_ip_header X-Forwarded-For 和 real_ip_recursive on
- set_real_ip_from 必须精确列出所有上游代理的 IP 或网段（如 10.0.0.0/8、172.16.0.0/12、云厂商 SLB 的固定出口段），不能写 0.0.0.0/0 或遗漏某一层
- 用 log_format debug '$remote_addr — $http_x_forwarded_for — $realip_remote_addr' 对比三者：若 $remote_addr 始终是中间代理 IP，而 $realip_remote_addr 已变为真实 IP，说明 real_ip 生效；若两者始终一致，大概率是 set_real_ip_from 范围不匹配
检查后端服务是否误读了错误的头字段
即使 Nginx 正确解析出真实 IP，后端若读错字段，结果仍是代理 IP。
- 确认后端代码（如 Java 的 request.getRemoteAddr()、Go 的 r.RemoteAddr）读取的是 X-Forwarded-For 并取第一个非私有 IP，而非直接依赖 remote address
- 避免混用 X-Real-IP：它通常只由一级代理设置，多级场景下会被覆盖为上一级代理 IP，不可靠
- 若业务使用 Nginx 自身变量（如限流用 $remote_addr），需确保已通过 real_ip 模块更新；若仍需原始连接 IP，可用 $realip_remote_addr（需开启 real_ip）或保留 $connection_addr
排除常见干扰项
某些看似无关的配置会间接破坏真实 IP 传递链。
- Cloudflare、阿里云 WAF 等托管服务可能改写 X-Forwarded-For 格式（如添加双引号、空格），需配合 real_ip_recursive on 和更宽松的可信网段判断
- Docker/K8s 环境中，宿主机网卡（如 docker0 的 172.17.0.1）常被误设为可信源，导致 $remote_addr 被错误替换为宿主机 IP —— 应仅信任真正对外的代理节点，而非容器网络内部地址
- 日志中若发现 $http_x_forwarded_for 出现重复 IP（如 “a,b,b,c”），说明某级代理错误地将自身 IP 重复追加，需检查其 proxy_set_header 配置是否误用了 $remote_addr 而非 $proxy_add_x_forwarded_for
