Nginx 如何在 Nginx 中配置错误日志 error_log 捕获系统运行异常

Nginx的error_log不捕获操作系统级异常，仅记录自身运行错误；但可通过合理配置使其反映系统异常触发的失败行为，如Permission denied、Address already in use等，并配合系统日志定位OOM、SELinux等根本原因。

Nginx 的 error_log 本身不捕获操作系统级异常（比如内存不足 OOM、内核拒绝连接、文件系统只读、SELinux 拒绝等），它只记录 Nginx 自身在运行过程中产生的错误和警告。但你可以通过合理配置 error_log + 系统层联动手段，让这些系统异常在日志中留下可追踪的线索。

关键不是“让 Nginx 主动捕获系统异常”，而是让系统异常触发 Nginx 行为失败，并确保该失败被 error_log 清晰记录下来。

明确 error_log 能记录什么、不能记录什么

1. 能记：

   1. connect() failed (111: Connection refused) → 上游服务没起来或端口未监听
   2. open() "/etc/nginx/conf.d/app.conf" failed (13: Permission denied) → 权限问题（可能是 SELinux 或目录执行位缺失）
   3. bind() to 0.0.0.0:443 failed (98: Address already in use) → 端口被占
   4. SSL_CTX_use_certificate_chain_file() failed → 证书路径不可读或格式错误

2. ❌ 不能直接记：

   1. 内核 OOM killer 杀掉 worker 进程（Nginx 不会主动写日志，只会静默退出）
   2. systemd 因 LimitNOFILE 不足拒绝启动（错误输出在 journal，不在 error_log）
   3. 磁盘满导致 write() 失败（可能表现为 log write failed，但根源是系统状态）

在 nginx.conf 中正确配置 error_log 以暴露系统异常

确保全局块（main context）有明确的 error_log 指令，且级别足够：

# nginx.conf 顶部，user 和 pid 之后、events 之前error_log /var/log/nginx/error.log warn;

1. warn 是生产推荐起点：比 error 多一层提示（如证书过期、指令弃用、权限拒绝），又不会像 info/debug 那样淹没关键信号
2. 路径 /var/log/nginx/error.log 必须存在，且 Nginx 运行用户（如 www-data 或 nginx）对该文件及其父目录有 写权限 + 执行权限（对目录）
3. 不要留空或指向 /dev/null —— 否则所有线索都会丢失

让系统异常“落地”到 error_log 的实操要点

当系统出问题时，Nginx 往往因调用失败而报错。你要做的是让这些失败不被忽略、不被静默降级：

1. 权限类异常（Permission denied）

   1. 确保 error_log 级别 ≥ warn（warn 就能记录 open() ... failed (13: Permission denied)）
   2. 检查路径每级权限：namei -l /etc/nginx/ssl/example.key，确认所有父目录都有 x 位，文件有 r 位
   3. 若启用了 SELinux：ausearch -m avc -ts recent | grep nginx 查拒原因，或临时 setenforce 0 验证

2. 资源耗尽类（Too many open files）

   1. error_log 必须设为 alert 或 crit 级别（默认 error 不记录）：

      error_log /var/log/nginx/error.log alert;

   2. 同步调高系统限制：/etc/security/limits.conf + systemd LimitNOFILE + nginx.conf 中 worker_rlimit_nofile
   3. 出现 accept() failed (24: Too many open files) 时，立刻查 lsof -u www-data | wc -l 和 /proc/sys/fs/file-nr

3. 端口/网络类（Address already in use, Connection refused）

   1. error_log 默认 error 级别就能记录，无需调高
   2. 紧跟日志查系统状态：

      ss -tulnp | grep ':80|:443' # 看谁占着端口ping -c 3 upstream-host # 判断是网络不通还是服务宕了telnet upstream-host 8080 # 测试 TCP 连通性

4. OOM 或进程被杀

   1. error_log 不会直接记录，但你会看到 worker 进程反复退出、无错误信息
   2. 此时必须跳出 Nginx 日志，查：

      dmesg | tail -20# 看内核是否 OOM killer 了 nginxjournalctl -u nginx -n 50 --no-pager # systemd 启动失败详情ps aux | grep nginx | grep -v grep # 确认 master 是否存活

生产环境建议的 error_log 分层策略

1. 全局 error_log /var/log/nginx/error.log warn; —— 抓住所有影响稳定性的系统交互失败
2. 关键 server 块内单独加：error_log /var/log/nginx/ssl-error.log warn; —— 隔离 TLS 相关权限/证书问题
3. 临时排查时，可升全局为 notice（看 master 启动/worker fork）或 info（看 reload 信号流），但不要长期开启

不复杂但容易忽略：error_log 是你和系统异常之间的第一道翻译器——它不制造线索，但能帮你把系统发出的“哑信号”转成可读文字。