首页能打开，点击文章或商品却是 404；刷新一个子页面也打不开。这种现象容易让人以为 PHP 文件没上传完整。对于把请求统一交给 index.php 的项目，更应该先检查请求有没有被送到这个入口。

排查前留一份当前站点配置，再准备三个地址：首页、一个确定存在的 CSS 文件、一个确定存在的业务页面。每次只改一个地方，用这三个地址比较结果，避免把路径问题和 PHP 运行问题混在一起。

第一步：确认网站根目录指向哪里

先看项目结构。下面是常见的单入口 PHP 布局示例，并非所有项目都必须这样组织：

example-project/
├── app/
├── config/
├── vendor/
└── public/
    ├── index.php
    └── assets/
        └── site.css

这种布局一般应把网站根目录指向 example-project/public。浏览器请求 /assets/site.css，才会对应到 public/assets/site.css。项目上传目录和网站公开目录并不是一回事；在面板里调整运行目录前，先确认入口文件的真实位置。

如果连这个确实存在的 CSS 文件都打不开，优先核对域名对应的站点、实际目录、文件名大小写及读取权限。静态文件已经正常，而业务路径失败，再往下看转发规则。

第二步：让不存在的物理路径进入应用

以单入口项目为例，在对应站点已有的 location / 中配置下面的逻辑：

location / {
    try_files $uri $uri/ /index.php?$query_string;
}

Nginx 的 try_files 文档说明，它按顺序检查文件或目录；没有匹配项时，使用最后一个参数做内部转发。所以上例会先尝试原始路径，再交给 index.php，并保留查询字符串。

在宝塔这类面板中，要同时检查“伪静态”内容和站点配置里已有的规则，避免再加出两个相同的 location /。WordPress、带独立入口的系统或使用特殊路由约定的框架，应遵循各自的部署文档，不能把这一段当作万能配置。

第三步：确认 PHP 接得住这个入口

try_files 只决定请求往哪里走，实际执行 PHP 还依赖 FastCGI 配置。Nginx 官方入门指南介绍了 fastcgi_pass 以及用于定位脚本的 SCRIPT_FILENAME 参数。

如果直接访问 /index.php 也失败，应检查当前站点选用的 PHP 服务，以及传递的脚本路径是否与公开目录一致。面板生成的 PHP 配置通常已有这些内容，不要再随意粘贴另一套端口或 socket 路径。

判断哪一层返回了 404，需要看同一次请求的访问日志、Nginx 错误日志和应用日志。页面长得像 Nginx 默认错误页只能作为线索，不能单独作为结论。应用已经收到路径，却没有对应路由，也会正常返回 404。

按现象缩小范围

现象先核对什么
首页和静态文件都失败域名匹配、网站根目录、实际文件及读取权限
静态文件正常，业务子路径失败路由转发是否生效，应用是否注册了该路径
入口 PHP 也失败PHP 服务、FastCGI 连接和脚本路径
只有一部分旧链接失败路径是否变更、记录是否下架、路由参数是否正确

还有一种容易误判的情况：浏览器请求一个不存在的 JS 文件，入口应用返回了 HTML。开发者工具里可能看到状态 200，但响应内容开头是 HTML 标签。这时应修正资源路径或静态资源规则，不能只凭状态码认定文件加载成功。

保存后，怎样判断改动有效？

用当前 Nginx 安装对应的配置检测工具确认语法通过，再按面板或既有运维流程重载。随后重新检查之前准备的三个地址，同时访问一个明确不存在的页面，确认它仍然返回正确的 404，而不是所有路径都变成首页。

最后比较一次文章链接、带查询参数的列表和静态资源。这样能看出请求是否到达正确入口，也能及时发现“页面看起来好了，筛选参数却丢了”之类的问题。