排查error_log配置错误需先确认语法合法（路径、级别、分号）、级别拼写正确且小写、路径含空格须引号；再检查作用域覆盖、日志路径权限及selinux限制；最后用nginx -t查看最终生效配置并验证写入。
排查 error_log 级别配置参数错误，关键不是看日志“有没有内容”，而是确认该指令本身是否写对、是否生效、是否被覆盖——因为级别写错不会报语法错，但会导致关键错误（如 [emerg]）被静默丢弃。
先确认 error_log 指令语法是否合法
error_log 的基本格式是：error_log 文件路径 [级别];。常见错误包括：
- 漏掉分号：例如
error_log /var/log/nginx/error.log error（缺;）→ 触发[emerg] directive is not terminated by ";" - 级别拼写错误：比如写成
erorr、warnn或debugg→ 报[emerg] invalid log level "erorr" - 级别大小写敏感：必须小写，
Error或ERROR都不合法 - 路径含空格未引号包裹：如
error_log /var/log/nginx/my app.log error;→ 解析失败，报错指向该行
检查级别是否过低导致 [emerg] 不显示
[emerg] 是最高级别，理论上任何合法级别（debug 到 emerg）都应记录它。但如果配置了过高的级别（如只设 crit 或 alert），反而会漏掉部分上下文信息；更危险的是设成 notice 或 warn——虽然 [emerg] 仍会写入，但中间的 [error]、[alert] 可能被过滤，影响连贯判断。
建议：排查语法问题时，临时设为 error_log /path/to/error.log debug;（需 Nginx 编译支持 debug），或至少用 error 级别确保主干错误不丢失。
留意作用域覆盖导致实际生效的级别非预期
error_log 可在 main、http、server、location 多个层级定义，低层级会覆盖高层级。典型陷阱：
- 主配置
nginx.conf中设了error_log /var/log/nginx/error.log error; - 某个
server块里又写了error_log /dev/null emerg;→ 该 server 下所有错误（包括语法加载阶段的[emerg]）都会被丢进/dev/null，看似“没日志” - include 的子配置中重复定义，且级别更低（如
notice），可能掩盖主配置的error
排查方法：用 nginx -T（大写 T）输出**完全展开后的最终配置**，搜索所有 error_log 行，看哪个在生效位置、路径是否可写、级别是否合理。
验证日志是否真被写入而非“假空”
即使 error_log 语法正确、级别合适，也可能因以下原因看不到 [emerg]：
- 日志路径所在目录不存在，或 Nginx 运行用户（如
www-data或nginx）无写权限 - SELinux 或 AppArmor 拦截写入（尤其在 CentOS/RHEL 或 Ubuntu 严格模式下）
- 配置中用了
syslog:或memory:等非常规目标，但后端服务未就绪
快速验证：执行 sudo -u nginx touch /path/to/error.log 2>/dev/null || echo "写入失败"；或改用 nginx -e stderr 强制将错误输出到终端，绕过文件写入环节直接观察。
