本文旨在解决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匹配遵循以下精确的顺序：
- 精确匹配 (=): Nginx首先查找使用=修饰符定义的精确匹配。如果URI与location = /uri完全一致，则立即停止搜索并使用该配置。
- 前缀匹配 (^~): 接下来，Nginx查找使用^~修饰符定义的前缀匹配。如果找到最长匹配的前缀location带有^~，则停止正则表达式匹配，直接使用此location。
- 最长前缀匹配 (无修饰符): Nginx会遍历所有不带修饰符的前缀location，并选择与URI匹配最长的那个。这个最长匹配的location会被“记住”，但不会立即使用。
- *正则表达式匹配 (~ 或 `~)**: Nginx按其在配置文件中出现的顺序检查所有正则表达式location`。一旦找到第一个匹配项，就会停止搜索并使用其配置。
- 回退到最长前缀匹配: 如果所有正则表达式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的设置。
在您的原始配置中，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配置的简洁性和高效性。
