本文详解如何在 nginx 中安全、可靠地重定向旧子路径（如 `/dataview/xxx`）到新路径（如 `/backend/xxx`），重点剖析 `rewrite` 指令中 `last` 与 `permanent` 的本质区别，避免因内部重写导致的 404 错误。
在实际 Web 应用迭代过程中，URL 路径结构调整十分常见。例如将旧路径 /dataview/unknownvvvo 迁移至 /backend/unknown-vvvo，或把 /dataview/servicecounter 更新为 /backend/servicecounter-events。此时，借助 Nginx 的 rewrite 模块实现平滑过渡是高效且低侵入的做法——但若配置不当，极易引发看似成功实则返回 404 的“静默失败”。
问题根源在于 rewrite ... last 的内部重写机制：它仅在 Nginx 请求处理流程中修改 URI，不改变客户端可见地址，也不重置后续 location 匹配上下文。以你的配置为例：
rewrite ^/dataview/unknownvvvo(.*)$ /backend/unknown-vvvo$1 last;
# → URI 内部变为 /backend/unknown-vvvo，但请求仍落入 location / {}随后 try_files $uri /index.php$is_args$args 尝试查找物理路径 /app/app/public/backend/unknown-vvvo（不存在），最终回退至 /index.php。而 PHP-FPM 接收到的 REQUEST_URI 仍是原始值 /dataview/unknownvvvo（由 fastcgi_params 默认传递），后端应用无法识别新路由，最终 404。
✅ 正确解法：使用 外部重定向（301），强制浏览器跳转并刷新请求上下文：
server {
listen 80;
listen [::]:80;
root /app/app/public;
index index.php index.html;
# ✅ 使用 permanent 实现客户端重定向
rewrite ^/dataview/unknownvvvo(.*)$ /backend/unknown-vvvo$1 permanent;
rewrite ^/dataview/servicecounter(.*)$ /backend/servicecounter-events$1 permanent;
location / {
try_files $uri /index.php$is_args$args;
}
location ~ \.php$ {
fastcgi_pass php-fpm_cms:9000;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
# ⚠️ 关键补充：确保后端收到的是重写后的 URI
fastcgi_param REQUEST_URI $request_uri; # 可选，但推荐显式控制
}
}? 补充说明：permanent 等价于 redirect（301），会向客户端返回 Location: /backend/... 响应头；浏览器重新发起请求，Nginx 重新匹配 location /backend/...（需确保该路径有对应处理逻辑），同时 REQUEST_URI 自动更新为新路径，后端可准确路由。
? 注意事项：
- 若需内部代理转发（不暴露新路径给用户），应改用 proxy_pass + location 块，而非 rewrite；
- 避免在 server 块顶层滥用 rewrite，优先考虑 location 内限定作用域；
- 生产环境建议使用 rewrite ... redirect（302）先行测试，验证无误后再切为 permanent（301）；
- 启用 rewrite_log on; 仅用于调试（需编译时启用 --with-debug），上线前关闭以避免性能损耗。
总结：Nginx 的 rewrite 不是万能路由层——last 适用于同一服务内路径标准化，而跨语义路径迁移必须依赖 permanent 或 redirect 触发完整请求生命周期。理解这一差异，是写出健壮反向代理配置的关键前提。
