Nginx try_files 在PHP文件不存在时回退机制的配置与原理

本文旨在解决nginx在处理不存在的php文件时，因`location`匹配优先级导致`try_files`回退机制失效的问题。文章将深入解析nginx的`location`匹配机制，阐明为何特定请求绕过了通用`try_files`配置。接着，提供在php处理块中正确配置`try_files`的解决方案，确保所有不存在的php文件请求能按预期回退至`index.php`。同时，探讨`path_info`参数的兼容性及其在现代web应用中的最佳实践。

Nginx location 匹配机制解析

Nginx的location指令用于根据URI匹配请求，并应用相应的配置。理解其匹配优先级是解决许多配置问题的关键。Nginx的location匹配遵循以下精确的顺序：

1. 精确匹配 (=): Nginx首先查找使用=修饰符定义的精确匹配。如果URI与location = /uri完全一致，则立即停止搜索并使用该配置。
2. 前缀匹配 (^~): 接下来，Nginx查找使用^~修饰符定义的前缀匹配。如果找到最长匹配的前缀location带有^~，则停止正则表达式匹配，直接使用此location。
3. 最长前缀匹配 (无修饰符): Nginx会遍历所有不带修饰符的前缀location，并选择与URI匹配最长的那个。这个最长匹配的location会被“记住”，但不会立即使用。
4. *正则表达式匹配 (~ 或 `~)**: Nginx按其在配置文件中出现的顺序检查所有正则表达式location`。一旦找到第一个匹配项，就会停止搜索并使用其配置。
5. 回退到最长前缀匹配: 如果所有正则表达式location都没有匹配成功，Nginx将使用之前“记住”的最长前缀匹配location的配置。

在上述场景中，当请求example.com/fakepath时，它会匹配location /这个前缀location，并由其中的try_files指令处理，最终回退到index.php。然而，当请求example.com/fakepath.php时，Nginx会首先进行前缀匹配（最长匹配仍是location /），然后检查正则表达式匹配。此时，location ~ \.php$会精确匹配/fakepath.php，由于正则表达式location的优先级高于普通前缀location，Nginx会直接进入location ~ \.php$块进行处理。

问题根源：PHP处理块中缺少 try_files

给定的Nginx配置如下：

server {
    listen 80;
    server_name example.com;
    root /var/www/html; # 假设您的网站根目录

    location / {
        index index.php index.html;
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ \.php$ {
        fastcgi_index                   index.php;
        fastcgi_param SCRIPT_FILENAME   $document_root/$fastcgi_script_name;
        fastcgi_param QUERY_STRING      $query_string;
        fastcgi_param PATH_INFO         $fastcgi_path_info;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;

        include fastcgi_params;
        fastcgi_pass unix:/run/php/php7.4-fpm.sock;
    }
}

当请求example.com/fakepath.php时，Nginx的匹配机制使其直接进入location ~ \.php$块。此块的职责是将请求传递给PHP-FPM处理。然而，此location块中没有try_files指令来检查文件是否存在。因此，Nginx会直接将SCRIPT_FILENAME参数（即/var/www/html/fakepath.php）传递给PHP-FPM。由于/var/www/html/fakepath.php文件实际不存在，PHP-FPM会返回一个“File not found.”的错误，而不是将请求回退到index.php。

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

解决方案：在PHP处理块中集成 try_files

要解决此问题，最直接的方法是在location ~ \.php$块中也添加try_files指令。这样，在将请求传递给PHP-FPM之前，Nginx会先尝试查找文件。

修改后的Nginx配置如下：

server {
    listen 80;
    server_name example.com;
    root /var/www/html; # 假设您的网站根目录

    location / {
        index index.php index.html;
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ \.php$ {
        # 在此处添加 try_files 指令
        try_files $uri /index.php$is_args$args;

        fastcgi_index                   index.php;
        fastcgi_param SCRIPT_FILENAME   $document_root/$fastcgi_script_name;
        fastcgi_param QUERY_STRING      $query_string;
        # fastcgi_param PATH_INFO         $fastcgi_path_info; # 见下文说明
        # fastcgi_split_path_info ^(.+\.php)(/.+)$; # 见下文说明

        include fastcgi_params;
        fastcgi_pass unix:/run/php/php7.4-fpm.sock;
    }
}

通过在location ~ \.php$块中添加try_files $uri /index.php$is_args$args;，Nginx在处理.php文件请求时，会首先检查$uri（即请求的文件路径）是否存在。

• 如果文件存在（例如/index.php），Nginx会继续处理，将请求传递给PHP-FPM。
• 如果文件不存在（例如/fakepath.php），Nginx会执行try_files的下一个参数，即内部重定向到/index.php，并将原始请求的查询字符串和参数一并传递。此时，location /中的try_files将不再被触发，因为请求已经被location ~ \.php$处理并重定向。

PATH_INFO 参数的考量与最佳实践

在上述修改后，需要注意try_files与PATH_INFO参数的交互。Nginx的try_files指令在执行内部重定向时，可能会影响PATH_INFO的设置。

DeepBrain

AI视频生成工具，ChatGPT +生成式视频AI =你可以制作伟大的视频!

94

查看详情

在您的原始配置中，fastcgi_split_path_info ^(.+\.php)(/.+)$;和fastcgi_param PATH_INFO $fastcgi_path_info;旨在解析URI中PHP脚本名称后的额外路径信息。例如，对于example.com/index.php/some/path，SCRIPT_FILENAME可能是/index.php，而PATH_INFO是/some/path。

然而，在您当前的location ~ \.php$正则表达式中，\.php$只匹配以.php结尾的URI，不包含后续的路径信息。这意味着，对于example.com/fakepath.php或example.com/index.php，fastcgi_split_path_info中的第二个捕获组(/.+)将永远不会被匹配，导致$fastcgi_path_info始终为空。因此，在您当前的配置下，即使保留这些行，PATH_INFO参数也不会被有效利用。

现代Web应用的实践：

• REQUEST_URI 优先: 大多数现代PHP框架（如WordPress、Laravel、Symfony等）更倾向于使用$_SERVER['REQUEST_URI']来获取完整的请求URI，并自行解析路由，而不是依赖PATH_INFO。

• 简化配置: 如果您的应用不依赖于PATH_INFO（在大多数情况下确实如此，特别是当location正则表达式只匹配.php文件本身时），您可以安全地移除以下两行，以简化配置并避免潜在的混淆：

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

  登录后复制

  精简后的PHP处理块将更清晰：

  location ~ \.php$ {
      try_files $uri /index.php$is_args$args;
      fastcgi_index                   index.php;
      fastcgi_param SCRIPT_FILENAME   $document_root/$fastcgi_script_name;
      fastcgi_param QUERY_STRING      $query_string;
      include fastcgi_params;
      fastcgi_pass unix:/run/php/php7.4-fpm.sock;
  }

  登录后复制

• 需要 PATH_INFO 的特殊情况: 只有在少数特定场景或CMS（如Craft CMS）中，PATH_INFO才可能被明确需要。如果您的应用确实需要处理example.com/index.php/some/path这种形式的URI，并且需要PATH_INFO，您可能需要调整location正则表达式为\.php($|/)，并结合Nginx官方文档或相关社区提供的PATH_INFO处理方案来确保其正确性。但对于大多数标准PHP应用，上述简化方案是更优的选择。

总结

解决Nginx中不存在的PHP文件无法正确回退到index.php的问题，核心在于理解Nginx的location匹配优先级，并确保在处理PHP请求的location块中也配置了try_files指令。通过在location ~ \.php$块中添加try_files $uri /index.php$is_args$args;，可以有效解决此问题。同时，建议根据您的PHP应用实际需求，审视PATH_INFO参数的使用，并在不必要时进行精简，以保持Nginx配置的简洁性和高效性。

以上就是Nginx try_files 在PHP文件不存在时回退机制的配置与原理的详细内容，更多请关注php中文网其它相关文章！