nginx -t 不检查 pid 目录权限，仅校验语法；启动或 reload 失败报“permission denied”时，需确认运行用户（如 nginx）、逐级目录可进入（x）与可写（w）权限、selinux 状态及 systemd-tmpfiles 自动重建机制。
排查 PID 文件目录无写入权限，不能只靠 nginx -t——它只校验配置语法是否合法，**完全不检查路径是否存在、权限是否足够、用户是否有权写入**。真正出问题时，nginx -t 会显示“syntax is ok”，但启动或 reload 仍失败，报错如 open() "/run/nginx.pid" failed (13: Permission denied) 或直接找不到文件。
确认 nginx 实际运行用户
别只看 nginx.conf 里的 user 行，它可能被注释、被覆盖或未生效：
- 查正在运行的 worker 进程：
ps -eo pid,user,comm,args | grep nginx | grep -v master，看 USER 列（常见为nginx或www-data） - 若 Nginx 尚未启动，可临时用 root 启动一次：
sudo nginx -c /etc/nginx/nginx.conf，再执行上条命令确认 - PHP 环境下也可在 Web 请求中执行：
<?php echo posix_getpwuid(posix_geteuid())['name']; ?>
检查 PID 目录的逐级权限
PID 文件路径（如 /run/nginx.pid）从根到最末一级都必须满足两个条件：每层有 可进入（x）权限，最终目录所在父路径还需有 可写入（w）权限：
- 执行：
ls -ld /run /run/nginx.pid（注意不是看文件本身，而是看其所在目录/run） - 关键点：
/run必须是drwxr-xr-x或更宽松；若为drw-r--r--，Nginx 用户连目录都进不去，自然无法创建或写入 pid 文件 - 常见陷阱：目录属主是
root:root，权限755是 OK 的；但若权限是750，而 Nginx 用户既不是 owner 也不在 group 中，就会静默拒绝
修复目录归属与权限
按最小权限原则操作，避免 chmod 777：
- 确保目录存在且属主正确：
sudo mkdir -p /run/nginx && sudo chown nginx:nginx /run/nginx - 设安全权限（仅对目录加 x，不影响文件）：
sudo chmod 755 /run/nginx - 如果 PID 路径是
/var/run/nginx.pid，注意/var/run通常是/run的符号链接，实际操作目标仍是/run下对应子目录
留意 SELinux 和 systemd-tmpfiles 干扰
某些系统（如 CentOS/RHEL/Alpine）启用 SELinux 后，即使权限全对，也会静默拦截：
- 检查状态：
sudo sestatus -v，若为enforcing，临时放开：sudo setsebool -P httpd_write_content 1 - 长期方案：打 SELinux 上下文标签：
sudo semanage fcontext -a -t httpd_pid_t "/run/nginx(/.*)?"，再执行sudo restorecon -Rv /run/nginx - systemd 系统中，
/run是临时文件系统，重启后清空。应通过tmpfiles.d配置自动重建目录：echo "d /run/nginx 0755 nginx nginx -" | sudo tee /etc/tmpfiles.d/nginx.conf
