本文深入探讨nginx中非存在php文件404处理不一致的问题。当请求不存在的.php文件时，由于nginx location块的优先级规则，请求会直接进入php处理模块，导致应用层无法捕获404。教程将详细解释其原理，并提供通过在php location块中配置try_files指令来确保所有非存在文件请求都能正确回退到应用入口文件进行处理的解决方案，同时讨论path_info等相关配置的注意事项。
Nginx中PHP文件404处理异常现象
在Nginx + PHP-FPM环境中，开发者可能会遇到一种不一致的404处理行为。例如，当访问一个不存在的路径如 example.com/fakepath 时，请求能够正确地被应用程序的入口文件（如 index.php）捕获，进而由应用程序处理404页面、日志记录等。然而，当访问一个不存在的PHP文件如 example.com/fakepath.php 时，Nginx可能不会将请求转发给应用程序，而是直接返回一个空白页面或显示“File not found”的错误，绕过了应用程序的自定义404逻辑。
典型的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; # 根据实际情况调整PHP-FPM socket路径 } }
在这种配置下，/fakepath 请求会匹配到 location / 块，由于文件不存在，try_files 会将其重写到 /index.php。而 /fakepath.php 请求则会直接触发“File not found”错误。
Nginx Location匹配机制深度解析
要理解上述现象，关键在于Nginx location 指令的匹配优先级。Nginx在处理请求URI时，会遵循一套严格的匹配算法：
立即学习“PHP免费学习笔记（深入）”；
- 精确匹配 (=): 首先检查是否存在与URI完全匹配的 location = /uri。如果找到，立即停止搜索并使用该配置。
- 前缀匹配 (^~): 接着检查带有 ^~ 修饰符的前缀匹配 location ^~ /uri。如果找到最长匹配项，则停止正则匹配，直接使用该配置。
- 普通前缀匹配: 检查不带修饰符的前缀匹配 location /uri。Nginx会记住最长匹配的前缀location，但不会立即使用它。
- *正则表达式匹配 (~ 或 `~`):** 按照它们在配置文件中出现的顺序，检查所有正则表达式location。一旦找到第一个匹配项，Nginx就会使用其配置并停止搜索。
- 回退到最长前缀匹配: 如果没有任何正则表达式匹配成功，Nginx将使用之前记住的最长匹配的前缀location的配置。
在我们的例子中，location ~ .php$ 是一个正则表达式匹配块，而 location / 是一个普通的前缀匹配块。根据优先级规则，正则表达式匹配的优先级高于普通前缀匹配。
因此，当Nginx收到 /fakepath.php 的请求时，它会优先匹配到 location ~ .php$ 这个正则表达式块。一旦匹配成功，Nginx会立即停止搜索并使用该块的配置来处理请求。由于 location ~ .php$ 块中没有 try_files 指令来处理文件不存在的情况，Nginx会直接将 $document_root/fakepath.php 这个不存在的文件路径作为 SCRIPT_FILENAME 参数传递给PHP-FPM。PHP-FPM在尝试执行这个不存在的脚本时，就会返回“File not found”的错误。
解决方案：在PHP Location块中引入try_files
解决这个问题的最直接方法是在处理PHP文件的 location 块中也加入 try_files 指令，以确保即使PHP文件不存在，请求也能回退到应用程序的入口文件。
修改后的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在处理 /fakepath.php 请求时：
- 首先尝试查找 $uri（即 /fakepath.php）。
- 如果 $uri 不存在，则会执行回退逻辑，将请求内部重定向到 /index.php，并携带原始的查询参数。
- 此时，/index.php 作为一个存在的PHP文件，会被正常传递给PHP-FPM处理，从而让应用程序有机会处理这个“不存在的PHP文件”的404情况。
PATH_INFO与fastcgi_split_path_info的考量
在上述解决方案中，需要注意 try_files 指令与 PATH_INFO 参数的潜在交互。根据Nginx的一些内部行为，当 try_files 导致内部重写时，可能会影响 PATH_INFO 的设置。
在当前的配置中，location ~ .php$ 配合 fastcgi_split_path_info ^(.+.php)(/.+)$; 和 fastcgi_param PATH_INFO $fastcgi_path_info; 旨在从URI中提取路径信息。然而，如果你的正则表达式是 .php$（只匹配以 .php 结尾的URI），那么 $fastcgi_path_info 变量通常会是空的，因为 $uri 中没有额外的路径信息。
现代PHP应用程序（如wordPress、laravel等主流框架）大多依赖 REQUEST_URI 或 $_SERVER[‘REQUEST_URI’] 来获取请求路径，而非 PATH_INFO。PATH_INFO 在某些特定的旧版应用程序或如Craft cms这类对URL路由有特殊要求的系统中仍然被使用。
如果你确定你的应用程序不依赖于 PATH_INFO，或者在 .php$ 匹配模式下它实际上并未生效，那么可以安全地移除以下两行：
# 可以移除的行 fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_split_path_info ^(.+.php)(/.+)$;
这样做可以简化配置，并避免潜在的 try_files 对 PATH_INFO 传递的影响。
如果你的应用程序确实需要 PATH_INFO，并且你的URL结构允许像 example.com/index.php/some/path 这样的形式，那么你需要调整 location 的正则表达式为 location ~ .php($|/)，并结合特定的 fastcgi_split_path_info 配置来正确解析 PATH_INFO。在这种情况下，try_files 的使用可能需要更复杂的配置或权衡。但对于大多数现代Web应用，上述解决方案是足够且推荐的。
总结
Nginx中非存在PHP文件404处理不一致的问题，根源在于Nginx location 块的匹配优先级。正则表达式 location ~ .php$ 会优先捕获以 .php 结尾的请求，导致 location / 块中的 try_files 指令失效。通过在PHP处理的 location 块中显式地添加 try_files $uri /index.php$is_args$args;，可以确保所有不存在的PHP文件请求都能被正确地重写到应用程序的入口文件，从而实现统一的404处理逻辑。同时，在配置中审视 PATH_INFO 的必要性，可以进一步优化Nginx配置的简洁性和效率。理解Nginx的匹配机制和 try_files 的行为，是构建健壮Web服务配置的关键。