调优 error_log 级别需分层控制：全局日志管 Nginx 自身异常，HTTP 上下文日志管请求链路错误；生产推荐默认全局 error、关键 server warn，临时诊断按需升至 notice/info/debug，并联动系统工具交叉验证。
调优 error_log 级别不是为了“开最大”，而是让日志在关键时刻说清关键话——既要避开信息淹没，又不能漏掉致命线索。核心在于分层控制、按需启用、快速聚焦。
区分全局与HTTP上下文的日志作用域
全局 error_log（位于 nginx.conf 最外层、events 和 http 块之外）只管 Nginx 自身：主进程启动失败、配置解析崩溃、端口绑定被拒、worker 初始化异常等。这类错误永远走全局日志，server 或 location 里的 error_log 指令对它无效。
HTTP 请求过程中的错误（如 upstream timeout、client closed connection、rewrite loop）则由 http/server/location 块内的 error_log 控制，可独立设置路径和级别。
线上故障排查时，先看全局日志是否记录了启动/重载失败；再查对应虚拟主机或接口的 HTTP 错误日志，定位具体请求链路问题。
生产环境推荐的分级策略
不建议长期开启 debug，但必须保留快速降级能力：
-
默认运行态：全局设为
error，关键业务server块设为warn—— 覆盖语法警告、连接拒绝、上游不可达等高价值告警 -
疑似配置或加载异常时：临时将全局
error_log改为notice，观察 master 启动、worker fork、模块加载顺序是否异常 -
定位信号处理或 reload 行为问题时：升到
info，能看到signal process started、reconfiguring、cycle finished等生命周期事件 -
仅限临时诊断 core 级故障：确认编译含
--with-debug后，全局设debug并指定独立文件，用grep -E "(conf|cycle|signal|init)"过滤，避免全量日志阻塞磁盘
结合 error_log 快速交叉验证的实操动作
单看日志容易误判，要立刻联动系统工具缩小范围：
- 若日志出现
bind() to 0.0.0.0:80 failed (98: Address already in use)，立即执行lsof -i :80或ss -tulnp | grep :80查端口占用 - 若报
open() "/etc/nginx/conf.d/app.conf" failed (13: Permission denied)，用namei -l /etc/nginx/conf.d/app.conf检查路径每级权限，尤其注意父目录的执行位 - 若提示
configuration file test failed，不要直接nginx -s reload，先跑nginx -t -v获取详细解析报错行号 - 若 worker 进程频繁退出且日志无明显错误，用
journalctl -u nginx -n 100 --no-pager或dmesg | tail -20查看是否被 OOM killer 杀掉
避免常见配置陷阱
很多“日志没反应”其实源于配置逻辑误区：
- 全局未声明
error_log时，默认写入logs/error.log（相对路径），而实际安装中该目录常为/var/log/nginx/，导致日志“消失”——务必显式写绝对路径 - 多个
error_log指令共存时，HTTP 上下文的会覆盖全局的级别，但不会覆盖全局路径；若想隔离日志，必须在各server块中完整指定路径+级别 -
debug级别在未编译--with-debug时静默降级为info，不报错也不提醒，可用nginx -V 2>&1 | grep -o with-debug提前验证 - 日志文件路径的父目录需对
nginx工作用户（如www-data或nginx）有写权限，否则连error级都可能无法落盘
