打开终端，定网敲下 nginx -T，页目屏幕上哗啦啦滚出一大段配置。定网你盯着 root /var/www/html; 这行字，页目心想：行，定网网页文件就放这儿了。页目但浏览器一访问，定网404。页目问题出在哪儿？定网大概率是你没搞清楚 nginx 到底把哪个目录当成了“家”。

很多人以为 root 指令后面跟的页目路径就是网页根目录，这话对，定网也不对。页目得看它出现在哪个上下文里。定网写在 server 块里，页目它就是定网这个虚拟主机的根；写在 location 块里，nginx 会把 location 的匹配部分拼接到 root 路径后面。举个例子：

location /static/ {  root /data/www; }

访问 /static/logo.png，nginx 实际去找的是 /data/www/static/logo.png，而不是 /data/www/logo.png。这个拼接逻辑坑过不少人。我第一次配 nginx 时就在这儿栽了跟头，明明文件放在 /data/www 下，URL 也写对了，就是 404。后来把 root 改成 alias 才通——alias 不做拼接，直接替换 location 匹配的部分。

那怎么确认当前生效的目录到底是哪个？最直接的办法是看 nginx 自己吐出来的完整配置。nginx -T 会把主配置和所有 include 进来的子配置全部打印出来，包括注释。比翻 /etc/nginx/nginx.conf 再一层层找 include 快得多。如果只想看某个 server 块的配置，用 nginx -T | grep -A 20 "server_name example.com" 也能凑合。

另一个容易忽略的点：nginx 进程的工作目录和配置里的路径是两码事。你用 ps aux | grep nginx 看到的 nginx: worker process 那个进程，它的 cwd 通常是 / 或者编译时指定的目录，跟网页根目录没半毛钱关系。别被这个误导。

如果配置里用了 root 的相对路径，比如 root html;，那它是相对于 nginx 的编译前缀（通常是 /usr/local/nginx 或 /etc/nginx）。这种写法现在很少见了，但老配置文件里偶尔能碰到。我见过一个跑了七八年的服务器，配置里写着 root html;，结果运维换人后没人知道网页文件实际在 /usr/local/nginx/html 下面，白白折腾了一下午。

还有一种情况：try_files 指令会改变实际读取的文件路径。比如：

location / {  root /var/www/site; try_files $uri $uri/ /index.html; }

访问 /about，nginx 先找 /var/www/site/about，找不到再找 /var/www/site/about/，还没有就返回 /var/www/site/index.html。这时候你去看 root 指向的目录，里面可能压根没有 about 这个文件，但页面正常显示——因为实际读的是 index.html。调试时别只看 URL 和目录的对应关系，得把 try_files 的 fallback 逻辑也考虑进去。

想实时验证 nginx 到底读了哪个文件？打开 error_log，把级别调到 debug，然后 tail -f 盯着。访问一次页面，日志里会明明白白写着 trying to open file: /var/www/site/about 之类的记录。这比猜来猜去靠谱得多。不过 debug 日志量巨大，生产环境别长时间开着。

最后提一个常见错误：改完配置用 nginx -s reload 之后，发现目录还是旧的。先别急，用 nginx -T 确认新配置真的被加载了。有时候 include 的文件路径写错，或者 sites-enabled 里的软链接断了，reload 根本不报错，但配置也没生效。我习惯 reload 之后立刻 nginx -T | grep root 扫一眼，确认目标目录变了，再去刷新浏览器。

搞清楚 nginx 绑定的网页目录，核心就三件事：看 root 或 alias 写在哪、注意路径拼接规则、用 nginx -T 和日志验证实际行为。别信直觉，信配置和日志。