排查 nginx 平滑重载期间的 502 bad gateway，核心在于确认上游服务在重载瞬间是否因信号处理或配置加载失败而中断。通常做法是检查 nginx 主进程与 worker 进程的切换逻辑，以及上游服务的健康状态。如果上游服务未正确响应 sigterm 信号或 nginx 配置文件存在语法错误导致重载回滚，就会引发连接拒绝。
Nginx 重载机制如何影响上游连接
Nginx 的平滑重载依赖于主进程（Master）和子进程（Worker）的协作。当执行 nginx -s reload 时，主进程会验证新配置文件，若成功则启动新的 Worker 进程，并通知旧 Worker 进程停止接受新连接。此时，正在处理的请求会被继续完成，但新进来的请求会由新 Worker 处理。如果新旧 Worker 切换期间，上游服务短暂不可用，或者 Nginx 无法建立新连接，就会返回 502。
worker_processes 1;
events {
worker_connections 1024;
}
http {
upstream backend {
server 127.0.0.1:8080;
}
server {
listen 80;
location / {
proxy_pass http://backend;
proxy_next_upstream error timeout;
}
}
}
上述配置中，proxy_next_upstream 默认包含 error 和 timeout。这意味着如果上游在重载瞬间报错，Nginx 可能会尝试重试。但如果只有一个上游节点且立即返回错误，用户将看到 502。通过调整该指令，可以控制重试行为，减少 502 的出现频率。
如何区分是 Nginx 问题还是上游服务问题
要确定 502 的具体来源，需要查看 Nginx 的错误日志。常见的错误信息包括 connect() failed (111: Connection refused) 或 upstream prematurely closed connection。前者通常表示上游服务在 Nginx 尝试连接时完全不可用，可能是服务重启导致的；后者可能表示上游在处理请求时崩溃或主动断开连接。
# 模拟上游服务短暂不可用的脚本
while true; do
curl -s -o /dev/null -w "%{http_code}" http://localhost/ || echo "Failed"
sleep 1
done
在实际测试中，可以通过模拟上游服务的短暂停机来复现 502。例如，使用上述脚本持续请求，并在请求过程中重启上游服务。观察 Nginx 的错误日志，可以确认 502 是由连接拒绝还是其他原因引起的。这有助于定位问题是出在 Nginx 的重载逻辑还是上游服务的稳定性上。
重载期间上游服务无响应时的具体表现
当上游服务在 Nginx 重载期间无响应时，Nginx 会记录相应的错误日志，并向客户端返回 502 状态码。具体表现为客户端收到 502 Bad Gateway 页面，而 Nginx 错误日志中会出现 connect() failed (111: Connection refused) 或类似信息。这种情况通常发生在 upstream 服务重启或配置加载失败时。
