error_log本身不直接反映运行状态异常，而是通过记录connect() failed、upstream timed out、worker process exited on signal 11等高危错误信号，结合频次、时间集中度及错误层级，精准识别服务失稳或失效。
error_log 本身不直接反映“运行状态是否异常”，它只记录 Nginx 进程在运行过程中发生的错误事件。真正有效的监控，是把 error_log 当作信号探测器——不是看它“有没有日志”，而是看它“写了什么、什么时候写、写了多少”。关键在于识别那些预示服务即将失稳或已失效的典型模式。
聚焦三类高危日志信号
以下错误类型出现即表明运行状态已异常，需立即响应：
- connect() failed (111: Connection refused) while connecting to upstream：上游服务（如 PHP-FPM、Node.js）彻底离线，Nginx 仍在运行但无法代理请求
- upstream timed out (110: Operation timed out) while reading response header：后端响应严重延迟，可能已卡死或资源耗尽
- worker process [pid] exited on signal 11：发生段错误，worker 崩溃，属于核心稳定性故障，非配置问题
结合时间与频次判断异常程度
单条错误可能是偶发，持续或密集出现才构成真实异常：
- 用
tail -n 100 /var/log/nginx/error.log | grep -c "Connection refused"统计最近 100 行中连接拒绝次数；若 ≥5 次，基本可判定上游宕机 - 观察时间戳是否集中爆发：用
awk '{print $1,$2}' /var/log/nginx/error.log | sort | uniq -c | sort -nr | head -5查看错误最密集的时间段 - 注意错误是否成对出现：例如先有
open() "/etc/ssl/certs/my.crt" failed (13: Permission denied)，紧接着SSL_CTX_use_certificate_chain_file() failed，说明证书加载失败，HTTPS 将不可用
区分错误来源层级，避免误判
error_log 的内容需结合其产生位置理解：
- 全局块（main context）报错，如
bind() to 0.0.0.0:443 failed (98: Address already in use)，说明 master 进程启动失败，整个服务未就绪 - http/server/location 块内报错，如
rewrite or internal redirection cycle，说明某虚拟主机或路径配置逻辑错误，仅影响局部流量 - 日志中带
upstream字样的错误，本质是后端通信链路问题，Nginx 自身进程仍健康，但服务能力已降级
临时提级诊断，快速定位静默故障
某些异常（如共享内存区满、限流静默失效）默认级别下不会记入 error_log：
- 将全局 error_log 临时设为
notice或info，重载后观察是否出现limit_req: zone "perip" is full等提示 - 启用 debug 日志时，必须指定独立文件（如
error_log /var/log/nginx/debug.log debug;），避免冲刷主错误日志 - 排查完立刻改回
error或warn，debug 级别长期开启会导致 I/O 压力和磁盘爆满
不复杂但容易忽略
