warn级别真正有用，可捕获证书过期、重定向循环、上游拒绝等高价值预警；error为默认级，仅记502/504等失败事件；notice适合验证reload；info用于排查连接/SSL逻辑；debug需--with-debug编译且仅限临时精准诊断。
调高 Nginx 错误日志级别不是为了“看到更多”，而是让关键线索不被过滤掉——比如证书过期提醒、重定向循环、上游连接拒绝前的警告，这些在 error 级别下根本不会出现。
哪些级别真正有用
日志级别从低到高是：debug → info → notice → warn → error → crit → alert → emerg。注意：设为某一级，就记录该级及更严重的所有日志（例如 warn 会包含 warn/error/crit/alert/emerg）。
- warn：生产环境推荐默认值。能捕获证书即将过期、too many redirects、upstream refused connection 等高价值预警，又不过载
- error：默认级别，只记请求失败（502/504）、模块加载失败等，但漏掉大量前置信号
- notice：适合上线前验证 reload 行为，能看到 “reconfiguring”、“start worker processes” 等生命周期事件
- info：临时用于排查连接建立、SSL 握手、upstream 选择逻辑，建议仅限单个 server 或 location 块启用
-
debug：需编译时启用
--with-debug，否则无效；仅限短时精准诊断，必须配合路径隔离和关键词过滤（如grep -E "(conf|signal|upstream)"）
按场景精准提级，不污染全局
全局设高日志级别会拖慢性能、填满磁盘。真正有效的做法是分级、分域、按需启用：
- 核心业务
server块内加：error_log /var/log/nginx/api_error.log warn; - 怀疑 SSL 握手失败？在对应
server块中写：error_log /var/log/nginx/ssl_debug.log info; - 定位偶发 502？在
location /api中临时加：error_log /var/log/nginx/upstream_trace.log debug; - 想确认 reload 是否生效？把全局
error_log（nginx.conf 最外层）改为notice，reload 后看是否出现 “reconfiguring” 日志
快速检查当前生效的配置
很多人改了 http 块却忘了某个 server 块里有独立 error_log 指令，结果调试半天日志没变化。用这条命令扫一遍：
grep -r "error_log" /etc/nginx/ --include="*.conf" | grep -v "#"
- 只在
http块出现 → 全局生效 - 某
server块内有额外行 → 该站点覆盖全局设置 - 完全没搜到 → 使用编译默认值
error
结合系统工具交叉验证
单看 error_log 容易误判。遇到典型报错，立刻联动系统命令缩小范围：
- 报
bind() to 0.0.0.0:443 failed (98: Address already in use)→ 执行ss -tulnp | grep :443 - 报
open() "/etc/nginx/ssl/key.pem" failed (13: Permission denied)→ 用namei -l /etc/nginx/ssl/key.pem查每级权限，特别注意父目录执行位 - worker 频繁退出但 error_log 无明显错误 → 运行
dmesg | tail -20看是否被 OOM killer 杀掉 - 配置校验失败 → 先跑
nginx -t -v，它会输出具体哪一行语法出错
