如何解决后端微服务Context-Path变更后的proxy

nginx proxy_pass斜杠语义决定uri裁剪或追加，context-path变更需同步调整proxy_pass、proxy_redirect和host/x-real-ip头配置，否则导致404或跳转错误。

如何解决后端微服务context-path变更后的proxy_pass重构

后端微服务的 context-path 变更后，Nginx 的 proxy_pass 配置必须同步重构，否则前端请求会 404 或被错误转发。核心不是“重写路径”，而是让 Nginx 在转发时精准控制 URI 的裁剪与拼接逻辑。

这是最关键的一步，直接决定后端能否收到正确路径：

proxy_pass http://backend;（末尾无斜杠）→ Nginx 将完整匹配的 URI 追加到目标地址后。例如 location /api/ { proxy_pass http://127.0.0.1:8080; }，请求 /api/user 会被发往 http://127.0.0.1:8080/api/user
proxy_pass http://backend/;（末尾有斜杠）→ Nginx 将 location 匹配前缀裁掉，只转发剩余部分。同上例，请求 /api/user 会被发往 http://127.0.0.1:8080/user
若后端 context-path 设为 /cnAdminRy，且前端 API 基准路径是 /prod-api，则应让 Nginx 把 /prod-api 替换为 /cnAdminRy，此时不能仅靠斜杠裁剪，需配合 rewrite

根据后端实际配置的 context-path 值，选用对应方案：

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

后端 context-path = /cnAdminRy（非根、带前缀）：前端仍用 /prod-api 发请求 → Nginx 需将 /prod-api 重写为 /cnAdminRy 再代理
示例：
```
location /prod-api/ {   rewrite ^/prod-api/(.*)$ /cnAdminRy/$1 break;   proxy_pass http://127.0.0.1:8080/; }
```
后端 context-path = /（默认根路径）：但前端仍保留 /prod-api → 直接裁剪前缀即可
```
location /prod-api/ {   proxy_pass http://127.0.0.1:8080/; }
```
后端 context-path = /v1（版本化路径）：前端已适配为 /v1/user → 无需重写，只需确保 proxy_pass 目标地址能响应该路径
```
location /v1/ {   proxy_pass http://127.0.0.1:8080/; }
```

仅改 proxy_pass 不够，以下三处不一致就会导致跳转失败、Cookie 丢失或 HTTPS 暴露内网地址：

proxy_set_header Host $host;：确保后端收到的 Host 头是客户端真实域名，而非 127.0.0.1
proxy_redirect off; 或显式重写重定向响应：
若后端返回 302 跳转（如登录成功跳转），默认会把 Location: /cnAdminRy/dashboard 原样返回给浏览器，造成路径错乱。
应配置：proxy_redirect /cnAdminRy/ /prod-api/;（将后端返回的 context-path 替换回前端期望路径）
proxy_set_header X-Real-IP $remote_addr; 和 X-Forwarded-For：保障后端日志和鉴权能获取真实客户端 IP

配置完成后，逐项确认：

用 curl -v http://your-domain.com/prod-api/login 查看 Nginx access log，确认转发目标地址和路径是否符合预期
检查后端应用日志，确认收到的请求路径是 /cnAdminRy/login（而非 /prod-api/login 或 /login）
在浏览器开发者工具 Network 面板中，查看接口响应头中的 Location 是否已被 proxy_redirect 正确修正，避免跳转到错误路径