proxy_pass末尾斜杠决定路径处理方式：带斜杠则替换路径（如location /api/ → 后端收/users），不带则追加路径（如收/api/users）；正则匹配时必须显式指定URI；rewrite可配合实现灵活路径改写。

proxy_pass 末尾加不加斜杠，直接决定后端收到的路径是不是你想要的。搞错一个字符，就可能让所有接口返回 404。

proxy_pass 带斜杠：路径替换，去掉 location 前缀

这是最常用也最安全的方式，适合前后端分离、后端服务监听根路径的场景。

• location 中匹配到的路径部分（比如 /api/）会被完全移除
• proxy_pass 后的路径（比如 /）会作为新起点，拼接剩余 URI
• 请求 /api/users → 后端收到 /users
• 请求 /api/v2/profile → 后端收到 /v2/profile

配置示例：

location /api/ {
  proxy_pass http://backend/;
}

proxy_pass 不带斜杠：路径追加，原样转发完整路径

这种写法容易出问题，除非后端明确要求保留前缀，否则不建议使用。

WebChat Voice Proxy

⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**

下载

• Nginx 不做任何截断，把客户端原始请求路径整个拼到 proxy_pass 地址后面
• 请求 /api/users → 后端收到 /api/users
• 如果后端没部署在 /api 这个上下文下，就会 404

配置示例：

location /api/ {
  proxy_pass http://backend;
}

正则或精确匹配时，proxy_pass 必须带 URI

当 location 使用 =、~ 或 ~* 时，Nginx 无法自动推导要截掉多少路径，必须显式写出目标路径。

• 错误写法：location ~ ^/static/ { proxy_pass http://cdn; }（Nginx 启动失败）
• 正确写法：location ~ ^/static/(.+)$ { proxy_pass http://cdn/$1; }
• 精确健康检查：location = /health { proxy_pass http://backend/health; }

用 rewrite 配合 proxy_pass 实现灵活路径改写

默认映射逻辑不够用时，rewrite 可以先重写 URI，再交给 proxy_pass 转发。

• 把 /v2/api/users 改成 /api/v2/users：
• location /v2/api/ {
    rewrite ^/v2/api/(.*)$ /api/v2/$1 break;
    proxy_pass http://backend/;
  }
• 注意 break 标志，避免重复 rewrite