Linux服务器如何配置ThinkPHP伪静态规则详解

遇到ThinkPHP伪静态规则在Linux服务器上失效，页面直接404？别急着怀疑框架或PHP版本，十有八九是Nginx的rewrite规则没写对，外加fastcgi_split_path_info这个“隐形杀手”在捣乱。今天，我们就来把这个问题彻底拆解清楚。

核心问题就一个：去掉index.php后，Nginx没能把请求正确地交给ThinkPHP处理。

为什么去掉 index.php 就 404？关键在 Nginx 的 location 和 PATH_INFO 处理

ThinkPHP（无论是5.x还是6.x版本）默认采用PATH_INFO模式来解析URL。简单来说，它期望像/index.php/user/list这样的地址，/user/list这部分能被放到$_SERVER['PATH_INFO']这个变量里。

但Nginx的默认配置往往不直接生成这个变量。它依赖一个叫fastcgi_split_path_info的指令，试图把请求路径“拆分”出来。问题恰恰出在这里：这套拆分逻辑很容易和ThinkPHP内部的路由解析机制“打架”，导致$_SERVER['PATH_INFO']要么是空的，要么是错的，最终控制器自然就找不到了。

怎么解决？记住下面几个实操要点：

• 清理干扰项：首先，检查你的Nginx配置，找到并注释掉或删除所有与fastcgi_split_path_info相关的行，包括那些用正则匹配去设置$path_info变量的地方。
• 弃用if，改用try_files：很多老教程喜欢用if (!-e $request_filename)来判断文件是否存在，然后重写。这在Nginx里不仅性能有隐患，语义也容易出问题，特别是处理子目录时。更现代、更可靠的做法是使用try_files指令。
• 规则要单一：确保重写逻辑集中在location /块里，避免在location ~ \.php$块里又写一套rewrite规则，造成冲突或重复处理。

推荐使用下面这套配置，直接放在你的server配置块内：

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

这条规则的意思是：先尝试访问请求的URI对应的真实文件或目录（$uri和$uri/），如果都不存在，就把请求统一转发给/index.php，并且把原始的查询字符串（$query_string）也带过去。这样一来，ThinkPHP就能通过$_SERVER['REQUEST_URI']或$_SERVER['QUERY_STRING']来获取路由信息，完美绕开了对PATH_INFO的依赖。

root 必须指向 public/，否则敏感目录可被直接访问

这是一个非常常见且危险的安全误区。如果你把整个ThinkPHP项目目录（包含application/、config/、runtime/等）直接设置为网站根目录，那就相当于把源代码、数据库配置文件、日志全都暴露在了互联网上。任何人访问http://你的域名/application/database.php，都可能直接下载到含有明文密码的配置文件。

正确的做法必须遵循以下步骤：

• 修正root路径：Nginx配置中的root指令，必须指向项目内的public/子目录的绝对路径。例如：root /var/www/myapp/public;
• 检查文件权限：确保public/index.php这个入口文件对Nginx的运行用户（通常是www-data或nginx）是可读的。可以用ls -l /var/www/myapp/public/index.php命令查看。
• 检查目录遍历权限：Linux的目录访问需要“执行(x)”权限。确保Nginx用户有权限逐级进入public/目录。如果/var/www/myapp的父目录（比如/var/www）对Nginx用户没有执行权，也会导致403错误。

runtime 目录权限设成 775，且必须和 Nginx 进程同组

很多人把runtime目录权限设为755后，依然遇到“mkdir(): Permission denied”的错误。这通常不是因为权限给高了，而是因为Nginx的工作进程用户（如www-data）不属于runtime目录的所属组，或者目录没有设置setgid位，导致新建的子目录组权限不对。

一劳永逸的权限设置方案如下：

• 修改目录权限：chmod -R 775 /var/www/myapp/runtime
• 修改所属组：chgrp -R www-data /var/www/myapp/runtime（将组改为你的Nginx用户所在组）
• 设置setgid位：chmod g+s /var/www/myapp/runtime。这个操作至关重要，它能保证今后在runtime目录下新建的任何文件或子目录，都会自动继承www-data组。
• 清空旧缓存：完成上述设置后，务必运行rm -rf /var/www/myapp/runtime/{cache,log,route,view}（根据你的TP版本，目录名可能略有不同），删除所有旧的缓存文件，让框架重新生成。

.env 配置和缓存未清会导致 debug 关闭、路由不生效

有时候，Nginx配置明明已经正确，但新加的URL还是返回404，甚至页面一片空白。这时候，问题可能出在框架自身配置或缓存上。

• 检查.env文件：确认.env文件位于项目根目录（与public/目录同级）。检查其中的APP_DEBUG是否设置为true，APP_ENV是否设置为local（开发环境）。如果APP_DEBUG=false，框架在遇到路由错误时可能不会显示详细错误信息。
• 清理框架缓存：修改路由或配置后，一定要执行清理命令。对于ThinkPHP 6，使用php think clear；对于ThinkPHP 5.1及以上版本，可以使用php artisan optimize:clear。
• 注意面板工具：如果你使用宝塔面板这类管理工具，记得在网站的“伪静态”设置里选择“ThinkPHP”规则并保存。它会自动覆盖你的Nginx配置文件，同时，面板的操作有时也会帮你清理runtime/temp/下的缓存。

最后，也是最容易被忽略的一点：每次修改Nginx配置文件后，必须测试并重载配置。正确的流程是：nginx -t（测试配置语法是否正确），然后systemctl reload nginx（平滑重载配置）。记住，reload不是restart，它不会中断现有连接，但前提是语法必须通过测试。