企业官网建设流程全解析

如果你维护过Nginx服务器，大概率会撞上这样一种让人抓狂的时刻：站点配置检查了无数遍，location规则写得自认为滴水不漏，DNS解析一切正常，防火墙也放行了，结果页面偏偏给你一个403 Forbidden——最后折腾半天，发现只是目录少了一个执行权限。又或者更隐蔽的情况：前后端代码都没问题，但上传功能间歇性失败、日志文件不持续追加、nginx -s reload偶尔报错。这些问题的背后，绝大多数都指向同一个方向：Nginx权限问题。

“Nginx权限问题详解及解决方案”这个主题我拖了很久才动笔，因为权限问题太容易被当成普通配置错误处理。网上搜出来的答案往往是一句“把目录改成755就好了”，却没人告诉你为什么必须755、为什么有时候改成755依然不行、以及怎么用一套系统的方法把问题一次定位干净。这篇文章我会从Nginx的进程模型讲起，把“谁在什么身份下访问哪些文件”这条主线理清楚，再给出完整的排查工具链、分场景解决方案和一组能直接抄作业的权限配置规范。

如果你现在正好被某个权限问题卡住，或者想提前建立一套“权限防御体系”，这篇文章都值得花二十分钟看完。我尽量用对话的方式写，不甩术语吓人，但涉及关键原理的地方也不会含糊。

1. 权限问题的本质：进程、用户与文件权限的三角关系

1.1 先看懂Nginx的进程模型，权限问题就解决了一半

很多刚开始接触权限问题的人会有一个误区：以为Nginx就是“一个程序”，要么能访问某个路径，要么不能。实际上Nginx在运行时会分裂成两种角色完全不同的进程，权限边界也因此完全不同。

以最常见的源码编译或发行版安装方式来看，Nginx启动后通常包含：

• 一个master主进程，负责读取配置文件、管理worker进程、绑定监听端口。它通常以root身份运行，因为只有超级用户才能在Linux上绑定80或443这些1024以下的特权端口。
• 多个worker工作进程，负责实际处理HTTP请求、读取静态文件、转发反向代理请求。它们会主动放弃root身份，以配置文件里user指令指定的低权限用户运行。

这个过程本质上是一种特权分离设计。主进程保留必要权限完成启动和端口绑定，之后把实际业务处理下放到一个“尽量什么都干不了”的用户。这个用户通常叫nginx（CentOS/RHEL系）或www-data（Debian/Ubuntu系）。

所以，你在浏览器里请求一个页面，真正接触文件系统的是worker进程，也就是nginx或www-data这个用户。所有静态文件读取、日志写入、临时文件创建，都是它在执行。如果它读不了你的文件、进不了你的目录、写不了你的日志，Nginx能做的就是返回一个错误码。

理解这一点后，权限问题的答案其实很简单：让worker进程所代表的那个用户，对目标文件或目录拥有合适的权限。

1.2 文件权限的三个维度，别只盯着数字

说到权限，绕不开Linux的rwx模型。一组权限实际上分为三段：所有者（user）、所属组（group）、其他用户（other），每段分别包含读（r, 4）、写（w, 2）、执行（x, 1）三个位。合起来就是755、644、700这类数字。

但Nginx场景下有几个容易被忽略的细节：

• 目录的“执行权限”意味着“能否进入这个目录”。没有x权限的目录，里面文件再好也读不到。这就解释了为什么很多403的修复动作是给目录加x权限，而不仅仅是加r。
• 文件的“执行权限”对静态文件Nginx本身并不关心，它只要r权限就能读取内容返回给客户端。但如果你希望运行PHP之类的动态脚本，最终执行脚本的是PHP-FPM进程，那个进程通常也不是Nginx用户，又会牵扯到另一套权限关系。
• 判断能否访问一个文件，不是只看文件本身的权限，而是从根目录到文件所在位置一路上所有目录的权限都通过了才算数。这就是常说的“路径穿越权限”。

用一个生活化的类比：目录像一扇扇门，文件是放在门后的箱子。你得先能推开每一扇门（目录的x权限），才能摸到箱子；把箱子搬出来还需要读权限（文件的r）。只要中间有一扇门锁着，哪怕箱子本身敞开着，你也拿不到。

1.3 为什么权限问题如此普遍

如果你问一个运维老手“Nginx最常见的故障是什么”，他大概率会提到403或502，而这两者的根因里，“权限不匹配”能排进前三。原因是多方面的：

第一，Nginx进程的身份经常是发行版默认的nginx或www-data，但你部署站点时的操作身份通常是root或某个管理账号。这种天然的身份错位，导致创建出来的文件所有者往往是部署者而非Nginx运行者。

第二，解压代码包、挂载外部存储、拷贝备份文件时，其中带着的权限信息很多时候沿用的是源环境里的设置，没有与当前服务器上的用户体系对齐。

第三，配置user指令的人各有所好。有人改成了www，有人改成apache，有人直接用root（这是极度危险的做法），Nginx用户一旦不一致，整个权限体系就要跟着重新捋。

后面我会具体展开每种场景的修复方法，但请记住：权限问题不是一个“改个数字就解决”的玄学，它的背后是“进程身份、文件所有者、目录层级权限”这三方是否匹配的逻辑问题。

2. 最常见的权限问题现象与根因排查

2.1 403 Forbidden：一切都正常，但就是进不去

我在实际维护中遇到的403分两类：一类是明确知道自己没权限，另一类是“我以为我有权限但实际没有”。后者更坑。

第一类很容易理解：访问一个本来就不公开的文件、目录列表被关闭、或者站点根目录指向了一个不存在的位置。这类问题看一眼日志就有答案。

第二类才考验技术功底。举例说明，某次在模拟项目X中部署一个静态站点，配置写的是：

server { listen 80; server_name demo.local; root /opt/project-x/dist; index index.html; }

ls看过去/opt/project-x/dist下确实有index.html，权限是-rw-r--r--，目录是drwxr-xr-x，看起来没毛病。可访问时依然报403。

最后用namei -l /opt/project-x/dist/index.html一查，发现问题出在/opt这个目录：它的权限是drwx--x--x，其他用户只有执行权限没有读权限。对于目录来说，即使Nginx用户能“穿过”它，但因为没有读权限，实际执行中会判定为无法访问。把/opt的可读权限放开给其他用户，或把站点目录迁移到别的路径下，问题就解决了。

这个案例非常典型。它的核心启示是：权限判断是逐层进行的，任何一个中间目录的异常都会导致最终结果异常，而排查时如果只盯着最后一级目录，永远找不到真正原因。

2.2 502 Bad Gateway：有时候是权限问题在假扮网络问题

502的原因很多：后端服务没启动、端口不通、反向代理目标变了、超时等。其中有一个极少被第一时间想到的原因是Unix Socket权限问题。

当你通过fastcgi_pass unix:/run/php-fpm/www.sock;或proxy_pass http://unix:/tmp/app.sock;这类方式与后端通信时，Nginx的worker进程需要对这个socket文件拥有“连接”权限。这个权限同样走Linux文件权限模型。

很多场景下，PHP-FPM以www-data身份创建了socket文件，创建的socket默认权限可能是srw-rw----，所有者是www-data，所属组是www-data。如果Nginx worker运行身份是nginx，既不是所有者也不在同一个组，连接就会被拒绝，于是Nginx向上报告502错误。

排查这种问题的关键：一是确认后端服务确实在运行并且socket文件存在，二是看ls -l结果，确认socket文件的所有者、组和权限位是否允许Nginx用户连接。调整的办法通常包括修改PHP-FPM池配置里的listen.owner和listen.group，或者用setfacl给Nginx用户单独加权限。

这种问题之所以迷惑性强，是因为表面症状像是网络不通，各种ping、curl私有地址、重启服务都试过了，但真正的问题只是两个用户之间对同一个socket文件没有交集。

2.3 日志、PID、临时文件：写不进去的隐秘角落

与读取类权限问题相比，写入类权限问题更容易被忽视，因为它们不直接产生面向用户的错误页面，而是让服务在后台慢慢“变脏”。

最典型的是日志文件不写入。如果你发现error.log或access.log长时间不增长，先别急着怀疑流量，去/var/log/nginx/下看一眼目录权限。如果目录所有者是root，权限是drwxr-xr-x，那么Nginx worker用户就只能在里面读，不能创建或追加日志文件。日志不写、错误看不到，排查难度会指数级上升。

另一个容易遭殃的是PID文件。Nginx重载或停止时需要在/var/run/nginx.pid写入主进程ID。这个目录在多数现代系统上是临时文件系统（tmpfs），重启后清空。如果Nginx没有权限在/var/run/下创建自己的pid文件，启动时多半会报错。发行版安装的Nginx通常通过systemd或tmpfiles机制提前创建好并调整好所有者，但如果你是自己编译的Nginx，又没有写配套启动文件，就很容易在这个坑里卡住。

临时文件目录同样敏感。proxy_temp、client_body_temp、fastcgi_temp这些目录如果不存在或权限不足，会出现“大文件上传失败”“代理传输异常”等诡异现象。这些目录的路径通常由编译参数或配置文件指定，但它们可写要求的用户身份依然是worker用户。

3. 用一套方法论快速定位权限问题

前面聊了很多现象，现在进入正题：该用什么方法把权限问题一次定位清楚。我推荐一套组合拳，效率和准确率都极高。

3.1 先把权限格子填完整：ls、stat、namei 组合拳

遇到权限问题，我建议从下至上做三层检查：

第一步，用ls -l看目标文件和它父目录的基本权限。注意区分这是一个文件还是目录：文件的读权限用r，目录的进入权限用x。

第二步，用stat查看更详细的属性信息，包括所有者的UID/GID数字。这里有个容易混淆的点：有时候你看到的用户名和实际UID对不上，比如某个目录显示所有者是nginx，但在另一台机器上nginx的UID是999，在这台机器上可能是998。跨系统拷贝文件经常出现这种“看起来有权限但实际没有”的问题，用stat能看到真实UID。

第三步，用namei -l /完整/路径/目标文件一次性列出一路上每一级的权限。namei的输出会把从根目录开始的每一层所有权和权限都打印出来，一眼就能看出哪一级卡住了。

举个例子，我排查时常用的完整命令组合是：

ls -la /var/www/site stat /var/www/site/index.html namei -l /var/www/site/index.html

三条命令下来，基本能把“文件本身、父目录、全路径”三个层面的情况全部覆盖。如果你的场景更复杂，比如涉及到挂载点或软链接，建议再用df -T看文件系统类型、用readlink -f确认最终真实路径。

3.2 切换到Nginx用户复现真实身份

会读权限位之后，下一步最有效的做法是“戴上Nginx用户的帽子”去走一遍它要走的路径。具体操作方法是用sudo -u nginx或者su -s /bin/bash nginx切换到Nginx worker对应的用户，然后用一组模拟命令测试权限：

sudo -u nginx ls /var/www/site/ sudo -u nginx cat /var/www/site/index.html > /dev/null sudo -u nginx touch /var/www/site/test-write.txt sudo -u nginx -c "nginx -t"

第一个命令检验目录的可读性和可进入性，第二个命令检验文件的读权限，第三个命令检验写入权限。如果想知道某个目录是否真的可以进入并读取，cd进去再看一眼是最直观的。

这里有个细节：sudo -u在部分系统上会因为Nginx用户的shell是非交互式而报错，可以用sudo -u nginx -s /bin/bash -c "命令"强制指定shell绕过。如果连sudo都没配，就干脆chroot --userspec=nginx:nginx /bin/ls /path替代，不过日常多数据环境下sudo已经够用了。

用这种方法排查的好处是：你不再靠推测“大概有权限吧”，而是用真实的调用者身份去触碰文件系统，结果就是最直接的事实。

3.3 建立“最小权限清单”思维

纯技术手段之外，我更想强调一种思维方式：先明确目标，再规划权限。与其反复试错，不如直接列出某个功能点正常工作需要的最小权限集合。

判断一个Nginx站点要正常提供静态资源，需要满足三组权限：

• 所有静态资源文件对worker用户至少具备r权限。
• 从根目录到资源文件路径间的所有目录对worker用户至少具备x权限，如果要实现目录浏览，还需要r权限。
• 动态脚本能执行即可，但执行者不是Nginx，而是PHP-FPM；Nginx只需通过socket或TCP把请求转交出去。

判断一个Nginx进程要正常运行基础功能，需要满足：

• 配置目录和日志目录对worker用户具备写入权限。
• PID文件目录对启动用户具备写入权限。
• 缓存和临时文件目录对worker用户具备写入权限。

把上面的清单拉出来，等于把“权限需求”变成了一个可枚举的表格。之后遇到任何权限故障，只需对照这个表格逐项打勾，漏掉的那一项就是问题所在。这远比赛一发现某个地方不对就疯狂chmod 777要安全和可靠得多。

4. 分场景解决方案与实操记录

理论讲了不少，下面把每个典型场景的解决方案完整走一遍。这些方案都是我在实际项目中反复验证过的，你可以直接对照配置操作。

4.1 静态站点403：目录穿越权限的修复实例

先展示一个典型的修复过程。某次在模拟项目X中，静态页面部署完成后访问直接403。初始状态如下：

$ ls -ld /var/www drwxr--r-- 5 root root 4096 Jun 15 10:30 /var/www $ ls -ld /var/www/html drwxr-xr-x 5 root root 4096 Jun 15 10:32 /var/www/html $ ls -l /var/www/html/index.html -rw-r--r-- 1 root root 4052 Jun 15 10:33 /var/www/html/index.html

从表面看文件权限是644，目录权限是755，似乎没问题。但用namei一查才发现，/var/www这一层的权限是755而不是我习惯的755（实际是755），关键问题在于/var这一层可能没有开放执行权限。

这里就体现出namei的价值了：

$ namei -l /var/www/html/index.html f: /var/www/html/index.html drwxr-xr-x root root / drwxr-xr-x root root var drwxr--r-- root root www drwxr-xr-x root root html -rw-r--r-- root root index.html

看到没有，/var/www这一层权限是drwxr--r--，对于other用户来说有r没有x。目录没有执行权限，Nginx worker用户即使看到了这个目录的名字，也无法真正进入。

修复方式有两种，一种是调整权限：

chmod o+x /var/www

另一种是把站点根目录迁移到权限更宽松的位置，例如/srv/www/html。我更推荐在条件允许时调整站点根目录到一个完全可控的路径，而不是频繁去修改系统根目录下的权限。毕竟/var下放网站文件本来就不是一个好的目录规划习惯。

修复完成后再访问，页面正常返回200。这个案例再次验证：权限问题必须从根路径开始逐层排查，只改最后一级目录经常治标不治本。

4.2 日志目录写不进去：chown之后也要看父目录

日志类问题的修复看起来最简单，但它有一个非常容易复发的变种。

先说简单版本。错误日志不写入，排查后发现/var/log/nginx/目录权限是drwxr-xr-x，所有者和组都是root。Nginx worker用户无法创建文件，于是日志写入失败。修复动作：

chown -R nginx:nginx /var/log/nginx/ chmod 755 /var/log/nginx/

处理完这个，日志恢复写入。

但接下来是复杂版本：如果我重新安装了Nginx，或者搞了一次系统更新，/var/log/nginx/目录的所有者又变回root，日志再次写不进去。这类问题反复出现的根源在于，很多系统工具或软件包会在启动时重置某些目录的所有者，或者日志轮转工具以root身份重新创建了目录。

针对反复出现的情况，我建议用setfacl设置一个ACL默认规则，让目录后续新建的子文件自动继承给定的权限：

setfacl -R -m u:nginx:rwx /var/log/nginx/ setfacl -R -d -m u:nginx:rwx /var/log/nginx/

-d参数设置的是“默认ACL”，以后在该目录下新建的文件会自动给nginx用户留出指定权限。这样即使软件包更新时重置了目录的所有者，ACL这条线依然能兜住。

如果你不想用ACL，还有一个替代思路：让日志目录的所有者直接就是nginx，并且赋予setgid位：

chown nginx:nginx /var/log/nginx/ chmod 2775 /var/log/nginx/

2前缀的setgid位会让这个目录下新建的文件自动归入nginx组，保证组内协作写日志顺畅。这两种方案各有适用场景，ACL更灵活，但可移植性略差；setgid更简单，适合目录结构固定、不跨服务器的环境。

4.3 FastCGI socket权限：一边改池配置一边改权限

动态请求场景的权限问题往往更隐蔽，因为错误码是502而不是403。某次在某图像处理Demo项目中，Nginx配置了通过Unix Socket与PHP-FPM通信，但访问时阿里云提示502。排查过程如下：

先确认后端进程是否活着：

systemctl status php-fpm ps aux | grep php-fpm

然后看socket文件是否存在、权限如何：

ls -l /run/php-fpm/www.sock srw-rw---- 1 www-data www-data 0 Jun 15 10:40 www.sock

问题很明显：socket文件的权限是rw只给所有者和组，所有者是www-data，组也是www-data。而我的Nginx worker以nginx用户运行，既不匹配所有者也不在组内，连接必然失败。

修复方案有两个方向：

第一个方向，从Nginx侧解决：如果Nginx通过独立的worker用户运行，可以从Nginx侧指定socket文件的访问权限。但对Nginx来说，它只是连接socket的一端，不能直接改变socket文件的所有者，所以更通用的做法是修改PHP-FPM的池配置。

在PHP-FPM配置文件（如www.conf）中找到这三项：

listen.owner = nginx listen.group = nginx listen.mode = 0660

设置完成后重启PHP-FPM，它会按新的所有者重新创建socket文件。此时再访问，Nginx就能连上了。注意修改配置后不仅需要重启PHP-FPM，还需要让Nginx也重新加载一次配置，两边保持一致。

第二个方向，用ACL给Nginx用户加socket访问权：

setfacl -m u:nginx:rw /run/php-fpm/www.sock

这种方案适用于不想改动PHP-FPM池配置、又想快速恢复的情况。但它的问题在于socket文件会在后端重启后被重新创建，ACL会随之丢失，所以只适合临时救火，长期方案还是调整池配置。

顺带说一句，如果你用的是TCP端口通信（比如127.0.0.1:9000），权限问题就基本不存在了，因为通信走的是网络栈而不是文件系统。但这会引入一个新的安全考量：端口必须监听在回环地址上，不能暴露到外部网络。取舍就看具体场景了。

4.4 临时文件目录与上传功能：client_body_temp 的坑

还有一个很容易被忽略的场景跟上传功能有关。Nginx默认会把请求体（例如上传的文件）先写入临时目录，再交给后端处理。这个临时目录由client_body_temp_path指定，如果你没有显式配置，Nginx会使用编译时设定的默认目录，通常类似/var/lib/nginx/tmp/client_temp。

如果这个目录不存在或者Nginx用户没有写权限，你会遇到一个非常奇怪的症状：小文件上传成功，大文件上传失败。而且错误日志里看不到明显的权限报错，只有在很靠后的位置才会出现类似“Cannot create temp file”的线索。

这是因为小文件可能直接进了内存缓冲，没触发临时文件写入；大文件超过了缓冲区上限，必须落盘，才暴露出权限问题。

修复起来很简单：

mkdir -p /var/lib/nginx/tmp/client_temp chown -R nginx:nginx /var/lib/nginx/tmp/ chmod 700 /var/lib/nginx/tmp/

也可以用配置指令去声明一个更合适的临时目录：

client_body_temp_path /srv/nginx-tmp/client_temp; proxy_temp_path /srv/nginx-tmp/proxy_temp; fastcgi_temp_path /srv/nginx-tmp/fastcgi_temp;

无论目录放在哪，核心原则一致：该目录必须允许Nginx worker用户写文件，并且磁盘空间要充裕。很多“上传到大文件就报500”的奇葩问题，追根溯源都是这几个temp目录在作怪。

5. 权限配置的规范建议与安全平衡

5.1 最小权限原则下的标准目录结构

谈完解决方案，我想重点说说怎么从一开始就避免权限问题的反复出现。

我的建议是建立一套“部署规范”，把站点目录、日志目录、临时文件目录三者分离管理，每类目录使用固定的权限模板。

站点静态文件目录的标准权限：

• 文件：644，属主为部署账号
• 目录：755，属主为部署账号
• 如果写权限需要交给某个应用用户：单独用ACL控制，不轻易开777

日志目录的标准权限：

• 目录：755或2755，属主为nginx或指定的worker用户
• 日志文件：644，追加写入时保持属主正确

临时文件目录的标准权限：

• 目录：700或750，属主为nginx
• 不要放在Web根目录下，避免被外部直接访问

这套结构能挡住绝大多数权限问题的入侵。我见过不少线上事故，查到最后都是因为图省事把某个目录直接chmod 777。这种处理方式短期看起来好用，但它会让后续产生的所有子目录和文件都继承宽松权限，安全隐患极大。

5.2 用户分组与子目录继承：setfacl 的优雅解法

如果你的站点同时需要多个角色访问，比如Nginx读取静态文件、后端应用写缓存、日常维护账号改代码，单纯依靠 owner/group 的模式会很吃力。这时候ACL值得好好学学。

一个典型用法是，把需要读写访问的用户加入到一个公共组，然后对共享目录设置组默认权限。例如：

groupadd webapp usermod -a -G webapp nginx usermod -a -G webapp deploy mkdir -p /srv/www/myapp chown deploy:webapp /srv/www/myapp chmod 2750 /srv/www/myapp setfacl -m d:g:webapp:rwx /srv/www/myapp

这样，deploy用户可以在目录里维护文件，nginx用户也能读取文件，而新创建的子文件会自动归入webapp组并带上组读写权限。

在我实际的操作经验里，这套组合比单纯考虑chown/chmod要稳定得多，尤其在多人协作、多角色共用的服务器上，能很大程度避免“我改了权限，但另一个用户又不行了”的恶性循环。

5.3 重载、热更新等操作对权限的隐性要求

权限问题不仅影响正常请求，也会影响运维操作本身。比如当你执行nginx -s reload时，主进程需要读取配置文件、创建新的worker进程，有时还需要修改PID文件。如果配置目录权限不对，或者PID目录不可写，重载操作会静默失败，但主进程依然在跑，你会在尝试重启时突然发现“明明reload了但配置没生效”。

建议把以下路径都纳入权限检查范围：

• /etc/nginx/目录需要允许运行Nginx的系统用户读取配置
• PID文件目录（通常是/var/run/）需要允许主进程写入
• 如果使用include引入额外配置，所有被引入的配置文件同样需要可读

特别是当你使用进程管理工具（比如systemd）时，部分配置生命周期由systemd接管，它的运行身份边界可能与命令行启动模式不同，这也是很多人“手动启动正常、用systemd启动报错”的原因。

6. 常见问题速查表与避坑经验

6.1 快速对照表：现象、排查方向、解决动作

我把实践中遇到的高频权限问题整理成一张速查表，遇到问题可以直接从表格里找方向：

这张表不是万能的，但能覆盖到我日常被问到的90%的权限问题。遇到表中没有的诡异情况，回到第3节的方法论，从进程身份、路径穿透、写权限三个维度重新走一遍，基本不会跑偏。

6.2 我在实战中反复踩过的坑

说几个我在真实项目里踩过的、值得重点提示的坑，每一个都花了不少时间去定位。

第一个坑是sudo -u nginx测试时忽略shell环境。Nginx用户通常没有登录shell，直接执行sudo -u nginx ls可能没问题，但如果你需要跑一段较复杂的Shell脚本，环境变量和PATH会跟正常状态差很多，导致结果失真。我的经验是测试权限时尽量使用完整的二进制路径，比如sudo -u nginx /usr/bin/ls /path。

第二个坑是完全信任发行版默认的用户名。我曾在某台机器上发现user指令配置的是www-data，但日志目录所有者却是nginx，排查半天才发现发行版不同导致默认用户名不同。设定权限前务必先确认实际运行用户，命令是：

ps -eo user,comm | grep nginx

第三个坑是忘了递归目录时权限叠加的结果。很多人chown -R之后就不管了，但这里的风险是目录内细粒度权限可能被你的一键操作覆盖掉。比如某些文件原本用ACL精细控制着第三方程序的访问，一条chown -R会把所有ACL清掉。如果站点结构复杂，建议先备份当前权限再动手：

getfacl -R /var/www/site > site-acl-backup.txt

第四个坑是“看起来能读但实际参数不对”。文件权限正确不代表Nginx配置正确。有时候403的根源不在权限而在路径拼接，比如root指令的值没有包含完整路径，导致实际查找的文件路径和预期不一致。这虽然不算严格意义上的权限问题，但在排查流程里怎么看都像，所以也要纳入考虑范围。

6.3 从一次完整的403排查看流程设计

最后复盘一个完整的排查过程，把整篇文章的方法串起来。某站点报告所有页面都返回403，前提是昨天还正常。

我的排查顺序是：

1. 先看错误日志：tail -f /var/log/nginx/error.log，确认Nginx确实在报权限错误。
2. 用ps -eo user,comm | grep nginx确认worker用户是nginx。
3. 用namei -l /var/www/site/index.html检查全路径，发现/var/www/site正常，但/var/www下有一个挂载点，挂载后权限变成了700。
4. 用df -T /var/www/site确认文件系统类型，发现目录位于一个额外的数据盘上，数据盘的挂载选项是defaults，而数据盘本身由于之前被某程序写坏了权限。
5. 修复挂载点权限，并将站点的实际存储路径调整到/data/www/site，同时在配置中更新root指向，问题解决。整个过程约15分钟。

这次排查效率高的原因在于我没有从“改权限”做起，而是先把“路径上每一层状态”完整地拿在手里，用结构化的方式消除变量。这也是我想让你从这篇文章里带走的方法：Nginx权限问题的本质是“进程身份与文件系统权限不匹配”，只要你的排查流程覆盖了身份确认、路径穿刺、写入验证这三个维度，绝大多数问题都能在几分钟内定位清楚。

我个人在实际操作中深有体会的一点是：与其记住每个命令的拼写和每个错误码的含义，不如先建立一个关于权限的最小逻辑模型——谁在用、要做什么、路径上有什么限制。想通这三件事，你不仅能在出问题时快速解决，还能在一开始就通过合理的目录规划和ACL配置，把大半权限问题提前挡在门外。