最常见原因是logrotate重置属主或手动操作波及父目录；需验证nginx工作进程用户能否持续打开并追加写入error_log，检查完整路径权限（含各级x权限）、logrotate配置是否含create与su指令，并通过tail -f触发错误实时观察写入行为。
日志无法写入，最常见原因是权限被意外修改——比如 logrotate 重置了属主，或手动 chown/chmod 操作波及了父目录。排查关键不是看当前文件权限，而是验证 Nginx 工作进程能否持续、稳定地打开并追加写入 error_log 文件。
确认 Nginx 实际运行用户
配置里的 user 指令可能未生效，必须以真实进程为准：
- 运行
ps aux | grep nginx，找到 worker 进程那一行，第二列即为实际用户（如www-data或nginx） - 核对
/etc/nginx/nginx.conf开头的user行是否一致；若用 systemd，还需检查/lib/systemd/system/nginx.service中的User=设置 - 该用户就是后续所有权限检查的基准主体
检查 error_log 文件及其完整路径权限
Linux 要求“可写入” = “目标文件可写” + “所有父目录可进入（x 权限）”，缺一不可：
- 查日志路径：从
nginx -T | grep error_log获取实际路径（如/var/log/nginx/error.log） - 执行
namei -l /var/log/nginx/error.log，逐级查看每层目录的属主、属组和权限，重点识别哪一级缺失x（例如/var/log权限是drwxr-x---，而 Nginx 用户不属于log组，就进不去） - 确保
error.log文件本身属主/属组匹配 Nginx 用户（如www-data:adm），且权限至少为644；若已存在，还要确认它没被其他进程独占锁定
验证日志是否真在写入，而非静默失败
启动成功不代表日志持续可用，必须主动触发并观察：
- 执行
tail -f /var/log/nginx/error.log，另起终端触发一个错误（如访问一个不存在的 upstream，或故意配错proxy_pass） - 观察
tail是否立即新增一行类似connect() to ... failed (13: Permission denied)的记录 - 若无更新，立刻检查系统日志：
journalctl -u nginx --since "5 minutes ago" | grep -i "open\|permission\|log"，找启动或重载时的原始报错
重点排查 logrotate 导致的权限回退
这是生产环境中最隐蔽也最高频的原因：日志轮转后新建文件自动归 root 所有，Nginx 随即失写权限：
- 查看
/etc/logrotate.d/nginx，确认是否包含create 640 www-data adm和su www-data adm（或对应用户/组） - 手动强制轮转测试：
sudo logrotate -f /etc/logrotate.d/nginx，然后立刻运行ls -l /var/log/nginx/error.log看新建文件属主是否仍是www-data - 若属主变回
root，说明create或su未生效，需修正配置并等待下一轮自动执行，或临时补救：sudo chown www-data:adm /var/log/nginx/error.log
排除符号链接与安全模块干扰
这两类问题不会直接报错，但会导致日志路径解析失败或系统级拦截：
- 运行
ls -l /var/log/nginx/error.log，若显示lrwxrwxrwx，说明是软链；再用readlink -f /var/log/nginx/error.log获取真实路径，并对真实路径重复上述权限检查 - CentOS/RHEL 上运行
getenforce，Ubuntu/Debian 上运行aa-status；若启用，临时设为 permissive 或 disable 后重启 Nginx 测试是否恢复写入
