Nginx URI重写与内部路由概述
在web开发中，为了实现更友好的url结构（clean url）和内部路由机制，我们经常需要对用户请求的uri进行处理。例如，将形如 example.com/shop/product/123 的请求，内部重写为 example.com/shop/main.php?route=/product/123，由 main.php 文件负责解析 route 参数并处理业务逻辑。nginx作为高性能的web服务器，提供了强大的uri重写能力，但其实现方式与apache的 .htaccess 有所不同，需要理解其核心指令的工作原理。
直接使用 $uri 变量进行重写往往无法满足剥离特定路径前缀的需求，因为 $uri 包含了完整的请求路径。同时，try_files 指令虽然强大，但它主要用于文件或目录的查找，并不能直接通过正则表达式捕获 $1 这样的变量。要实现精确的路径剥离和参数传递，我们需要巧妙地结合 try_files 和 rewrite 指令。
核心配置解析
实现上述目标的Nginx配置主要依赖于两个 location 块和一个 rewrite 指令。
location /shop/ {
try_files $uri $uri/ @rewrite;
}
location @rewrite {
rewrite ^/shop(/.*) /shop/main.php?route=$1 last;
}下面我们逐一解析这些配置项：
1. location /shop/ 块
这个 location 块匹配所有以 /shop/ 开头的请求。
-
try_files $uri $uri/ @rewrite;:
- $uri: Nginx会首先尝试查找与请求URI完全匹配的文件。例如，如果请求是 /shop/main.php，它会尝试查找物理文件 /path/to/webroot/shop/main.php。
- $uri/: 如果第一个尝试失败，Nginx会尝试查找与请求URI对应的目录。例如，如果请求是 /shop/product，它会尝试查找物理目录 /path/to/webroot/shop/product/。如果找到目录，NNginx会尝试在其内部查找 index 文件（如 index.html 或 index.php，这取决于其他配置）。
- @rewrite: 如果上述两种尝试都失败（即没有找到对应的文件或目录），Nginx会将请求内部重定向到名为 @rewrite 的命名 location 块进行处理。这是实现自定义路由的关键入口。
2. location @rewrite 块
这是一个命名 location 块，它不会直接响应外部请求，只用于内部重定向。
- *`rewrite ^/shop(/.) /shop/main.php?route=$1 last;`**: 这是实现URI重写的核心指令。
- rewrite: Nginx的重写指令。
- ^/shop(/.*): 这是一个正则表达式，用于匹配和捕获请求URI的特定部分。
- ^: 匹配URI的开头。
- /shop: 精确匹配字符串 /shop。
- (/.*): 这是一个捕获组。它匹配 / 后面的任意字符（.）零次或多次（*）。这个捕获组的内容将被存储在 $1 变量中。例如，如果原始URI是 /shop/product/123，那么 $1 的值将是 /product/123。
- /shop/main.php?route=$1: 这是重写后的目标URI。
- /shop/main.php: 指定了处理请求的PHP文件。
- ?route=$1: 将捕获到的路径（即 $1 的内容）作为 route 参数传递给 main.php。
- last: 这是一个标志。它告诉Nginx停止处理当前 location 块中的其他 rewrite 指令，并重新开始搜索 location 匹配，使用重写后的URI作为新的请求URI。这意味着Nginx会再次查找 /shop/main.php 对应的 location 块（通常会匹配到处理PHP文件的 location ~ \.php$ 块），并将其传递给 php-fpm 处理。
完整示例配置
为了使上述配置生效，通常还需要一个用于处理 .php 文件的 location 块，并与 php-fpm 进行通信。
server {
listen 80;
server_name example.com;
root /path/to/webroot; # 你的网站根目录，例如 /var/www/html
index index.html index.htm index.php;
# 处理 /shop/ 路径下的请求
location /shop/ {
# 尝试查找物理文件或目录，如果找不到，则交给 @rewrite 处理
try_files $uri $uri/ @rewrite;
}
# 命名 location，用于URI重写
location @rewrite {
# 使用正则表达式剥离 /shop/ 前缀，并将剩余部分作为 route 参数传递
# 例如：/shop/product/123 -> /shop/main.php?route=/product/123
rewrite ^/shop(/.*) /shop/main.php?route=$1 last;
}
# 处理所有 .php 文件的请求
location ~ \.php$ {
# 确保文件存在，防止恶意请求
try_files $uri =404;
# FastCGI 配置
fastcgi_pass unix:/var/run/php/php8.1-fpm.sock; # 根据你的php-fpm版本和配置修改
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
# 其他静态文件处理或错误页配置
location ~ /\.(ht|svn|git) {
deny all;
}
error_page 404 /404.html;
location = /404.html {
internal;
}
}注意事项
- $1 变量的来源：在Nginx中，$1、$2 等变量仅在 rewrite 指令的正则表达式捕获组中产生。它们不能直接用于 try_files 指令，因为 try_files 不进行正则表达式匹配。
- try_files 与 rewrite 的协作：try_files 负责检查物理文件和目录的存在性，提供静态资源访问的优化。当静态资源不存在时，它将请求“委托”给 rewrite 指令进行动态路由处理，这种分工是高效且清晰的。
- last 标志的重要性：last 标志是 rewrite 指令的关键。它指示Nginx在重写后重新启动 location 匹配过程，确保重写后的URI（例如 /shop/main.php）能够被正确的 location 块（例如 location ~ \.php$）处理。如果没有 last，Nginx可能会继续在当前 location 块中处理，导致意想不到的结果。
- 避免嵌套 try_files：在Nginx中，不推荐在 try_files 的回退参数中再次使用 try_files 或其他复杂的指令。这会增加不必要的开销并可能导致配置混乱。
- PHP-FPM 配置：确保 fastcgi_pass 指向正确的 php-fpm 套接字或地址，并且 SCRIPT_FILENAME 参数正确地构建了PHP脚本的物理路径。
总结
通过上述Nginx配置，我们成功地实现了URI的灵活重写和路径参数的剥离。这种方法不仅能够创建更美观、更易于SEO的URL，还能将复杂的路由逻辑集中到后端应用处理，极大地提升了Web应用的灵活性和可维护性。理解 try_files 和 rewrite 指令的协同工作原理，是掌握Nginx高级配置的关键。
