Nginx返回默认404而非ThinkPHP自定义页，根本原因是Nginx提前终止请求未交由index.php处理；需通过error_page、try_files、子目录适配或fastcgi_intercept_errors四种方式，确保404请求兜底进入ThinkPHP路由与异常处理流程。
在Nginx环境下部署ThinkPHP项目时，你是否遇到过这样的尴尬：访问一个不存在的路由，屏幕上弹出的却是Nginx那个冷冰冰的默认404页面，而不是你精心设计的ThinkPHP自定义错误页？
问题根源其实很明确：Nginx在判定“找不到对应物理文件”后，就提前终止了请求流程，没有把这次404请求“兜底”转发给项目的统一入口——public/index.php。这样一来，ThinkPHP的路由系统和异常处理机制就完全没机会介入。别担心，下面这四种配置方法，总有一种能帮你解决这个问题。
一、启用Nginx error_page指令指向ThinkPHP入口
这个方法的核心思路是“借力打力”。我们直接利用Nginx自身的error_page机制，当它内部判定为404时，不是直接对外响应，而是悄悄做一个内部重定向，把请求（连同原始的URL信息）转交给index.php去处理。
具体操作分三步走：
1. 在Nginx的server配置块里，添加一条error_page指令，让它指向/index.php，并且务必要带上原始的URI信息：error_page 404 /index.php?$request_uri;
2. 接着，检查处理PHP的location ~ \.php$配置块，确保其中正确设置了SCRIPT_FILENAME和PATH_INFO这两个关键的FastCGI参数：fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;fastcgi_param PATH_INFO $fastcgi_path_info;
立即学习“PHP免费学习笔记（深入）”；
3. 最后，为了验证配置是否生效，可以在public/index.php文件的顶部临时加入一段调试代码：if ($_SERVER['REDIRECT_STATUS'] == '404') {
header('HTTP/1.1 404 Not Found');
echo 'ThinkPHP 404 Handler Active
'; exit;
}
如果访问不存在的URL能看到这个提示，恭喜你，配置成功了。
二、通过try_files兜底强制所有非静态请求进入index.php
如果说第一种方法是“事后补救”，那么try_files方案就是“主动预防”。它不依赖错误码，而是在请求一开始就尝试寻找对应文件，如果找不到，就一律交给index.php。这样一来，路由是否存在、是否抛出404异常，完全由ThinkPHP框架自己来判断和渲染。
配置的关键点如下：
1. 首先确认root指令已经正确指向了项目的public目录，例如：root /var/www/myapp/public;
2. 然后，在负责通用请求的location /块中，配置完整的try_files语句：try_files $uri $uri/ /index.php?$query_string;
这句配置的意思是：先尝试访问$uri这个文件，再尝试访问$uri/这个目录，如果前两者都不存在，就把请求（连同查询参数）转给/index.php。
3. 同样，在PHP处理块中，确保FastCGI参数设置无误：fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;fastcgi_param PATH_INFO $fastcgi_path_info;
4. 别忘了检查ThinkPHP自身。确保config/app.php配置文件中的'exception_handle' => \think\exception\Handle::class已启用，并且在APP_DEBUG关闭的生产环境下，能够正常渲染你定义的404模板。
三、为二级目录部署单独配置404透传路径
当你的ThinkPHP项目不是部署在网站根目录，而是像/example/这样的子路径下时，情况会稍微复杂一点。如果配置不当，Nginx传递给PHP的环境变量会缺失子目录前缀，导致框架无法正确定位入口文件，从而直接绕过路由解析，返回Nginx原生的404。
针对这种场景，配置需要更加精确：
1. 使用location /example/ {}来精确匹配子目录，而不是宽泛的location / {}。在内部，使用alias指令指向实际的public目录，并在try_files中显式带上子目录前缀：location /example/ {
alias /var/www/myapp/public/;
try_files $uri $uri/ /example/index.php?$query_string;
}
2. 在嵌套的PHP处理配置块中，最关键的一步是：必须显式地、硬编码地设置SCRIPT_FILENAME为入口文件的绝对物理路径：fastcgi_param SCRIPT_FILENAME /var/www/myapp/public/index.php;
3. 继续确保PATH_INFO参数被正确设置，以便ThinkPHP能提取出路由信息：fastcgi_param PATH_INFO $fastcgi_path_info;
4. 配置完成后如何验证？一个简单有效的方法是在public/index.php开头加入调试代码：var_dump($_SERVER['SCRIPT_NAME'], $_SERVER['REQUEST_URI']); die();
访问一个子目录下的URL，确认输出的SCRIPT_NAME值是否为/example/index.php。如果是，说明路径传递正确。
四、禁用Nginx默认404并交由FastCGI拦截后端错误
最后这种方法，适用于另一种场景：请求成功进入了ThinkPHP（比如路由存在），但框架内部逻辑主动抛出了一个404异常（例如RouteNotFoundException）。我们的目标是确保Nginx不要“多管闲事”去拦截这个由PHP返回的404，而是原封不动地将框架生成的错误页面和状态码返回给浏览器。
配置的核心是fastcgi_intercept_errors指令：
1. 在server块中开启这个开关：fastcgi_intercept_errors on;
这个指令告诉Nginx：当从FastCGI后端（即PHP）返回的状态码是400及以上的错误时，不要使用你Nginx自己的错误页，而是使用我后面error_page指令定义的规则。
2. 同时，需要确保PHP-FPM的配置中catch_workers_output = yes，避免错误信息被静默丢弃。
3. 接着，在location ~ \.php$块的末尾，添加针对404的error_page指令，并将其指向一个自定义的命名location：error_page 404 = @tp404;
location @tp404 {
rewrite ^(.*)$ /index.php?s=$1 last;
}
这里定义了一个名为@tp404的location，当接收到PHP返回的404状态码时，会将请求重写并再次传递给index.php，让框架的异常处理器有机会渲染自定义页面。
4. 当然，这一切的前提是，你的ThinkPHP应用中已经注册了全局的异常处理器，并且config('app.exception_handle')指向的类能够正确渲染HTML格式的404模板。
