微服务架构路由重写时 Nginx 重写如何配

Nginx路由重写核心是为微服务精准转发并隐藏后端路径，关键依赖location匹配、proxy_pass斜杠行为（带/则剥离前缀，不带则保留全路径）及可选rewrite介入，三者协同实现解耦与收敛。

微服务架构里，Nginx 做路由重写不是为了“改 URL 给用户看”，而是为了让请求精准落到对应服务上，同时隐藏后端路径细节、统一处理跨域和负载逻辑。关键不在 rewrite 指令本身，而在 proxy_pass 的斜杠行为 + location 匹配 + 可选的 rewrite 介入 这三者的配合。

location + proxy_pass 的路径剥离是基础

这是最常用也最容易出错的一环。proxy_pass 后是否带斜杠，直接决定前端路径要不要被截掉：

1. 结尾带 /：自动剥离匹配到的 location 路径前缀。比如 location /api/user/ { proxy_pass http://user-svc:8081/; }，访问 /api/user/profile 会被转成 /profile 发给后端。
2. 结尾不带 /：保留原始完整路径。比如 location /api/order { proxy_pass http://order-svc:8082;（没斜杠），访问 /api/order/list 就会原样发过去，后端收到的是 /api/order/list。

需要动态路径映射时用 rewrite 配合 proxy_pass

当路径结构不规则、或要提取变量做转发时，rewrite 才真正派上用场。注意它必须在 proxy_pass 之前执行，且重写后需触发内部重定向（加 break 或 last）：

1. 把 /v2/product/123 改成 /product?id=123：

   location ~ ^/v2/product/(d+)$ {
   rewrite ^/v2/product/(d+)$ /product?id=$1 break;
   proxy_pass http://legacy-api:8000;
   }

2. 正则捕获后转发到不同 upstream：

   location ~ ^/api/(user|order)/(.*)$ {
   proxy_pass http://$1-backend/$2;
   }

   （依赖变量插值，要求 Nginx ≥1.3.14）

Ingress-nginx 场景下用注解替代手写 rewrite

在 Kubernetes 中，ingress-nginx 不推荐直接写 rewrite 规则，而是通过标准注解控制：

1. nginx.ingress.kubernetes.io/rewrite-target: /$2 —— 配合正则 path 使用，例如 /v1/(.*) 匹配后，把 $2 当作新路径；
2. nginx.ingress.kubernetes.io/use-regex: "true" 必须开启才能用正则；
3. 避免用 rewrite-target: / 这种全局重写，容易破坏 API 层级结构。

别忘了重写只是手段，目标是解耦与收敛

所有重写配置最终服务于三个目的：

1. 让前端只认一个入口（如 /api/xxx），不用管后端服务名和端口；
2. 把跨域、鉴权、限流等通用逻辑收口到 Nginx，后端专注业务；
3. 升级或迁移服务时，只需改 Nginx 配置，前端和下游服务完全无感。