分发规则匹配逻辑详解
本指南用于排查“规则已经创建，但请求去了另一个服务器池”或“默认规则一直生效”等问题。配置时需要同时考虑匹配条件、优先级、同级顺序和命中后的动作。
基础概念：策略与规则
| 对象 | 解决的问题 | 示例 |
|---|---|---|
| 分发策略 | 匹配什么请求 | URL 前缀为 /api/、请求方法为 GET |
| 分发规则 | 满足条件后做什么 | HTTP 代理到指定服务器池、返回静态资源、重定向 |
| 虚拟服务中的规则关联 | 哪些规则参与本业务，以及优先级和顺序 | 高、中、低三个级别 |
| 默认分发规则 | 其他规则均未命中时如何处理 | 转发到默认服务器池 |
创建规则后，还必须将其关联到目标虚拟服务。只创建分发策略或分发规则，不会改变业务流量。
组合条件如何填写
以“GET 请求且 URL 以 /aaa 开头，并带指定查询参数”为例，分别创建 URL 前缀、请求方法、URL 参数策略，再在同一规则中选择这些策略。
图中使用自定义响应内容便于区分命中的规则；实际业务可改为代理到不同服务器池。使用正则路径时，优先将正则规则单独配置，并为可能重叠的规则设置清晰的优先级，不要直接套用其他路径类型的组合示例。
匹配优先级总览
先按“高 → 中 → 低”查找，某一级存在有效命中后，不再继续查找低一级；三个级别都未命中时，才使用默认分发规则。
在同一级内，不能简单概括为“正则 > 完全匹配 > 前缀”，也不能认为任何路径类型都只按页面从上到下决定。
| 同级竞争情形 | 配置时需要知道的行为 |
|---|---|
| 完全匹配与前缀匹配 | 先尝试满足条件的完全匹配，再查找前缀路径 |
| 多个不同前缀 | 从更具体的路径查找；短前缀不是因为排在前面就必然覆盖长前缀 |
| 相同路径下的多条规则 | 同级顺序影响选择，应把具体条件放在宽泛条件前面 |
| 正则与完全匹配或前缀规则重叠 | 还要比较同级顺序；正则不是无条件覆盖其他路径类型 |
| 多条正则同时匹配 | 同级顺序影响选择，应避免没有明确先后关系的重叠表达式 |
对于业务上明确要求“例外规则一定优先”的情况，使用高一级优先级表达，不要依赖对路径类型的猜测。
进入虚拟服务编辑页，在“分发规则”区域选择规则和优先级；需要调整同级顺序时，拖动规则左侧手柄。保存后执行变更，再用具体请求验证。
一组可复用的配置示例
下面的组合来自已验证的多规则场景。资源名称可自行确定；同一级内按表中自上而下的顺序关联。
| 优先级 | 规则简称 | 匹配条件 | 命中后返回的识别内容 |
|---|---|---|---|
| 高 | PATCH 规则 | 方法 PATCH | hijack all patch |
| 高 | 管理删除规则 | 前缀 /admin + 方法 DELETE | block /admin DELETE |
| 高 | 管理提交规则 | 前缀 /admin + 方法 POST | hijack all admin POST |
| 高 | 字母正则规则 | 正则 /[a-z]{6} | regex/[a-z]{6} |
| 中 | 精确 GET 规则 | 完全匹配 /aaa + 方法 GET | /aaa && get request |
| 中 | 参数规则 | 前缀 /aaa + GET + 参数 username=a、age=c | /aaa && GET && url k-v match |
| 中 | 前缀通用规则 | 前缀 /aaa + 允许的全部请求方法 | /aaa && ALL request |
| 低 | 数字正则规则 | 正则 /[a-z]{4}[0-9]{5} | regex/[a-z]{4}[0-9]{5} |
| 低 | 方法兜底规则 | 允许的全部请求方法 | Any request |
“方法兜底规则”仍是一条普通关联规则；它与虚拟服务的“默认分发规则”不是同一个配置项。此例中的全部方法为 GET、POST、PUT、DELETE、HEAD、OPTIONS、TRACE、CONNECT、PATCH。
用请求核对预期结果
| 请求 | 应命中的规则 | 核对重点 |
|---|---|---|
PATCH / | 高：PATCH 规则 | 高级别规则优先 |
DELETE /admin/4321 | 高：管理删除规则 | 路径与方法共同满足 |
POST /admin/4321 | 高：管理提交规则 | 同一路径可按方法分流 |
GET /abcdef | 高：字母正则规则 | 正则表达式与目标请求相符 |
GET /aaa | 中：精确 GET 规则 | 精确路径与方法均匹配 |
GET /aaa104?username=a&age=c | 中：参数规则 | 不被同级宽泛前缀规则抢先处理 |
POST /aaa101 | 中：前缀通用规则 | GET 条件不满足，继续匹配 |
GET /abcd12345 | 低：数字正则规则 | 正则规则放在低级别兜底规则前 |
GET /1001 | 低：方法兜底规则 | 未命中高、中级别的业务规则 |
前缀 /admin 也可能匹配 /admin123xxx。如果业务只希望匹配该目录下的请求，应明确考虑 /admin/ 与 /admin 本身的区别。正则示例没有添加首尾锚点，不能将它当成“整个 URL 必须完全一致”的表达式。
匹配规则与 URL 改写是两件事
分发策略决定请求走哪条规则；七层 HTTP 策略中的“修改转发 URL”决定后端收到什么路径。不要照搬 NGINX 配置中不同写法的尾斜杠行为。
例如，配置了把匹配请求的转发 URL 设为 /backend，请求 /api/users 的目标路径可以变为 /backend，并不必然保留为 /backend/users。应到后端访问日志核对实际收到的路径和查询参数。
静态资源的“URL映射”和“URL去前缀映射”是另一组配置，具体示例见 静态资源托管指南。
验证与排查顺序
- 确认请求到达正确的虚拟服务，记录方法、Host、完整路径和查询参数。
- 确认规则已关联到该虚拟服务，优先级和同级顺序符合预期。
- 核对每个实际匹配条件，特别是方法、大小写、路径末尾斜杠和查询参数。
- 核对命中后的处理方式、服务器池或自定义响应内容。
- 保存并执行变更；通过业务访问日志和后端响应确认命中结果。
| 现象 | 常见检查方向 |
|---|---|
| 总是走默认分发规则 | 未关联规则、条件不满足、变更未执行 |
| 总是走宽泛前缀规则 | 具体规则的条件不满足，或同路径规则的顺序不正确 |
| 正则规则未生效 | 优先级或同级顺序、表达式范围、实际请求 URI |
| 后端收到的路径不符合预期 | 关联的 HTTP 策略是否修改了转发 URL 或执行 URI 去前缀 |
| 调整一个规则后其他业务改变 | 同一规则或策略被多个虚拟服务复用，修改前应检查引用 |