Nginx 反向代理排障：从 502 到稳定上线

先分清 502、503 和 504

502 表示 Nginx 收到了无效的上游响应，503 表示暂时没有可用服务，504 则表示上游在超时时间内没有返回。数字相近，处理方向不同。

第一步：同时看两边日志

不要只看 Nginx 的 access.log。先确认请求是否真正到达了后端，再对照后端的错误堆栈。很多 502 其实是后端起得太慢、端口写错，或健康检查误判。

第二步：检查容器网络

Nginx 与后端容器是否在同一网络，是否使用了固定的服务名而不是会变化的 IP。容器刚启动时，DNS 和端口监听都需要时间，只设置 restart 并不能解决顺序问题。

docker compose ps
docker network inspect blog_default
curl -I http://backend:8090/health

第三步：校准超时与缓冲区

上传、生成页面或调用外部接口的请求需要更长时间。默认的超时值很容易触发 504。根据真实业务调整 proxy_read_timeout，并让后端也设置一致的时限。

location / {
    proxy_pass http://backend:8090;
    proxy_read_timeout 60s;
    proxy_connect_timeout 5s;
}

第四步：看资源是否耗尽

内存不足、文件描述符耗尽、CPU 被打满，都可能让后端无法响应。先用 free、ss、ps 和日志判断瓶颈，再决定扩容或优化，而不是直接不断重启。

反向代理排障的本质，是把一次失败还原成完整请求链路。把每个环节的证据对齐，502 就不再是一个模糊状态。