Nginx故障排查核心是“现象→日志→配置/环境→验证”闭环，首查错误日志（默认/var/log/nginx/error.log），聚焦[error]/[crit]行；再依HTTP状态码归因（如502指向后端崩溃、504提示超时）；继而nginx -t校验语法、systemctl status看服务、curl直连测后端；最后通过结构化日志与关键指标监控实现主动预警。
排查 Nginx 故障，核心不是“试错”，而是建立“现象→日志→配置/环境→验证”的闭环。真正高效的人，靠的不是经验堆砌，而是一套可复用、能沉淀的处理路径。
一、错误日志：第一响应现场
错误日志是故障排查的起点，90%以上的问题线索都藏在里面。默认路径为 /var/log/nginx/error.log，但务必先确认 nginx.conf 中 error_log 指令的实际配置，避免查错文件。
- 实时追踪最新错误：运行 tail -f /var/log/nginx/error.log，尤其在重启、上线或告警触发后立即执行
- 聚焦关键标识：优先筛选含 [error]、[crit]、[alert] 的行；例如 "connect() failed (111: Connection refused) while connecting to upstream" 直接指向后端不可达
- 临时提级诊断：若常规日志信息不足，可将日志级别临时设为 debug（注意：仅限排查期，事后必须调回 warn 或 error，否则磁盘和性能压力剧增）
二、状态码归因：精准区分问题层级
不同 HTTP 状态码对应完全不同的故障域，不能笼统归为“后端挂了”。
- 502 Bad Gateway：Nginx 已连上后端，但收到非法响应或连接被重置——常见于 PHP-FPM 崩溃、Java 应用 OOM 后强制 kill、或上游返回非标准 HTTP 头
- 504 Gateway Timeout：Nginx 在设定时间内未收全响应——需检查 proxy_read_timeout 是否过短，同时结合 upstream_response_time 日志字段判断是网络延迟、后端卡死，还是慢查询拖垮
- 499 Client Closed Request：客户端主动断开（如用户关闭页面、APP 超时放弃）——本身非服务端错误，但大量出现可能暗示前端体验差或接口响应太慢
三、配置与依赖双线验证
日志给出方向，但最终定位要落到具体配置项和上下游依赖上。
- 语法校验必做：nginx -t 检查配置合法性，避免 reload 后服务静默退出
- 服务状态快检：systemctl status nginx 看进程是否存活，ss -tlnp | grep :80 确认端口监听真实存在
- 后端连通性实测：用 curl -v http://127.0.0.1:9000/ping（替换为实际后端地址）绕过 Nginx 直连验证；若失败，问题不在 Nginx 层
- SSL 证书有效性：用 openssl x509 -in /path/to/cert.pem -noout -enddate 查过期时间，过期前 7 天应自动续签并 reload
四、监控预警闭环：让问题止于发生前
被动排查永远滞后。真正的“终极”，是把高频故障点转化为可观测指标，并触发分级响应。
- 关键指标采集：除基础请求量、错误率外，必须监控 upstream_response_time 的 P95/P99、upstream_connect_time 异常升高、以及 upstream_cache_status 中 MISS 率突增
- 日志结构化：弃用默认 combined 格式，改用 JSON 格式输出（含 request_time、upstream_addr、ssl_protocol 等），便于 ELK 或 Loki 快速聚合分析
- 告警收敛设计：对同一 IP 短时高频 502 不发单条告警，改为“过去 5 分钟 502 错误数 > 50”才触发；避免告警风暴掩盖根因
