Nginx access_log 停止写入但服务正常，主因是 worker 用户对日志路径缺乏写权限；需检查进程用户、目录及文件属主权限、SELinux 拦截和 logrotate 权限重置。
当 Nginx 的 access_log 文件突然停止写入，但服务仍在正常处理请求，很可能是日志文件或其所在目录的写入权限不足。排查需从进程身份、路径所有权、SELinux（如启用）和日志轮转机制四方面入手。
确认 Nginx 工作进程的运行用户
Nginx 实际以配置中 user 指令指定的用户（默认常为 nginx 或 www-data）运行 worker 进程，该用户必须对日志路径有写权限。可通过以下方式确认：
- 查看主配置：
grep "^user" /etc/nginx/nginx.conf - 检查实际进程用户：
ps -o user,comm -C nginx（注意区分 master 和 worker） - 若未显式配置
user，Nginx 默认以启动时的用户（通常是 root）运行 master，但 worker 会降权——此时真正写日志的是 worker 进程用户，不是 root
检查日志路径的属主与权限
不仅日志文件本身，其**父目录**也必须允许目标用户创建、写入和遍历（即需 x 权限）。常见错误是只改了文件权限却忽略目录：
Web Accessibility (WCAG 2 AA))
下载
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
- 运行：
ls -ld /var/log/nginx/和ls -l /var/log/nginx/access.log - 确保目录属主/属组包含 Nginx worker 用户，且权限至少为
drwxr-xr-x（即其他用户可进入和写） - 日志文件权限通常不影响写入（Nginx 用
O_APPEND打开），但若文件属主不是 worker 用户且无组/其他写权限，且目录不可写，则无法追加 - 修复示例：
sudo chown nginx:nginx /var/log/nginx/ && sudo chmod 755 /var/log/nginx/
检查 SELinux 是否拦截（仅限启用 SELinux 的系统）
在 CentOS/RHEL 等默认开启 SELinux 的系统中，即使传统权限正确，也可能因安全上下文限制导致写入失败：
- 临时放行测试：
sudo setenforce 0，观察日志是否恢复；若恢复，说明是 SELinux 问题 - 查看拒绝记录：
sudo ausearch -m avc -ts recent | grep nginx或检查/var/log/audit/audit.log - 永久修复：给日志目录打上正确上下文，例如：
sudo semanage fcontext -a -t httpd_log_t "/var/log/nginx(/.*)?"，再执行sudo restorecon -Rv /var/log/nginx
排查日志轮转（logrotate）引发的权限重置
logrotate 在切割日志后可能将新文件设为 root:root 且权限为 600，导致 Nginx worker 无法写入：
- 检查 logrotate 配置（如
/etc/logrotate.d/nginx），确认是否包含create 644 nginx nginx（或对应用户/权限） - 手动触发一次轮转测试：
sudo logrotate -f /etc/logrotate.d/nginx，然后立即检查新生成的access.log属主和权限 - 若缺失
create指令，Nginx 启动时创建的日志文件会被轮转保留，但新文件由 root 创建且无写权限，worker 将静默失败
不复杂但容易忽略。重点始终是：worker 用户能否在日志目录中创建/打开/追加文件——这取决于目录权限、文件权限、SELinux 策略及轮转行为的共同作用。
