nginx -t 不报权限问题，因其仅校验语法合法性，不验证路径存在性、目录可写性及用户执行权限；权限检查发生在worker进程运行时，失败则静默丢弃日志，不报错、不中断请求。
配置语法检查（nginx -t）本身不会报出 access_log 路径权限不足的问题——它只校验配置文件格式和指令合法性，不验证路径是否存在、目录是否可写、用户是否有权限进入。所以即使 nginx -t 显示 “syntax is ok”，access_log 仍可能完全不写入，且 error_log 里也查不到错误。
为什么 nginx -t 看不出权限问题
因为权限检查发生在 worker 进程运行时，而非配置加载阶段。Nginx 启动后由 master 派生 worker，worker 以指定用户（如 www-data）尝试 open() 日志文件。若失败，Nginx 默认静默丢弃日志，不记录错误、不中断请求、也不退出进程。
-
nginx -t只读取配置、解析语法、检查路径字符串是否合法（比如有没有未闭合引号） - 它不会用 worker 用户身份去
stat()或open()日志路径 - 即使
/var/log/nginx/access.log所在目录不存在、权限为 700、或父目录无 x 权限，-t也不会提示
真正有效的排查动作
绕过语法检查，直接验证运行时权限链：
- 查 Nginx 实际工作用户：
ps aux | grep "nginx: worker" | head -1，看 USER 列（如 www-data） - 确认 access_log 配置的真实路径：
grep -r "access_log" /etc/nginx/，注意是否含变量或相对路径 - 逐级检查路径权限：例如日志路径是
/data/logs/nginx/access.log，执行namei -l /data/logs/nginx/access.log—— 它会列出/→/data→/data/logs→/data/logs/nginx→/data/logs/nginx/access.log每一级的属主、属组和权限，重点看每一级是否对 worker 用户有 x（进入）权限 - 模拟写入测试：
sudo -u www-data touch /data/logs/nginx/test.log 2>/dev/null && echo "ok" || echo "fail"
启动时捕获早期权限失败
有些权限问题会在 master 初始化日志模块时暴露，但被默认忽略。可用以下方式强制输出：
- 停止服务：
sudo systemctl stop nginx - 手动前台启动并重定向错误：
sudo nginx -c /etc/nginx/nginx.conf -e stderr - 观察终端输出：若日志路径不可写、父目录不可进入，会立即打印类似
open() "/data/logs/nginx/access.log" failed (13: Permission denied)
常见权限陷阱
这些情况 nginx -t 全部无法发现：
- 日志路径含多级目录（如
/a/b/c/d/access.log），其中/a/b权限是 700，www-data 进不去 - 日志目录归属为 root:root，但未给组或其他用户 x 权限，且未把 www-data 加入对应组
- 使用了符号链接作为日志路径，而链接目标目录权限不对，或链接自身被删（
readlink返回空） - SELinux 启用状态下，
nginx_var_run_t上下文未正确赋予日志目录（ls -Z /var/log/nginx可查）
