error_log级别共8级，从低到高为debug、info、notice、warn、error、crit、alert、emerg；生产环境推荐全局设error、关键server设warn，debug需编译启用--with-debug且仅临时精准使用。
error_log 级别不是越低越好，也不是越高越安全，而是按需分级、分层控制——让每条日志都落在它该在的位置。
各级别的含义与触发信号
nginx error_log 共 8 级，从低到高为：debug → info → notice → warn → error → crit → alert → emerg。这不是简单“详细 vs 简略”的二分，而是对应不同系统行为阶段的信号强度：
-
debug：记录变量值、配置加载顺序、信号处理路径、cycle 初始化细节——只在编译含
--with-debug时有效，且必须显式写error_log path debug - info：服务启停、worker fork 成功、模块加载完成等生命周期事件
- notice：配置重载成功、SSL 会话复用启用、缓存 zone 创建完成等“值得留意但无需干预”的状态
- warn：证书即将过期、重定向跳转超限、upstream 连接被拒绝、临时文件缓冲告警
- error：502/504 上游错误、open() 失败（如找不到静态文件）、proxy_pass 超时、Lua 模块执行异常
-
crit 及以上：内存分配失败（
crit）、主进程退出前最后日志（alert）、配置语法致命错误导致无法启动（emerg）
生产环境分层配置策略
全局设太细会淹没关键线索，全设太高又漏掉预警信号。推荐按作用域分层设置：
-
main 块（全局）：设为
error—— 覆盖 worker 异常退出、模块初始化失败、配置解析崩溃等基础稳定性问题 -
server 块（关键业务域名）：设为
warn—— 捕获证书过期、TLS 协商失败、重定向循环、upstream refused connection 等可恢复但需关注的问题 -
location 块（如 /api 或 /admin）：可单独设
error或关闭（error_log off）—— 避免 404、favicon.ico 缺失等低价值噪音 -
调试临时启用：reload 异常或 worker 启动卡住时，临时升为
notice或info，观察 fork、cycle、init 相关日志
debug 级别的实操前提与风险控制
debug 不是加个单词就能开，它有硬性门槛和强约束：
- 必须验证编译参数：
nginx -V 2>&1 | grep -o with-debug，无输出则无效 - 必须显式指定路径与级别：
error_log /var/log/nginx/debug.log debug，仅写debug不生效 - 路径需对 worker 用户（如 www-data）可写，否则静默失效
- 启用后务必配合过滤使用，例如：
tail -f /var/log/nginx/debug.log | grep -E "(conf|signal|cycle)"，避免刷屏 - 容器环境中建议输出到 syslog：
error_log syslog:server=unix:/dev/log debug，交由 journald 统一限流与轮转
按故障类型匹配日志级别
查什么问题，就调什么粒度，避免盲目拉高或压低：
-
启动失败（报 emerg）或 reload 报错：先看全局
error_log，同时运行nginx -t -v定位语法错误行号 -
502/504 频发：在对应
upstream或server块内设error_log warn，聚焦连接拒绝、超时、健康检查失败 -
Permission denied 类错误：设
notice或info，观察 openat()、stat() 等系统调用路径，并同步查dmesg | tail -20排查 SELinux 或 OOM -
疑似 SSL/TLS 握手失败：在 server 块设
error_log debug，重点过滤ssl_do_handshake和tls_parse_*关键字
