监控error_log写入是否成功是发现权限风险最直接手段，因Nginx启动或重载时若无法写入会立即报错（如“could not open error log file”），否则将静默失败导致后续错误丢失；需检查终端/systemd日志、文件属主与权限、父目录x权限、logrotate配置及用strace验证写入行为。
监控 error_log 本身写入是否成功，是发现权限风险最直接的手段——因为 Nginx 启动或重载时若无法写入 error_log，会立刻在终端或系统日志中报错，而一旦静默失败，后续所有错误都将丢失，运维就彻底“失明”。
看启动阶段是否爆出 Permission denied
Nginx 主进程初始化时，会尝试打开 error_log 文件。如果权限不足，它不会静默跳过，而是输出明确错误：
- [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied)
- 该提示通常出现在执行
nginx -t或systemctl start nginx时的控制台输出中 - 若使用 systemd，可通过
journalctl -u nginx -n 50 --no-pager查看最近启动日志
检查 error_log 是否真正有新内容写入
即使启动成功，日志也可能在运行中因权限变化而中断写入。需主动验证：
- 用
ls -l /var/log/nginx/error.log确认文件属主/属组与 Nginx 工作用户一致（如www-data:www-data） - 执行
tail -f /var/log/nginx/error.log，再手动触发一个错误（例如访问一个不存在的 upstream），观察是否有新行出现 - 若无更新，立即检查父目录权限：
namei -l /var/log/nginx/error.log，确认每一级路径对 Nginx 用户都有执行（x）权限
警惕 logrotate 导致的权限回退
日志轮转后新建的 error.log 往往归属 root:root、权限 644，Nginx 工作进程便无法继续写入：
- 查看
/etc/logrotate.d/nginx是否包含create 640 www-data www-data和su www-data www-data - 手动测试轮转：
sudo logrotate -f /etc/logrotate.d/nginx，然后立刻检查新 error.log 的属主和权限 - 若发现新建文件属主为 root，说明配置未生效，需修正后重启 logrotate 服务或等待下一轮自动执行
用 strace 捕获实时写入失败行为
当常规检查无异常但日志仍停更时，可用系统调用追踪定位真实原因：
- 找到主进程 PID：
cat /run/nginx.pid - 运行：
sudo strace -p $(cat /run/nginx.pid) -e trace=openat,write -s 256 2>&1 | grep -i "error\|log" - 若看到
openat(..., "error.log", O_WRONLY|O_APPEND|O_CREAT, 0644) = -1 EACCES (Permission denied)，即确认是权限拒绝
