Nginx 如何排查 Nginx 目录中日志文件权限被修改导致日志无法写入故障

最常见原因是logrotate重置属主或手动操作波及父目录；需验证Nginx工作进程用户能否持续打开并追加写入error_log，检查完整路径权限（含各级x权限）、logrotate配置是否含create与su指令，并通过tail -f触发错误实时观察写入行为。

日志无法写入，最常见原因是权限被意外修改——比如 logrotate 重置了属主，或手动 chown/chmod 操作波及了父目录。排查关键不是看当前文件权限，而是验证 Nginx 工作进程能否持续、稳定地打开并追加写入 error_log 文件。

确认 Nginx 实际运行用户

配置里的 user 指令可能未生效，必须以真实进程为准：

1. 运行 ps aux | grep nginx，找到 worker 进程那一行，第二列即为实际用户（如 www-data 或 nginx）
2. 核对 /etc/nginx/nginx.conf 开头的 user 行是否一致；若用 systemd，还需检查 /lib/systemd/system/nginx.service 中的 User= 设置
3. 该用户就是后续所有权限检查的基准主体

检查 error_log 文件及其完整路径权限

Linux 要求“可写入” = “目标文件可写” + “所有父目录可进入（x 权限）”，缺一不可：

1. 查日志路径：从 nginx -T | grep error_log 获取实际路径（如 /var/log/nginx/error.log）
2. 执行 namei -l /var/log/nginx/error.log，逐级查看每层目录的属主、属组和权限，重点识别哪一级缺失 x（例如 /var/log 权限是 drwxr-x---，而 Nginx 用户不属于 log 组，就进不去）
3. 确保 error.log 文件本身属主/属组匹配 Nginx 用户（如 www-data:adm），且权限至少为 644；若已存在，还要确认它没被其他进程独占锁定

验证日志是否真在写入，而非静默失败

启动成功不代表日志持续可用，必须主动触发并观察：

1. 执行 tail -f /var/log/nginx/error.log，另起终端触发一个错误（如访问一个不存在的 upstream，或故意配错 proxy_pass）
2. 观察 tail 是否立即新增一行类似 connect() to ... failed (13: Permission denied) 的记录
3. 若无更新，立刻检查系统日志：journalctl -u nginx --since "5 minutes ago" | grep -i "open|permission|log"，找启动或重载时的原始报错

重点排查 logrotate 导致的权限回退

这是生产环境中最隐蔽也最高频的原因：日志轮转后新建文件自动归 root 所有，Nginx 随即失写权限：

1. 查看 /etc/logrotate.d/nginx，确认是否包含 create 640 www-data adm 和 su www-data adm（或对应用户/组）
2. 手动强制轮转测试：sudo logrotate -f /etc/logrotate.d/nginx，然后立刻运行 ls -l /var/log/nginx/error.log 看新建文件属主是否仍是 www-data
3. 若属主变回 root，说明 create 或 su 未生效，需修正配置并等待下一轮自动执行，或临时补救：sudo chown www-data:adm /var/log/nginx/error.log

排除符号链接与安全模块干扰

这两类问题不会直接报错，但会导致日志路径解析失败或系统级拦截：

1. 运行 ls -l /var/log/nginx/error.log，若显示 lrwxrwxrwx，说明是软链；再用 readlink -f /var/log/nginx/error.log 获取真实路径，并对真实路径重复上述权限检查
2. CentOS/RHEL 上运行 getenforce，Ubuntu/Debian 上运行 aa-status；若启用，临时设为 permissive 或 disable 后重启 Nginx 测试是否恢复写入