排查Nginx故障需联动访问日志、错误日志与实时监控：access.log分析异常请求模式（如5xx接口、恶意IP、慢请求），error.log定位底层问题（如连接拒绝、超时、文件描述符耗尽），stub_status验证连接状态，再结合集群监控确认影响范围。
排查 Nginx 故障不能只盯一个地方，得把访问日志、错误日志和实时监控指标串起来看——三者互补：日志告诉你“发生了什么”，监控指标告诉你“正在发生什么”，而两者的交叉比对才能定位“为什么发生”。
看 access_log 定位异常请求模式
访问日志是第一手线索，重点不是逐行翻，而是用命令快速聚合分析：
- 查高频 5xx 错误：
awk '$9 ~ /^5/ {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -10，快速找出报错最多的接口路径 - 查异常客户端 IP：
awk '$9 ~ /^5/ {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -5，判断是否为爬虫、扫描或单点压测行为 - 查超长响应时间（假设日志含
$request_time）：awk '$NF > 5 {print $0}' /var/log/nginx/access.log | tail -20，筛选耗时超 5 秒的请求，再结合 URI 和 upstream_addr 判断是转发慢还是本机处理慢
查 error_log 锁定底层运行问题
错误日志不记录业务逻辑，但暴露 Nginx 自身瓶颈或配置硬伤：
-
connect() failed (111: Connection refused)：后端服务宕机、端口未监听，或防火墙拦截 -
upstream timed out (110: Connection timed out)：后端无响应，需结合proxy_connect_timeout和proxy_read_timeout值判断是否配置过短，还是后端真卡死 -
open() "/path/to/file" failed (24: Too many open files)：系统级文件描述符耗尽，要同步检查worker_rlimit_nofile和ulimit -n是否匹配 -
no live upstreams while connecting to upstream：负载均衡组内所有节点都被标记为 down，可能因健康检查失败或主动摘除
用 stub_status 实时验证连接与吞吐状态
启用 stub_status 后访问 /nginx_status，返回类似：
server accepts handled requests
123456 123456 987654
Reading: 2 Writing: 6 Waiting: 120
关键看三项：
-
Waiting 数值持续接近 worker_connections：说明大量连接处于 keepalive 空闲态，不是性能瓶颈，而是客户端长连接没释放；若同时
Active connections持续飙升，则可能是连接泄漏或 DDoS - accepts ≠ handled：说明有连接被接受但未完成处理，常见于 worker 进程异常退出或资源不足（如内存 OOM 后被系统 kill）
-
handled/request 比值明显下降：比如从 1.0 降到 0.8，意味着部分请求在处理中被中断（如超时断开、客户端主动关闭），需回查 error_log 中的
client closed connection或upstream prematurely closed类报错
关联外部监控确认影响范围
单台 Nginx 的日志和状态只是局部视图，必须叠加维度：
- 对比同一集群其他 Nginx 节点的
stub_status数据：若仅某台Active connections异常高，可能是负载不均或该节点 upstream 配置错误 - 查看 Prometheus 中
nginx_connections_active+nginx_upstream_requests_total{status=~"5.."}：确认是全局性故障（所有节点 5xx 上升），还是局部上游服务异常（仅某 upstream group 报错） - 结合系统指标：当
nginx_process_cpu_percent飙升且load_average同步走高，优先查是否开启低效模块（如未编译优化的 Lua 脚本）、正则规则过于复杂，或日志写入磁盘 I/O 阻塞
