本文旨在解决Nginx配置中PHP应用程序（尤其是单入口点框架）在处理非文件路径请求时遇到的404错误。核心在于通过Nginx的`try_files`指令，实现将所有非静态文件请求重写至`index.php`，从而允许PHP应用内部进行路由处理。文章将详细阐述正确的Nginx配置方法，包括`root`路径设置和关键的`location /`块，确保Web应用能够正常解析URL。
理解PHP应用程序的路由机制与Nginx的默认行为
现代PHP应用程序，特别是基于框架（如Laravel、Symfony、Yii等）构建的应用，通常采用“单入口点”模式。这意味着所有用户请求，无论其URL路径如何（例如/signin、/signup、/products/123），最终都会通过一个统一的入口文件（通常是index.php）进行处理。应用程序内部的路由系统会根据请求的URL路径来决定加载哪个控制器和执行哪个操作。
然而，Nginx作为Web服务器，其默认行为是尝试将请求的URI映射到文件系统中的实际文件或目录。如果请求的URI，如/signin，在配置的root目录下找不到对应的文件或目录，Nginx就会返回404 Not Found错误。这就是当用户点击网站上的按钮，导致请求/signin或/signup时，尽管应用程序内部有对应的路由，Nginx却因为找不到物理文件而报错的原因。
分析常见Nginx配置问题
为了让Nginx能够正确地将所有非静态文件请求转发给index.php处理，我们需要在Nginx的server块中添加一个通用的location规则。
立即学习“PHP免费学习笔记（深入）”；
考虑一个典型的Nginx配置片段：
server {
listen 80;
listen [::]:80;
listen 443 ssl; # 假设已配置SSL
listen [::]:443 ssl;
root /root/var/www/myforum/public; # 网站的根目录，通常指向框架的public目录
index index.php index.html index.htm;
server_name www.example.com;
# PHP文件处理规则
location ~ \.php$ {
try_files $uri =404; # 这里的try_files对于PHP文件是正确的，但不是针对所有URI
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/run/php/php7.4-fpm.sock; # PHP-FPM的socket路径
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
# 缺少处理非静态文件请求的通用location块
# ...
}上述配置存在的主要问题是缺少一个能够捕获所有非静态文件请求并将其重写到index.php的location块。location ~ \.php$只处理以.php结尾的请求，而像/signin这样的请求则不会被这个块匹配，Nginx会直接在root目录下查找/signin文件，找不到便返回404。
此外，root指令的路径设置也至关重要。它必须精确指向PHP应用程序的公共目录（通常是public目录），而不是应用程序的根目录。错误的root路径，例如重复的/root/路径（/root/var/www/myforum/public如果实际文件路径是/var/www/myforum/public），会导致Nginx无法找到任何文件。
解决方案：实现URL重写与路由
解决Nginx 404错误的关键在于添加一个通用的location /块，并利用try_files指令来实现URL重写。
1. 确保正确的root路径
首先，确认root指令指向的是应用程序的公共目录。例如，如果你的PHP应用程序在/var/www/myforum，且其入口文件index.php位于/var/www/myforum/public，那么Nginx的root指令应该设置为：
root /var/www/myforum/public;
避免在路径中出现冗余或错误的目录层级。
2. 添加通用location /块
这是解决问题的核心。这个location块会捕获所有不被其他更具体location块（例如location ~ \.php$）匹配的请求。
location / {
try_files $uri $uri/ /index.php?$query_string;
}try_files指令详解：
- $uri: Nginx会首先尝试查找与请求URI完全匹配的文件。例如，如果请求/css/style.css，它会尝试在root目录下找到/css/style.css文件。
- $uri/: 如果$uri对应的文件不存在，Nginx会尝试查找与请求URI匹配的目录，并在该目录下寻找index指令中定义的默认文件（如index.html、index.php）。
- /index.php?$query_string: 如果前两者都找不到，Nginx会执行一个内部重写（而不是外部301/302重定向），将请求重写到/index.php，并附带原始的查询字符串$query_string。这意味着，对于像/signin这样的请求，Nginx会将其内部转发给index.php处理，而PHP应用程序的路由系统就能接收到/signin这个路径，并进行相应的处理。
3. 完整的Nginx配置示例
结合上述修正，一个完整的、适用于单入口点PHP应用的Nginx server块配置如下：
server {
listen 80;
listen [::]:80;
# 如果使用HTTPS，请添加并配置SSL证书
# listen 443 ssl;
# listen [::]:443 ssl;
root /var/www/myforum/public; # 确保这里指向你的应用public目录
index index.php index.html index.htm;
server_name www.example.com; # 你的域名
# 捕获所有非静态文件请求并重写到index.php
location / {
try_files $uri $uri/ /index.php?$query_string;
}
# PHP文件处理规则
location ~ \.php$ {
# try_files $uri =404; # 对于PHP文件，通常不需要此行，因为它们会被fastcgi_pass处理
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/run/php/php7.4-fpm.sock; # 确保这里的socket路径正确
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
# 可选：禁止访问某些敏感文件或目录
location ~ /\.ht {
deny all;
}
}注意事项：
- fastcgi_split_path_info 和 SCRIPT_FILENAME： 这两行确保Nginx能够正确地将PHP脚本的文件名和路径信息传递给PHP-FPM，这对于PHP应用程序正确识别脚本和处理PATH_INFO非常重要。
- PHP-FPM Socket路径： fastcgi_pass unix:/run/php/php7.4-fpm.sock; 中的路径必须与你的PHP-FPM版本和配置相符。例如，PHP 8.0可能是php8.0-fpm.sock。
- try_files 顺序： try_files的顺序很重要。它会按顺序尝试每个参数，一旦找到匹配项就停止。将/index.php?$query_string放在最后，确保静态文件优先被服务。
- 重启Nginx： 每次修改Nginx配置文件后，务必执行sudo nginx -t检查语法，然后sudo systemctl reload nginx或sudo systemctl restart nginx来应用更改。
- 检查错误日志： 如果问题依然存在，仔细检查Nginx的错误日志（通常在/var/log/nginx/error.log），它会提供关键的调试信息。
总结
正确配置Nginx以支持PHP应用程序的URL路由是构建现代Web应用的基础。通过确保root指令指向正确的公共目录，并利用location / { try_files $uri $uri/ /index.php?$query_string; }这一核心规则，Nginx能够智能地处理请求，优先服务静态文件，并将所有非静态请求转发给PHP应用程序的入口文件，从而避免404错误并实现应用程序内部的灵活路由。理解这些配置细节对于任何部署PHP应用的开发者来说都至关重要。
