在 nginx 中，`try_files` 是处理静态资源 fallback 和伪静态路由的首选方案，而 `rewrite` 则用于执行复杂的正则表达式匹配和 url 重写。要实现复杂的路由逻辑，通常的做法是先利用 `rewrite` 进行基于业务规则的 url 转换（如将动态参数转为路径结构），然后再通过 `try_files` 检查文件系统是否存在对应的文件，如果不存在则统一转发给后端应用服务器（如 php-fpm 或 node.js）进行处理。
如何配置 rewrite 实现 URL 规范化与重定向
`rewrite` 指令主要用于修改请求 URI，它支持正则表达式匹配，适合处理那些需要改变 URL 结构但又不想直接返回 404 的场景。例如，当用户访问带有旧版参数的 URL 时，可以使用 `rewrite` 将其重定向到新的标准 URL，从而提升 SEO 友好性并统一入口。这里的关键在于使用 `redirect` 或 `permanent` 标志来确保浏览器地址栏更新，避免循环引用。
server {
listen 80;
server_name example.com;
# 示例：将 /old/page?id=123 重定向为 /new/123
rewrite ^/old/page$ /new/$arg_id redirect;
location / {
root /var/www/html;
index index.html;
}
}
上述配置中，当请求 `/old/page` 时，Nginx 会提取查询参数 `id` 的值，并将其拼接到新路径中。`redirect` 关键字表示返回 302 临时重定向，若希望永久重定向可改为 `permanent`。这种写法简单直接，适用于参数较少且规则固定的场景。需要注意的是，`rewrite` 是在 `location` 块之外或内部按顺序执行的，一旦匹配成功并带有重定向标志，后续的处理流程就会终止。
如何结合 try_files 实现前端路由的 Fallback
`try_files` 的核心作用是按顺序检查文件是否存在，直到找到第一个存在的文件或返回指定的 fallback URI。在现代单页应用（SPA）中，所有路由都指向同一个入口文件 `index.html`，因此需要配置 `try_files` 来优先查找静态资源，若找不到则回退到 `index.html`，由前端路由器接管后续的路由解析。这种机制避免了因刷新页面或手动输入深层链接而导致 404 错误的问题。
server {
listen 80;
server_name example.com;
location / {
root /var/www/html;
index index.html;
# 先尝试找具体文件，再找目录，最后回退到 index.html
try_files $uri $uri/ /index.html;
}
# 假设后端 API 位于 /api/
location /api/ {
proxy_pass http://backend:3000;
}
}
在这个配置中，`$uri` 代表当前请求的 URI，`$uri/` 代表以 URI 为路径的目录。如果请求 `/about`，Nginx 会先检查 `/var/www/html/about` 是否存在，再检查 `/var/www/html/about/` 是否存在，如果都不存在，则将内部请求转发给 `/index.html`。这样，前端 JavaScript 就能接收到 `/about` 这个路径并进行路由匹配。同时，`/api/` 路径被单独处理，确保 API 请求不会被 `try_files` 干扰，而是直接代理到后端服务。
当 try_files 找不到文件且未指定 fallback 时会发生什么
如果在 `try_files` 指令中省略了最后一个 fallback 参数，或者指定的 fallback 路径在文件系统中也不存在，Nginx 会根据上下文返回相应的 HTTP 状态码。通常情况下，如果所有列出的文件都不存在且没有 fallback，Nginx 会返回 404 Not Found 错误。这种行为对于调试非常有用，因为它明确指示了资源缺失，但在生产环境中，通常需要显式指定 fallback 以确保用户体验的一致性。
server {
listen 80;
server_name example.com;
location /test {
root /var/www/html;
# 仅检查文件，无 fallback
try_files $uri;
}
}
在上述代码中，如果请求 `/test/nonexistent`，Nginx 会尝试查找 `/var/www/html/test/nonexistent`，如果该文件不存在，由于没有提供 fallback，Nginx 将直接返回 404 状态码。这与之前配置中返回 `index.html` 的行为形成鲜明对比。开发者可以通过这种方式验证文件路径是否正确，或者在特定场景下故意不设置 fallback 以强制暴露缺失的资源。此外，如果 fallback 指向一个不存在的内部 URI，Nginx 也会返回 404，除非该 URI 被其他 `location` 块捕获并处理。
