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 能记录什么、不能记录什么
-
✅ 能记：
-
connect() failed (111: Connection refused)→ 上游服务没起来或端口未监听 -
open() "/etc/nginx/conf.d/app.conf" failed (13: Permission denied)→ 权限问题（可能是 SELinux 或目录执行位缺失） -
bind() to 0.0.0.0:443 failed (98: Address already in use)→ 端口被占 -
SSL_CTX_use_certificate_chain_file() failed→ 证书路径不可读或格式错误
-
-
❌ 不能直接记：
- 内核
OOM killer杀掉 worker 进程（Nginx 不会主动写日志，只会静默退出） -
systemd因LimitNOFILE不足拒绝启动（错误输出在 journal，不在error_log） - 磁盘满导致
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;
-
warn是生产推荐起点：比error多一层提示（如证书过期、指令弃用、权限拒绝），又不会像info/debug那样淹没关键信号 - 路径
/var/log/nginx/error.log必须存在，且 Nginx 运行用户（如www-data或nginx）对该文件及其父目录有 写权限 + 执行权限（对目录） - 不要留空或指向
/dev/null—— 否则所有线索都会丢失
让系统异常“落地”到 error_log 的实操要点
当系统出问题时，Nginx 往往因调用失败而报错。你要做的是让这些失败不被忽略、不被静默降级：
-
权限类异常（Permission denied）
- 确保
error_log级别 ≥warn（warn就能记录open() ... failed (13: Permission denied)） - 检查路径每级权限：
namei -l /etc/nginx/ssl/example.key，确认所有父目录都有x位，文件有r位 - 若启用了 SELinux：
ausearch -m avc -ts recent | grep nginx查拒原因，或临时setenforce 0验证
- 确保
-
资源耗尽类（Too many open files）
-
error_log必须设为alert或crit级别（默认error不记录）：error_log /var/log/nginx/error.log alert;
- 同步调高系统限制：
/etc/security/limits.conf+ systemdLimitNOFILE+nginx.conf中worker_rlimit_nofile - 出现
accept() failed (24: Too many open files)时，立刻查lsof -u www-data | wc -l和/proc/sys/fs/file-nr
-
-
端口/网络类（Address already in use, Connection refused）
-
error_log默认error级别就能记录，无需调高 - 紧跟日志查系统状态：
ss -tulnp | grep ':80\|:443' # 看谁占着端口 ping -c 3 upstream-host # 判断是网络不通还是服务宕了 telnet upstream-host 8080 # 测试 TCP 连通性
-
-
OOM 或进程被杀
-
error_log不会直接记录，但你会看到 worker 进程反复退出、无错误信息 - 此时必须跳出 Nginx 日志，查：
dmesg | tail -20 # 看内核是否 OOM killer 了 nginx journalctl -u nginx -n 50 --no-pager # systemd 启动失败详情 ps aux | grep nginx | grep -v grep # 确认 master 是否存活
-
生产环境建议的 error_log 分层策略
- 全局
error_log /var/log/nginx/error.log warn;—— 抓住所有影响稳定性的系统交互失败 - 关键
server块内单独加：error_log /var/log/nginx/ssl-error.log warn;—— 隔离 TLS 相关权限/证书问题 - 临时排查时，可升全局为
notice（看 master 启动/worker fork）或info（看 reload 信号流），但不要长期开启
不复杂但容易忽略：error_log 是你和系统异常之间的第一道翻译器——它不制造线索，但能帮你把系统发出的“哑信号”转成可读文字。
