本文深入探讨nginx处理php文件404时`try_files`失效的常见问题。核心原因在于nginx `location`块的匹配优先级：正则表达式匹配的php处理块优先于通用路径匹配块。文章详细解析了nginx的匹配机制，揭示了php-fpm直接返回“file not found”错误的原因，并提供了在php处理块中添加`try_files`指令的优化方案，同时讨论了`path_info`参数的考量与现代web应用的最佳实践，确保所有未找到的php请求都能正确回退到`index.php`。
Nginx Location匹配机制深度解析
在配置Nginx服务器时，理解其location指令的匹配优先级至关重要。Nginx根据URI请求匹配不同的location块，其匹配算法并非简单地按照配置文件中的顺序执行。Nginx主要有两种类型的location匹配：
- 前缀匹配 (Prefix Locations)：使用location /path/to/形式定义，Nginx会选择与请求URI匹配最长的前缀。
- 正则表达式匹配 (Regular Expression Locations)：使用location ~ \.php$或location ~* \.jpg$形式定义，分别表示区分大小写和不区分大小写的正则表达式匹配。
Nginx的匹配流程如下：
- 第一阶段：前缀匹配。Nginx首先检查所有前缀匹配的location块，并选择匹配最长的那个。这个最长的匹配会被“记住”。
- 第二阶段：正则表达式匹配。Nginx随后按照它们在配置文件中出现的顺序检查所有正则表达式匹配的location块。一旦找到第一个匹配的正则表达式，Nginx就会立即使用对应的配置，并终止匹配过程。
- 最终阶段：回退。如果在第二阶段没有找到任何正则表达式匹配，Nginx将使用第一阶段“记住”的最长前缀匹配的location块。
问题根源
在典型的Nginx + PHP-FPM配置中，我们通常会有一个处理所有请求的通用location /块，以及一个专门处理.php文件的location ~ \.php$块。由于正则表达式匹配的优先级高于前缀匹配，当请求如/fakepath.php到达时，它会直接被location ~ \.php$块捕获，而不会经过location /块中定义的try_files $uri $uri/ /index.php$is_args$args;指令。
立即学习“PHP免费学习笔记（深入）”；
PHP-FPM 404错误溯源
当一个不存在的PHP文件（例如/fakepath.php）请求直接进入location ~ \.php$块时，该块的配置通常会将SCRIPT_FILENAME参数传递给PHP-FPM，其值是Nginx服务器上该文件的完整路径（如/var/www/html/fakepath.php）。
由于服务器上实际不存在/var/www/html/fakepath.php这个文件，PHP-FPM在尝试执行它时会发现文件缺失，并直接返回一个“File not found.”的错误响应。这个错误发生在Nginx将请求转发给PHP-FPM之后，且在Web应用程序的逻辑层处理之前，因此应用程序内部的404处理机制无法介入。
优化Nginx PHP-FPM配置
为了确保所有对不存在PHP文件的请求都能正确回退到index.php，我们需要在处理PHP文件的location块中也加入try_files指令。
核心解决方案
在location ~ \.php$块内添加try_files指令，使其在找不到实际的PHP文件时，能够将请求内部重写到index.php。
server {
listen 80;
server_name example.com;
root /var/www/html; # 您的项目根目录
index index.php index.html;
location / {
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; # 参见下面的PATH_INFO考量
# fastcgi_split_path_info ^(.+\.php)(/.+)$; # 参见下面的PATH_INFO考量
include fastcgi_params;
fastcgi_pass unix:/run/php/php7.4-fpm.sock; # 您的PHP-FPM套接字路径
}
}通过此更改，当Nginx接收到/fakepath.php请求时：
- 它会匹配location ~ \.php$。
- try_files $uri /index.php$is_args$args;会首先尝试查找/fakepath.php。
- 如果/fakepath.php不存在，它将内部重定向到/index.php，并保留原始的查询参数。
- /index.php请求随后被PHP-FPM处理，应用程序可以根据需要处理404逻辑。
PATH_INFO考量与最佳实践
在上述解决方案中，我们可能需要重新审视fastcgi_split_path_info和fastcgi_param PATH_INFO这两个参数。
- try_files对PATH_INFO的影响：当try_files指令在PHP处理块中触发内部重写时，它可能会干扰PATH_INFO的设置。如果您的应用程序（如某些CMS或旧版框架）严重依赖于PATH_INFO（例如，处理/index.php/some/path这样的请求），则可能需要更复杂的配置或特定的Nginx版本补丁来确保PATH_INFO的正确性。
- 现代Web应用趋势：当前大多数流行的PHP框架（如WordPress、Laravel、Symfony等）已经不再主要依赖PATH_INFO来路由请求，而是更多地使用REQUEST_URI或QUERY_STRING参数。
- 当前配置的PATH_INFO无效性：在提供的原始配置中，location ~ \.php$的正则表达式\.php$意味着它只匹配以.php结尾的URI，不包含任何额外的路径信息。因此，fastcgi_split_path_info ^(.+\.php)(/.+)$;中的(/.*)部分永远不会被匹配，$fastcgi_path_info也始终为空。
鉴于以上分析，如果您的应用程序不明确要求PATH_INFO，或者您已经在使用\.php$作为正则表达式，那么您可以安全地移除fastcgi_split_path_info和fastcgi_param PATH_INFO这两行，以简化配置。
精简后的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
如果您的应用程序确实需要PATH_INFO（例如，Craft CMS），并且希望支持/index.php/some/path这样的URL结构，您需要调整location正则表达式为\.php($|/)，并可能需要采取额外的措施来确保try_files和PATH_INFO的兼容性。这通常涉及更复杂的rewrite规则或特定的Nginx配置技巧，超出了本文的初衷。在大多数情况下，上述精简方案已足够。
总结
正确处理Nginx中的404错误对于提供良好的用户体验和应用程序稳定性至关重要。本文通过深入分析Nginx location块的匹配优先级，揭示了try_files在处理不存在的PHP文件时失效的根本原因。核心解决方案是在location ~ \.php$块中明确添加try_files $uri /index.php$is_args$args;指令，以确保所有此类请求都能回退到您的应用程序入口点。同时，理解PATH_INFO的用途及其与try_files的交互，可以帮助您构建更健壮、更符合现代Web开发实践的Nginx配置。始终记住，在修改Nginx配置后，务必使用nginx -t检查语法，并使用sudo systemctl reload nginx或sudo service nginx reload重新加载配置。
