mod_proxy_balancer可通过ProxyPass路径顺序、balancer组隔离和RewriteRule动态分流实现业务路径策略路由；需遵循从具体到宽泛的配置顺序，严格尾斜杠匹配，并配合balancer-manager实时监控。
Apache 的 mod_proxy_balancer 本身不直接识别“业务路径”，但配合 mod_proxy 的 ProxyPass 指令和路径匹配优先级，就能实现按 /api/、/static/、/admin/ 等路径前缀做策略隔离——关键在于路径配置顺序、后端分组定义和重写逻辑的协同。
路径匹配必须从具体到宽泛
Apache 按 ProxyPass 配置顺序逐行匹配，一旦命中就停止后续检查。所以更长、更具体的路径必须写在前面，否则会被更宽泛的规则提前截断。
-
ProxyPass "/api/v2/" "balancer://api-v2/"—— 必须放在 /api/ 前面 -
ProxyPass "/api/" "balancer://api-v1/"—— 匹配所有 /api 开头但未被 v2 规则捕获的请求 ProxyPass "/static/" "balancer://static/"-
ProxyPass "/" "balancer://default/"—— 放在最后，兜底所有未匹配路径
注意：路径末尾斜杠必须严格一致。/api/ 不会匹配 /api（无尾斜杠），建议统一用带尾斜杠形式，避免歧义。
为每类业务定义独立的 balancer 组
不同路径应路由到逻辑隔离的后端池，每个池可配置专属策略，比如健康检查方式、负载算法、权重或会话保持规则。
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
- API 类服务常用
bytraffic（按流量）或bybusyness（按当前请求数），响应时间敏感 - 静态资源适合
byrequests（轮询），或启用缓存优化，无需会话保持 - 管理后台可单独设高权限后端组，配合 IP 白名单或 Cookie 鉴权
示例分组定义：
BalancerMember http://10.0.1.10:8000 route=api2-1 loadfactor=2
BalancerMember http://10.0.1.11:8000 route=api2-2 loadfactor=2
ProxySet lbmethod=bybusyness timeout=8 retry=30
BalancerMember http://10.0.2.10:80 static-only
BalancerMember http://10.0.2.11:80 static-only
ProxySet lbmethod=byrequests
用 RewriteRule 实现动态路径分流
当路径规则超出前缀匹配能力（比如需看请求头、参数或 Cookie），可在 ProxyPass 前插入 RewriteRule 进行预处理。
- 根据 Cookie 区分用户角色：
RewriteCond %{HTTP_COOKIE} role=admin [NC]RewriteRule ^/(.*)$ balancer://admin-backend/$1 [P,L] - 强制静态文件走专用组：
RewriteRule \.(js|css|png|jpg|gif)$ balancer://static-backend%{REQUEST_URI} [P,L] - 把带版本号的 API 请求重写到对应集群：
RewriteRule ^/v3/(.*)$ balancer://api-v3/$1 [P,L]
务必加 [P]（代理标志）和 [L]（终止标志），防止后续规则干扰。
启用 balancer-manager 查看与干预状态
路径级策略是否生效，最直观的方式是访问 /balancer-manager 页面，确认各 balancer://xxx 组的状态、当前活跃节点、失败计数等。
- 需确保已启用
mod_status和mod_proxy_balancer - 在虚拟主机中放行访问：
<location></location>Require ip 192.168.1.0/24 - 页面上可手动标记节点 Up/Down，验证故障隔离效果
