Nginx 502与504故障排查怎么结合 error_log 定位崩溃根源-Nginx-PHP中文网

先看error.log错误阶段和errno：connect() failed(111)→502，后端未监听；while reading response header(110)→504，超时配置或后端慢；upstream prematurely closed→后端主动断连，查OOM、worker耗尽。

nginx 502与504故障排查怎么结合 error_log 定位崩溃根源

直接看 error.log 里的错误阶段和系统错误码，就能快速区分是上游挂了（502）还是卡住了（504），再顺着线索查进程、端口或超时配置。

盯住日志里明确标注的错误阶段

Nginx 的 error.log 不只告诉你“出错了”，更会说明错在哪一环：

while connecting to upstream → 连接建立失败，典型如 Connection refused (111)，说明后端根本没监听，先查服务是否启动、端口对不对、防火墙是否放行
while reading response header from upstream → 已连上但等不到响应头，这是 504 最常见位置，重点核对 proxy_read_timeout 和后端实际处理耗时
upstream prematurely closed connection → 后端主动断连，常见于 PHP-FPM worker 耗尽、应用 OOM 被杀、或 FastCGI 响应超时，要同步查后端日志和资源使用

按错误码反推系统级问题

日志括号里的数字不是随便写的，它对应 Linux 系统调用返回的 errno，能直指底层原因：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

(111: Connection refused) → 目标端口无服务监听，用 ss -tlnp | grep :8000 验证
(110: Connection timed out) → TCP 握手成功但读响应超时，检查后端是否卡在 fork、数据库锁、或磁盘 I/O
(113: No route to host) → 网络层不通，目标 IP 不可达，优先排查路由、安全组、跨网段策略

结合时间戳做关联分析

502/504 往往不是孤立事件，而是连锁反应的起点：

如果某时刻起 error.log 突然密集出现 upstream prematurely closed connection，立刻去查同一时间点的应用进程状态：systemctl status your-app 或 journalctl -u your-app -S "2026-10-01 02:03:00"
若同时发现大量 upstream timed out，且集中在某个接口路径（如 /api/report），就去查该接口的慢查询日志或应用 trace，大概率是数据库连接池打满或单条 SQL 耗时飙升