按路径转发怎么用
七层负载均衡可以按 URL 路径把请求分发到不同后端组，例如 /api 转给应用集群、/static 转给静态资源服务器、/admin 转到受控后台。它让一个域名下面挂多套服务成为常态，也是前后端分离与微服务聚合入口的常见做法。但要特别注意匹配细节：前缀匹配与精确匹配的语义不同，相近前缀之间还存在覆盖关系，配置完必须逐条路径验证。
基本信息
| 配置形态 | 路径前缀（如 /api）指向目标服务器组 |
|---|---|
| 典型场景 | 前后端分离、微服务多后端、静态资源独立 |
| 匹配细节 | 区分前缀匹配与精确匹配，注意大小写与优先级 |
| 验证方法 | 对每条路径发请求，核对响应内容与状态码 |
典型使用场景
- 前后端分离：页面与接口走不同后端，统一在同一域名下暴露
- 微服务聚合：按业务前缀把请求分发到不同服务集群
- 静态资源加速：图片与脚本交给专门的静态服务器处理
- 灰度发布：新增路径先指向新版本，验证后切换主路径
逐路径批量验证
逐路径批量验证
for u in / /api/ping /api2/x /static/logo.png; do \
curl -s -o /dev/null -w "$u %{http_code}\n" http://<LB地址>$u; done
# 特别关注相近前缀：/api 与 /api2 是否被同一条规则覆盖匹配方式对比
| 方式 | 行为 | 注意点 |
|---|---|---|
| 前缀匹配 | 路径以指定字符串开头即命中 | 容易误覆盖相近前缀 |
| 精确匹配 | 完全一致才命中 | 尾部斜杠差异会导致漏配 |
| 优先级 | 按产品规则比较 | 规则叠加时以文档为准 |
前缀规则的边界要成对验证：/api 与 /api2 这类相近前缀容易被同一条规则覆盖。
上线前怎么验证
路径转发的验证不能只测主路径能不能通，还要覆盖三类边界：一是相近前缀，确认 /api2 没有被 /api 规则吃掉；二是尾部斜杠差异，/admin 与 /admin/ 可能命中不同规则；三是大小写与查询串，确认路径匹配是否区分大小写。建议把这几类用例写成一份固定的回归清单，每次调整规则后跑一遍，比依赖人工点几下可靠得多，也能避免调整一条规则顺带影响了别的服务。