error_log指令在main、http、server、location四个作用域均可配置，优先级由近及远：server块内设置仅作用于该虚拟主机，未设置则继承http块配置，均未设置才使用main块默认值；location内虽可设但不推荐，除非需关闭某路径日志。
error_log 指令在哪写才生效
它不是只在 nginx.conf 顶部写一次就全局覆盖——error_log 可以出现在 main、http、server、location 四个作用域，优先级由近及远：某个 server 块里写了，就只管这个虚拟主机；没写就继承上层 http 的；都没写才用 main 块的默认值。
常见错误是改了全局配置却看不到效果，其实是因为某处 server 块里已有独立 error_log 行，把它覆盖掉了。
- 快速定位所有生效位置：
grep -r "error_log" /etc/nginx/ --include="*.conf" - 若输出中某行含
error_log /var/log/nginx/error.log warn;，说明该块已设为warn -
location块内也可设，但一般不推荐（除非要关掉某路径的错误日志，如用error_log /dev/null crit;）
warn / info / debug 级别怎么选
级别不是越低越好，而是按排查目标选：
-
warn：适合生产环境关键域名，能捕获证书过期、upstream refused connection、重定向跳转超限等可恢复但需人工介入的问题 -
info：适合调试服务启停、worker fork、模块加载顺序，比如 reload 后 worker 没起来，看info能确认 cycle 初始化是否完成 -
debug：必须满足两个硬条件才有效——nginx -V 2>&1 | grep -o with-debug有输出，且配置中显式写成error_log /path/to/debug.log debug;；只写debug不指定路径或路径不可写（如权限不对），会静默失效
别在生产环境长期开 info 或更低，磁盘 I/O 和日志体积会明显上涨，尤其高并发时。
修改后 nginx -t 和 reload 必须都做
只改配置不校验，可能 syntax error 导致 reload 失败，甚至主进程退出。必须分两步：
- 先运行
nginx -t，看到configuration file ... syntax is ok才继续 - 再执行
systemctl reload nginx或nginx -s reload；用kill -HUP是老做法，不推荐 - 如果 reload 报错说
could not open error log file: Permission denied，说明 worker 用户（如www-data或nginx）对日志路径无写权限，得chown或chmod对应目录
注意：改完 error_log 级别后，旧日志文件不会自动清空，新级别只对后续新产生的错误生效。
debug 日志太刷屏，怎么过滤关键内容
启用 debug 后，单秒几百行很常见，直接 tail -f 几乎没法读。得靠管道实时过滤：
- 关注配置加载过程：
tail -f /var/log/nginx/debug.log | grep -E "(conf|cycle|init)" - 查信号处理路径：
tail -f /var/log/nginx/debug.log | grep "signal" - 定位 SSL 协商失败：
tail -f /var/log/nginx/debug.log | grep -i "ssl\|handshake"
别忘了：debug 日志一旦确认问题，立刻调回 warn 或 error，避免持续刷盘。它的存在意义是“精准打点”，不是“常驻监控”。
