本文深入探讨 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 服务配置的关键。
