Nginx access_log写入失败时静默丢弃日志，不重试、不告警、不降级；根本原因常为日志路径各级目录缺少x执行权限，导致Nginx工作进程无法遍历访问，需逐级检查ls -ld权限并修复为755或显式添加x。
当 Nginx 的 access_log 指定路径无法写入日志时，目录缺少执行权限（x 权限）是一个容易被忽略但很关键的原因——尤其在 Linux 中，对目录而言，执行权限决定能否进入该目录、访问其下的文件或子目录。即使日志文件所在目录的属主和写权限都正确，若缺少 x，Nginx 工作进程（通常以非 root 用户如 www-data 或 nginx 运行）将无法“遍历”到目标路径，导致日志静默失败。
确认日志路径是否可被 Nginx 进程访问
先明确 Nginx 实际使用的用户（查看 nginx.conf 中的 user 指令，如 user www-data;），再模拟该用户检查路径遍历能力：
- 用
sudo -u www-data ls -ld /var/log/nginx/查看目录权限（注意末三位是否含x，如drwxr-xr-x✅，drw-r--r--❌） - 逐级检查完整路径中每一级目录（如
/var/log/nginx/access.log需要/var、/var/log、/var/log/nginx均有x） - 特别注意：若路径含软链接，需对链接本身及其指向目录分别检查
x权限
验证是否因权限导致日志缺失
不依赖日志内容，直接观察系统行为：
- 手动创建测试文件：
sudo -u www-data touch /var/log/nginx/test.log—— 若报Permission denied，基本锁定为权限问题 - 检查 Nginx 错误日志（
error_log）是否有类似open() "/var/log/nginx/access.log" failed (13: Permission denied)的记录（错误码 13 对应 EACCES，常由目录无 x 权限引发） - 临时改用
access_log /dev/stdout;并重载配置，若能看到日志输出，说明配置和模块正常，问题在磁盘路径权限
修复目录执行权限
仅添加缺失的执行权限，避免过度开放：
Web Accessibility (WCAG 2 AA))
下载
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
- 给日志目录加
x：sudo chmod +x /var/log/nginx/（若父目录也缺，同理处理） - 更安全的做法是明确设置：
sudo chmod 755 /var/log/nginx/（保证属主可读写执行，组及其他可读执行） - 确保目录属主与 Nginx 运行用户一致：
sudo chown www-data:www-data /var/log/nginx/ - 重载 Nginx：
sudo nginx -s reload，再触发请求，检查日志是否生成
预防类似问题
部署或变更日志路径时养成习惯：
- 新建日志目录后，立即用 Nginx 运行用户测试
ls和touch - 避免使用过于严格的 umask（如
077）创建目录，它会默认去掉组和其他的x - 在 Ansible/Chef 等自动化脚本中，显式设置目录权限为
0755而非仅0644
目录执行权限不是“可有可无”的附加项，而是 Linux 文件系统访问控制的基础环节。排查时盯住路径每一级的 ls -ld 输出，比反复检查日志配置更直接有效。
