HTTP 监听是什么
HTTP 监听启用七层能力：负载均衡解析请求后按域名与路径把流量分发到不同服务器组，还能附加请求头、启用 Cookie 会话保持、做重定向与重写。配置顺序建议先把默认服务器组设好做兜底，再逐条添加转发规则与匹配条件，避免请求未命中规则时直接报错。
基本信息
| 转发规则 | 域名 / 路径条件 → 目标服务器组 |
|---|---|
| 默认兜底 | 未命中任何规则时转发的服务器组 |
| 会话保持 | 七层通过 Cookie 实现，可植入或重写后端 Cookie |
| 扩展能力 | 重写、重定向、限速、ALB 类产品支持的更细粒度规则 |
| 匹配优先级 | 精确域名优先于通配域名，长路径优先于短路径（以产品文档为准） |
| 附加请求头 | 可注入 X-Forwarded-For 等头，便于后端获取真实客户端地址 |
典型使用场景
- 多个业务域名共用一个入口，按域名转发到各自后端
- 同一域名下 /api 与 /static 分发给不同服务或服务器组
- 灰度发布：把特定路径或带特定请求头的流量导向新版本
- 在入口统一做 HTTP 到 HTTPS 跳转与请求头注入
- 为不同客户端返回不同后端：按域名区分站点与接口
本地模拟携带 Host 的请求
本地模拟携带 Host 的请求
curl -sv -H 'Host: api.example.com' http://<LB地址>/v1/ping
# 观察返回内容是否来自该域名对应的服务器组
curl -s -o /dev/null -w '%{http_code}\n' -H 'Host: api.example.com' http://<LB地址>/
# 未命中规则时会落到默认服务器组，返回内容可用于反推匹配结果匹配规则要点
| 配置项 | 说明 | 注意 |
|---|---|---|
| 域名条件 | 精确域名或泛域名 | 泛域名覆盖范围要提前盘点 |
| 路径条件 | 支持精确与前缀匹配 | 路径写法以产品文档为准 |
| 默认服务器组 | 兜底接收未命中请求 | 不配置会让未命中请求直接报错 |
| 会话保持 | Cookie 粘性 | API 客户端不回传 Cookie 时无效 |
| 请求头注入 | 补充转发头 | 不能替代入口对伪造头的清洗 |
规则匹配优先级以产品文档为准，常见约定是精确域名优先于通配、长路径优先于短路径；调整规则前先确认当前实际生效的匹配关系。
通配域名（如星号记录形式的域名条件）会命中所有未单独配置的子域，新增前先盘点会被它覆盖的范围，避免抢走其他业务的流量。