Nginx 中 error_log 的级别配置与故障排查作用

Nginx error_log级别是关键线索过滤器，非日志量开关；生产推荐全局设error、核心server设warn，warn可捕获证书过期、重定向循环等预警，error记录502/504等明确失败。

Nginx 的 error_log 级别不是日志“多少”的开关，而是关键线索的过滤器——设得太低，满屏噪音；设得太高，故障前兆直接被丢弃。真正有效的配置，是让 warn 捕获证书过期、重定向循环、upstream 拒绝连接这些可干预的预警，让 error 稳稳守住 502/504、权限拒绝、模块加载失败等明确失败事件。

生产环境推荐默认用 warn

warn 是线上最实用的平衡点：它既不会像 debug/info 那样拖慢性能、填满磁盘，又能比 error 多捕获大量前置风险信号。比如：

1. SSL 证书剩余有效期不足 30 天时的提醒
2. too many redirects 循环跳转触发前的警告
3. upstream server 被临时标记为 down 的记录
4. client body 超限但已截断（不返回 413，却埋下隐患）

这些在 error 级别下完全看不到，但往往就是后续大面积 502 的源头。

按作用域分级设置，避免全局污染

全局（main 块）设为 error，保证基础稳定性日志不丢失；

核心业务 server 块单独加 error_log /var/log/nginx/api_error.log warn;，隔离定位；

非关键 location（如 /static 或 /favicon.ico）可设 error_log off 或仅 error，过滤 404 类低价值噪音；

调试某段逻辑时，只在对应 location 内临时启用更细粒度，例如 error_log /var/log/nginx/debug_upstream.log debug;（前提是编译含 --with-debug）。

快速确认当前生效级别

很多人改了 http 块，却忘了某个 server 块里有独立 error_log 指令，导致日志没变化。用这条命令检查：

grep -n "error_log" /etc/nginx/nginx.conf /etc/nginx/sites-enabled/*

1. 只在 http 块出现 → 全局生效
2. 某个 server 块内有额外行 → 该站点覆盖全局设置
3. 完全没搜到 → 使用编译默认值（通常是 error）

结合 access_log 交叉定位真实请求

单看 error_log 常常无法还原现场。例如日志里有一条：

connect() failed (111: Connection refused) while connecting to upstream

这时要：

1. 查同一时间点的 access_log，找 status=502/504 的请求
2. 提取 $request_id（需提前在 log_format 中定义）
3. 在 error_log 中搜索该 request_id，获取完整上下文链

Nginx 1.11.0+ 默认已在 error 日志中打印 request id，无需额外配置即可关联。

不复杂但容易忽略。