要在 Nginx 反向代理中可靠透传客户端真实 IP，必须三环节对齐：启用 http_realip_module 并用 set_real_ip_from 指定可信代理、real_ip_header 指定来源头、real_ip_recursive on 启用递归解析，使 $remote_addr 为真实 IP；再通过 proxy_set_header 将其透传至后端；后端须主动读取 X-Real-IP 或 X-Forwarded-For 而非 REMOTE_ADDR。
要在 Nginx 反向代理中可靠透传客户端真实 IP，不能只靠加几行 proxy_set_header。核心是三个环节必须对齐：Nginx 先“认出”真实 IP、再“传出去”、后端再“读出来”。缺一环，拿到的就可能是代理 IP 或伪造值。
让 $remote_addr 变成真实客户端 IP
Nginx 默认的 $remote_addr 是上一跳连接它的 IP（比如 CDN 节点或 SLB），不是用户本身。要让它变成真实 IP，必须启用 http_realip_module 并明确告诉 Nginx 哪些上游是可信的：
- 用
set_real_ip_from列出所有可信代理的 IP 或网段，例如：set_real_ip_from 100.64.0.0/10;（阿里云私网）set_real_ip_from 203.208.60.1;（某 CDN 回源节点） - 指定从哪个请求头提取真实 IP：
real_ip_header X-Forwarded-For;（推荐，兼容多层）
或real_ip_header X-Real-IP; - 开启递归解析：
real_ip_recursive on;
这样 Nginx 会从X-Forwarded-For的逗号列表中，从右往左剔除所有已知代理 IP，最终把最左边那个合法 IP 设为新的$remote_addr和$realip_remote_addr
用 proxy_set_header 把真实 IP 传给后端
只有 $remote_addr 已经是真实 IP 后，下面这些 header 才真正有效：
-
proxy_set_header X-Real-IP $remote_addr;
——最简方式，单个值，后端可直接信任使用 -
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
——标准链路记录，自动在原有值后追加当前$remote_addr，不覆盖原始路径 -
proxy_set_header X-Forwarded-Proto $scheme;
——透传原始协议（http/https），避免后端误判 HTTPS 状态 -
proxy_set_header Host $host;
——保留原始 Host，防止后端生成错误跳转链接
后端必须主动读取 Header，不能依赖 REMOTE_ADDR
后端服务收到的 TCP 远程地址永远是 Nginx 的内网 IP（如 127.0.0.1）。它必须显式检查请求头：
- 优先读
X-Real-IP；若不存在，再取X-Forwarded-For中最左边的非私有 IP（注意校验格式和合法性） - Java 应用不要用
request.getRemoteAddr()，改用request.getHeader("X-Real-IP") - PHP 中用
$_SERVER['HTTP_X_REAL_IP']或$_SERVER['HTTP_X_FORWARDED_FOR']，并做空值与 IP 格式判断 - Node.js 中类似：
req.headers['x-real-ip'] || req.headers['x-forwarded-for']?.split(',')[0].trim()
常见陷阱与验证建议
配置完别急着上线，先验证是否生效：
- 在 Nginx access log 中加入
$realip_remote_addr字段，确认日志里记录的是用户真实 IP - 临时加一个测试接口，返回所有相关 header（
X-Real-IP、X-Forwarded-For、REMOTE_ADDR），比对三者差异 - 警惕伪造风险：没配
set_real_ip_from时，X-Forwarded-For可被客户端任意修改；配了但网段漏写，也可能被绕过 - CDN 场景下，务必查清 CDN 回源使用的 IP 段，并全部加入
set_real_ip_from，否则real_ip_header无法生效
