Nginx反向代理中路径匹配核心逻辑在于location匹配结果与proxy_pass末尾斜杠的协同：前缀匹配（如/api/）可自动剥离前缀，配合proxy_pass http://backend/转发剩余路径；正则匹配需用$1显式构造URI；精确匹配须完整指定目标路径；斜杠决定是否剥离——/剥离，无/则全量追加，前后端路径约定必须一致。
Nginx 中路径匹配在反向代理里的核心逻辑，关键不在“怎么写 location”，而在于 location 匹配结果 和 proxy_pass 末尾斜杠 两者如何协同决定最终发给后端的 URI。这不是字符串拼接，而是有明确剥离与保留规则的路径处理过程。
location 匹配类型决定是否能自动剥离前缀
只有前缀匹配（如 location /api/）或精确匹配（location = /health）才能让 Nginx 明确知道哪些字符属于“匹配部分”。正则匹配（~ 或 ~*）没有固定前缀，Nginx 无法自动推断该砍掉什么，必须靠 $1 等捕获变量显式构造目标 URI。
- 前缀匹配（
/api/）→ 可安全配合proxy_pass http://backend/实现前缀剥离 - 正则匹配（
~ ^/v2/(.*)$）→ 必须写成proxy_pass http://svc/$1，否则配置会报错或转发异常 - 精确匹配（
= /ping）→ 只匹配完整路径，proxy_pass 后必须带目标 URI，如http://health/ping
proxy_pass 末尾斜杠决定路径是否被剥离
这是最容易出错的地方：斜杠不是可有可无的标点，而是触发不同转发逻辑的开关。
-
proxy_pass http://backend/;→ 剥离 location 匹配到的部分，只转发剩余路径 -
proxy_pass http://backend;→ 不剥离，把原始请求 URI 全部追加到 backend 地址后 - 二者行为差异直接导致后端收到的路径完全不同，比如请求
/api/users： - 用
http://backend/→ 后端收到/users - 用
http://backend→ 后端收到/api/users
前后端路径约定必须对齐
配置是否生效，取决于你和后端服务的“默契”——后端期望接收带前缀还是不带前缀的路径。
- 后端路由基于根路径设计（如 Express 的
app.get('/users')）→ 选带斜杠写法，剥离前缀 - 后端已按
/api/xxx结构部署（如 Spring Boot 的@RequestMapping("/api")）→ 可用不带斜杠写法，保留前缀 - 混用时极易出现 404：比如前端调
/admin/list，Nginx 转发成/admin/admin/list，后端根本没这个路由
特殊场景需 rewrite 配合
当 location 和 proxy_pass 的组合无法满足需求时（比如要重写路径、添加参数、统一版本前缀），就得引入 rewrite 指令。
- 例如把所有
/v1/xxx请求转为/v2/xxx再转发：location ~ ^/v1/(.*)$ { rewrite ^/v1/(.*)$ /v2/$1 break; proxy_pass http://svc/; } - 注意
break和last的区别：前者终止当前 location 内 rewrite，后者重新匹配 location - rewrite 在 proxy_pass 之前执行，是路径改造的关键环节
