HAProxy的ACL不参与Apache动态路由，仅在请求到达前基于Host、Path、Header等特征做流量分发决策；需Apache配合ProxyPreserveHost和ProxyPassReverse确保请求头与重定向正确。
HAProxy 的 ACL（Access Control List）规则本身不直接参与 Apache 的动态路由分发，因为 Apache 的路由逻辑由其自身（如 mod_rewrite、mod_proxy 或虚拟主机配置）处理；HAProxy 作为前置负载均衡器，只负责在请求到达 Apache 之前，根据 ACL 做**流量分发决策**。真正“动态路由”的实现，是 HAProxy 基于请求特征（如 Host、Path、Header、Cookie、IP 等）匹配 ACL，再将请求转发到不同后端服务器组（例如不同版本的 Apache 实例、灰度环境、多租户集群等）。这种组合方式能有效解耦路由策略与应用逻辑。
ACL 如何识别关键路由特征
HAProxy 的 ACL 是轻量级匹配表达式，用于提取并判断请求中的结构化信息。常用识别维度包括：
-
域名与路径：用
hdr(host)匹配多租户子域（如tenantA.example.com），用path_beg或path_reg匹配 API 版本前缀（如/v2/或/api/users） -
请求头与 Cookie：用
hdr(x-deployment)读取灰度标头，或cook(ENV)检查用户会话中携带的环境标识 -
客户端属性：用
src限制内网调试流量，或ssl_fc_sni区分 TLS 域名（对 SNI 多证书场景很重要）
基于 ACL 的后端分发策略配置示例
在 frontend 段定义 ACL 并绑定 use_backend 规则，即可实现条件路由。例如：
frontend http-in
bind *:80
# 定义 ACL
acl is_v2_api path_beg /v2/
acl is_admin_host hdr(host) -i admin.example.com
acl is_canary_cookie cook(traffic) -m sub canary
<pre class="brush:php;toolbar:false;"># 分发规则（顺序执行，首匹配优先）
use_backend apache-canary if is_canary_cookie
use_backend apache-admin if is_admin_host
use_backend apache-api-v2 if is_v2_api
default_backend apache-main
注意：ACL 判断发生在请求解析后、转发前，不依赖 Apache 响应；所有后端 server 可指向不同 Apache 实例（或同一集群的不同端口），各自运行独立配置。
与 Apache 协同的关键注意事项
要让 HAProxy 的分发真正“生效”，Apache 后端需配合做好两件事：
-
保留原始请求头：在 Apache 的
ProxyPass或mod_proxy配置中启用ProxyPreserveHost On，确保Host头不被覆盖，便于 Apache 内部做虚拟主机路由 -
正确处理重定向与 Cookie 路径：若 Apache 返回
302或设置 Cookie，需用ProxyPassReverse重写响应头中的 Location 和 Set-Cookie 域名/路径，避免跳转错位或 Cookie 作用域失效 - 避免循环或冲突：不要在 Apache 中重复实现与 HAProxy 相同维度的路由（如都按 Host 分发），否则易导致逻辑嵌套、调试困难
调试与验证方法
上线前建议通过以下方式确认 ACL 行为符合预期：
- 使用
haproxy -c -f /etc/haproxy/haproxy.cfg校验语法 - 开启 HAProxy 统计页面（
stats enable），实时查看各 backend 的请求命中数 - 用
curl -H "Host: tenantB.example.com" http://haproxy-ip/手动模拟请求，结合tcpdump或后端 Apache 的 access_log 验证实际转发目标 - 在配置中临时添加
http-request set-var(req.acl_match) str("none")+ 多个http-request set-var(req.acl_match) str("canary") if ...，再用log-format输出变量，直观跟踪匹配路径
