Nginx怎样配置ThinkPHP的URL重写_Nginx重写规则适配ThinkPHP【详解】

ThinkPHP在Nginx下遭遇404？根本在于请求未“进门”

有没有遇到过这种情况？明明已经把ThinkPHP项目部署到了Nginx服务器上，但访问时却必须带上index.php（比如https://example.com/index.php/index/hello），否则就直接给你一个冷冰冰的404页面。这背后的根本原因其实很明确：Nginx默认把请求当成了静态文件去查找，没找到，就直接返回404了，请求压根就没被传递到public/index.php这个框架入口。框架的路由机制自然也就无从启动。

下面，我们就来详细拆解几种适配不同ThinkPHP版本的Nginx重写配置方案，让你彻底告别URL重写失效的烦恼。

一、标准try_files方案（ThinkPHP 6.x首选）

对于ThinkPHP 6.x，官方最推荐的方式是使用try_files指令。这个方案非常“原子化”，它能优雅地处理路径匹配，避免重写规则陷入循环，并且能完美兼容QUERY_STRING的传递。其核心逻辑是：优先尝试匹配真实的静态文件或目录，如果都不存在，再将请求统一交给index.php处理，同时保留原始的查询参数。

具体配置步骤如下：

1. 打开你的站点Nginx配置文件，找到server块，在location /这个配置段内，添加下面这行核心规则：

try_files $uri $uri/ /index.php?$query_string;

立即学习“PHP免费学习笔记（深入）”；

2. 接下来是关键一步：确保在处理PHP的location ~ \.php$配置块中，fastcgi_param SCRIPT_FILENAME这个参数的值是$document_root$fastcgi_script_name。这里要划个重点：严禁使用$request_filename，否则极易出现脚本找不到的“Primary script unknown”错误。

3. 最后，确认fastcgi_pass指令指向的PHP-FPM监听地址是正确的，无论是Unix Socket（如unix:/var/run/php/php8.1-fpm.sock）还是TCP端口（如127.0.0.1:9000）。

二、PATH_INFO兼容方案（ThinkPHP 5.1及旧模式）

如果你的应用配置了'url_model' => 2（即PATH_INFO模式），或者需要兼容类似/index.php/Index/index这样的旧路由格式，那么就需要显式地提取并传递PATH_INFO变量。否则，框架内的$_SERVER['PATH_INFO']将会是空的，导致路由解析直接失败。

配置方法如下：

1. 在location /配置块中，使用if判断配合rewrite规则：if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s=$1 last; }

2. 更重要的是，在location ~ \.php$这个处理PHP的配置块里，需要添加以下指令来支持PATH_INFO：

fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_param PATH_INFO $fastcgi_path_info;

3. 还有一个容易遗漏的点：必须同时设置fastcgi_param SCRIPT_NAME $fastcgi_script_name;。如果不设置，$_SERVER['SCRIPT_NAME']可能会异常，进而影响到框架内URL的生成功能。

三、子目录部署适配方案（项目不在根目录）

很多时候，我们并不会把ThinkPHP项目直接部署在域名的根路径下，而是放在像/app/这样的子目录里。这时，Nginx就需要聪明一点：它得识别出这个前缀，并在将请求转发给框架前，把前缀剥离掉，只传递剩余的部分。不然，你在代码里定义的路由规则（Route::rule()）永远也无法正确匹配。

配置时需要这么做：

1. 定义一个针对子目录的location块：location /app/ {

2. 在这个块内部，使用try_files指令，并明确指出入口文件的相对路径：try_files $uri $uri/ /app/index.php?$query_string;

3. 修改root指令，让它指向网站的物理根目录（而不是子目录），例如root /var/www/html;。这样才能确保Nginx能正确找到$document_root/app/index.php这个文件。

4. 如果使用rewrite规则，所有重写目标路径都必须以/app/开头，并且正则表达式中的捕获组需要排除掉此前缀。例如：rewrite ^/app/(.*)$ /app/index.php?s=/$1 last;

四、安全增强型配置组合（不可或缺的防护）

除了实现URL重写，生产环境的安全防护绝对不能忽视。我们必须限制对框架敏感目录的直接Web访问，防止.env配置文件、runtime运行时目录、config配置目录等关键信息被泄露。

建议在server配置块中增加以下规则：

1. 添加独立的location规则来屏蔽敏感目录：location ~ ^/(app|config|database|runtime|vendor|extend)/ { deny all; }

2. 添加规则禁止访问所有以点开头的隐藏文件（如.git）：location ~ /\. { deny all; }

3. 这里要特别敲黑板：.env文件必须被deny。这个文件里通常存放着数据库密码、加密密钥等最高机密，一旦暴露，后果不堪设想。

五、调试与验证步骤（配置完别忘了检查）

所有配置修改完毕后，不能想当然认为已经生效，必须进行系统性的验证。Nginx配置变更后，重载和重启是有区别的，同时也要确保PHP-FPM服务在正常运行。

1. 首先，执行nginx -t命令测试配置文件语法。只有看到“syntax is ok”和“test is successful”这两行输出，才能进行下一步。

2. 测试通过后，执行nginx -s reload平滑重载配置。这个命令的好处是不会中断正在处理的连接。

3. 在ThinkPHP项目中创建一个简单的测试路由。例如，在route/app.php文件中添加：Route::get('test-rewrite', function(){ return 'success'; });

4. 打开浏览器，访问https://example.com/test-rewrite。如果页面上显示“success”，并且浏览器地址栏里没有出现index.php，那么恭喜你，URL重写配置成功了！如果返回404，别急，去查看Nginx的error.log日志文件，重点检查是否有类似FastCGI sent in stderr: "Primary script unknown"这样的错误信息，它能帮你快速定位问题所在。