核心要点（TL;DR）

• 真实IP丢失优先查real_ip模块与set_real_ip_from信任链，而非只看日志。
• 502多为后端不可用或上游超时，先用curl直连后端排除应用问题。
• X-Forwarded-For需逐层透传，缺失会导致日志与风控全部失真。
• 上线前用检查清单核对real_ip、超时、连接数与日志字段四项。

反向代理上线后，日志里全是内网IP、风控规则失效、用户投诉502，是运维和站长最常遇到的两类连锁故障。真实IP丢失会让限流、封禁、审计全部失真，502则直接意味着业务不可用。本文按「先定位、再修复、后加固」的顺序，拆解5个最常见原因，每个都给出可直接执行的命令与配置片段。

原因一：real_ip模块未启用，日志只记录代理地址

Nginx默认把$remote_addr记为直连对端地址，经过CDN或SLB后自然变成内网IP。解决依赖ngx_http_realip_module，多数发行版默认已编译，可用nginx -V 2>&1 | grep realip确认。

在http或server块加入信任链配置：

set_real_ip_from 10.0.0.0/8;
set_real_ip_from 172.16.0.0/12;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

重载后执行nginx -t && nginx -s reload，再用tail -f access.log观察$remote_addr是否变为公网IP。注意set_real_ip_from只填可信代理网段，填0.0.0.0/0等于允许伪造。

原因二：X-Forwarded-For未逐层透传，应用取错IP

即使Nginx侧配置正确，若上一跳代理没有透传头部，应用拿到的仍是代理IP。逐层检查每一跳是否使用追加而非覆盖：

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

用curl -H 'X-Forwarded-For: 1.2.3.4' http://后端/echo验证应用回显。多级代理时，应用侧应只信任来自代理网段的最右侧可信IP，避免被客户端伪造头部绕过限流。

原因三：后端服务不可用，502的第一嫌疑

502本质是Nginx连上了上游却拿不到有效响应，或连接直接被拒。按以下顺序排查：

1. 在Nginx机器执行curl -v http://后端IP:端口/健康路径，确认端口连通；
2. 检查后端进程与监听地址，ss -lntp | grep 端口，确认没有只绑127.0.0.1；
3. 查看error_log中connect() failed、upstream prematurely closed connection关键字；
4. 确认SELinux与防火墙未拦截，getenforce、firewall-cmd --list-all。

直连正常而经Nginx失败时，重点核对proxy_pass地址协议、路径斜杠与后端是否要求HTTPS。

原因四：上游超时与连接数打满，502与504交替出现

后端处理慢或并发过高时，Nginx会因超时或连接耗尽返回5xx。检查并调整：

同时用netstat -an | grep 后端端口 | wc -l观察TIME_WAIT堆积，必要时开启keepalive连接池并调整keepalive_requests。

原因五：DNS解析与权限问题，隐蔽但高频

proxy_pass使用域名时，Nginx只在启动时解析一次，后端IP变更后仍指向旧地址，表现为间歇性502。可用resolver配合变量写法解决，或改用upstream并定期reload。此外检查Nginx worker用户对上游证书、日志目录的读权限，权限不足同样会触发5xx。

上线前检查清单与行动建议

• real_ip信任链是否只包含可信代理网段；
• 每一跳是否使用$proxy_add_x_forwarded_for追加；
• access_log是否保留$remote_addr、$upstream_addr、$upstream_status；
• 超时与连接数是否按业务压测结果设置；
• 后端健康检查与5xx比例告警是否生效。

建议把上述清单固化为发布前检查项，并对5xx比例设置告警。在防护层面，AegisX可对回源请求做真实IP还原与异常流量识别，配合WAF规则拦截伪造X-Forwarded-For的恶意请求，减少因头部伪造导致的误封与绕过。

常见问题（FAQ）

Nginx日志里全是127.0.0.1或内网IP，怎么找回访客真实IP？

先确认请求是否经过CDN或负载均衡。在Nginx的http或server块启用ngx_http_realip_module：set_real_ip_from填写可信代理网段，real_ip_header X-Forwarded-For，real_ip_recursive on。重载后查看access_log中的$remote_addr是否变为公网IP。若仍为内网IP，说明上游未透传X-Forwarded-For，需在上一跳代理补proxy_set_header。

Nginx报502但后端服务看起来是正常的，从哪查起？

502表示Nginx无法从上游拿到有效响应。先在Nginx机器上执行curl -v http://后端IP:端口/健康检查路径，确认网络与端口连通；再查后端进程、监听地址是否绑在127.0.0.1、以及error_log中的connect() failed或upstream prematurely closed connection关键字。若直连正常而经Nginx失败，重点看proxy_pass地址、超时与SELinux/防火墙策略。

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for 为什么还会丢IP？

该指令只是把客户端地址追加到已有X-Forwarded-For后面，若上一跳没有传该头，或后端应用未按信任链取最左侧可信IP，仍会取错。此外多级代理中若某层用proxy_set_header覆盖而非追加，也会丢失。建议统一用$proxy_add_x_forwarded_for，并在应用侧配置可信代理列表，只信任来自代理网段的头部。

Nginx 502和504有什么区别，排查方向一样吗？

不一样。502是上游返回无效响应或连接被拒，多为后端进程崩溃、端口不通、协议不匹配；504是上游响应超时，多为后端处理慢、数据库阻塞或proxy_read_timeout过短。排查502先看连通性与后端日志，排查504先看后端耗时与超时参数，两者都要结合error_log定位。

如何在上线前避免真实IP与502问题反复出现？

建立四项检查：一是real_ip信任链与X-Forwarded-For透传配置；二是proxy_connect_timeout、proxy_read_timeout与keepalive连接池；三是后端健康检查与自动摘除；四是access_log保留$remote_addr、$upstream_addr、$upstream_status字段。配合监控对5xx比例告警，可在故障扩大前发现异常。