关键不是配置对不对，而是worker进程能否以自身身份逐级进入root路径并读取文件：先用ps和id确认实际用户及所属组，再用namei -l检查每级目录属主、属组和x权限，接着sudo -u模拟访问验证文件r权限与SELinux上下文，最后按最小权限原则chown/chgrp修正归属。
排查 Nginx root 路径因 Linux 属主不一致导致读取失败，关键不是“配置对不对”，而是“worker 进程能不能以它的身份走进去、打开文件”。整个链路必须全部畅通：从根目录 / 开始，逐级到 root 指定路径，再到目标文件，每一步的属主、属组和权限位都要匹配 worker 用户。
确认 Nginx worker 实际运行用户
别只看 nginx.conf 里的 user 行——它可能被注释、被 include 覆盖，或压根没生效。直接看进程：
- 运行
ps -eo pid,user,comm,args | grep nginx | grep -v grep，找出带worker字样的行，看 USER 列（常见为www-data、nginx或nobody） - 再执行
id <该用户名>，比如id www-data，确认它属于哪些组（后续设属组权限要用）
验证整条路径的属主与执行权限
Linux 中“进入目录”依赖 x（执行）权限，缺了就卡在门口，哪怕文件本身可读也白搭。重点检查 所有父目录（包括 /var、/var/www、/var/www/html 等），而不仅是 root 指向的最末一级：
- 用
namei -l /your/root/path/index.html一次性列出路径中每一级的属主、属组、权限，一目了然哪一级断了 - 手动逐级检查：
ls -ld / /var /var/www /var/www/html，确保每级对 worker 用户或其所在组有x权限（如drwxr-xr-x合理，drw-r--r--就不行） - 特别注意：如果 root 是
/home/deploy/app，而/home/deploy权限是700、属主是 deploy，那 www-data 根本进不去 —— 即使 app 目录权限再宽也没用
检查目标文件本身的读权限与 SELinux 上下文
路径能进，不代表文件能读。还要看两件事：
- 运行
sudo -u www-data ls -l /your/root/path/index.html，模拟 worker 用户视角。如果报Permission denied，说明文件或其所在目录缺 r/x 权限；如果报No such file，可能是路径拼错或大小写不符 - 在 CentOS/RHEL 等启用 SELinux 的系统上，即使权限全对，也可能被拦截。运行
ls -Z /your/root/path，确认目录上下文是httpd_sys_content_t（静态资源）或httpd_sys_rw_content_t（需写入）。若不是，用chcon -R -t httpd_sys_content_t /your/root/path修复
按最小权限原则修正归属，避免 chmod 777
改权限不如改归属安全、彻底：
- 如果整个站点由 Web 用户管理：
sudo chown -R www-data:www-data /var/www/html - 如果不能动属主（如挂载点或系统路径）：
sudo chgrp -R www-data /var/www/html && sudo chmod -R g+rx /var/www/html - 对需写入的子目录（如
storage、cache）单独处理：sudo chown www-data:www-data /var/www/html/storage && sudo chmod 750 /var/www/html/storage
