Nginx正常提供静态资源的关键在于以正确用户身份、在分层路径上配置精准权限。需验证worker进程实际运行用户（如www-data），确保各级目录具备执行权（x），根目录用750/640而非全开，上传目录加组写但禁PHP解析，严禁将代码/配置目录置于Web根下或赋予www-data读权，并通过sudo -u www-data模拟测试读写及查看error.log验证。
让 Nginx 正常提供静态资源，关键不在“能不能读”，而在于“以谁的身份、在哪些路径上、拥有刚好够用的哪类权限”。www-data 不是万能钥匙，配置错一步，就可能触发 403、Permission denied 或意外执行风险。
确认 Nginx 实际运行用户
别只看 /etc/nginx/nginx.conf 里的 user www-data; —— 要验证它真正在用谁：
- 运行 ps aux | grep nginx：主进程显示 root，worker 进程应显示 www-data（或 nginx）
- 运行 id www-data：确认该用户存在且 shell 为 /usr/sbin/nologin
- 若用的是 CentOS/RHEL，用户名可能是 nginx，需同步调整所有权限归属和组设置
目录与文件权限必须分层控制
统一 chmod 755 / 644 是常见误区。真实环境需按用途拆解：
- 根静态目录（如 /var/www/example.com）：属主可为 deploy:www-data，目录权限 750，文件权限 640
- 上传目录（如 uploads/、images/user/）：属组 www-data，加组写权限（chmod g+w），但禁用 PHP 解析（Nginx 中用 location ~ \.php$ { deny all; }）
- 上级路径（如 /var/www、/var/www/example.com）：www-data 必须对每一级都有 x（执行）权限，否则无法进入子目录 —— 缺少任一环节都会报 Permission denied
避免敏感路径暴露与越权访问
www-data 的权限边界必须收得严：
- 代码目录（app/、src/）、配置目录（config/、env/）不能放在 Web 根下，更不能让 www-data 拥有读权限；应移出 Web 路径，属主设为 deploy，权限 700 / 600
- 日志目录（logs/） 属主建议设为 www-data:adm，权限 750，便于 logrotate 读取又不泄露给普通用户
- 切勿把整个网站目录 chown 为 www-data:www-data —— 这等于把源码、配置、私钥全交到 Web 进程手里，一旦被注入，后果严重
验证权限是否真正生效
别依赖重启后“看起来能打开”就认为搞定，要模拟 www-data 行为测试：
- 用 sudo -u www-data ls -l /var/www/example.com/public/ 看能否列出文件
- 用 sudo -u www-data cat /var/www/example.com/public/index.html 测试读取能力
- 尝试写入上传目录：sudo -u www-data touch /var/www/example.com/uploads/test.tmp，再立刻 rm 掉
- 检查 Nginx 错误日志：tail -f /var/log/nginx/error.log，实时捕获权限拒绝细节
