负载均衡转发规则里的主机头匹配，核心作用就是让多个域名共用同一台服务器或同一组后端时，根据用户访问的域名精确分发流量。简单说，它读的是HTTP请求里的Host字段，也就是用户在浏览器地址栏输入的域名，配置好之后，访问a.example.com和b.example.com就能进入不同的后端服务，互不干扰。
主机头匹配到底在解决什么问题
互联网早期,一台服务器对应一个域名，用IP就能区分，但现在的架构里，一台服务器托管几十个网站是常态，云上负载均衡实例也要处理多个域名的流量，这时候，负载均衡光看IP和端口已经不够了，因为所有域名的流量到达的都是同一个IP和端口。
主机头（Host Header）就是HTTP/1.1协议规定的必填字段，浏览器发起请求时，会自动带上你输入的域名，负载均衡器解析这个字段，然后和转发规则里的条件比对，匹配上了就走这条规则，匹配不上就走默认规则。
行业共识认为,主机头匹配的价值有三层：
- 多域名复用：一个负载均衡实例挂多个域名，节省成本和管理精力
- 灰度发布：让一部分用户访问新版本，用特定域名或测试域名指向新后端
- 精细化路由：不同域名对应不同业务线，比如官网、API、管理后台各走各的
负载均衡主机头匹配配置怎么弄
配置入口通常在负载均衡控制台的监听详情页里,点击“转发规则”或“规则管理”就能看到，不同云厂商的界面略有差异，但核心参数是一样的：域名、URL路径、后端服务器组。
第一步：确定监听协议和端口
主机头匹配属于七层负载均衡（HTTP/HTTPS）的能力，四层负载均衡（TCP/UDP）里看到的是IP和端口，没有主机头的概念，所以你得先确认监听协议是HTTP或HTTPS，源端口一般是80或443。
第二步：填写转发条件
在新建转发规则时,你会看到两个条件：域名和URL路径，这里只需要填域名，路径保持默认的，以Nginx的配置习惯来说，等效的配置长这样：
server { listen 80; server_name a.example.com; location / { proxy_pass http://backend_a; } }
云控制台上的操作更偏向可视化,你只需要：
- 在“域名”输入框里填
a.example.com，注意不要带协议头（不要写https://） - 在“URL路径”里填，代表所有路径都走这条规则
- 选择对应的后端服务器组
- 保存后再添加一条域名
b.example.com的规则，指向另一组后端
第三步：验证匹配效果
配置完成后,用不同域名分别访问测试，在服务器上执行curl -H "Host: a.example.com" http://负载均衡IP/，观察返回内容是否来自对应的后端组，用curl -H "Host: b.example.com" http://负载均衡IP/再测一次，应该返回另一组的结果。
填域名时千万别带空格和多余的符号，有些新手会下意识填http://a.example.com或a.example.com/，这会导致匹配不生效，请求直接落到默认规则上。
主机头匹配和路径匹配区别在哪
两者的角色定位完全不同：主机头管的是“哪个域名来”，URL路径管的是“哪个资源被请求”，实际转发时，两者经常组合使用。
| 对比维度 | 主机头匹配 | URL路径匹配 |
|---|---|---|
| 匹配对象 | 请求头里的Host字段 | URL中的路径部分 |
| 典型场景 | 多域名共用实例 | 同一域名不同功能模块 |
| 配置示例 | a.example.com |
/api/、/admin/ |
| 优先级 | 高，先匹配域名 | 低，域名命中后再看路径 |
| 常用程度 | 多域名时必用 | 单域名微服务时常用 |
举个例子,你有一个电商平台，域名是shop.example.com，你可能希望/api/开头的请求全部转发给后端A（接口服务），/static/开头的转发给后端B（图片和静态资源），其他路径给后端C（页面渲染），这就是路径匹配的典型用法，而如果你同时运营着shop.example.com和payment.example.com，支付域名的流量要专线处理，那就得靠主机头匹配。
表里的优先级关系在大多数负载均衡产品里是默认的：先判断域名，再判断路径
，也就是说，一条规则的域名必须匹配，才继续匹配它的路径条件。
主机头配置最容易翻车的地方
主机头匹配原理不复杂,但实际生产环境中踩坑的人不少，下面这几个问题，属于高频事故点。
没配置默认规则导致请求全部丢失
有些产品只在“转发规则”里写了具体的域名规则，忘了加默认转发，结果业务跑得好好的，突然来了一波没有匹配到任何规则的请求，被直接丢弃。建议保留一条默认规则，指向一个兜底的后端页面，哪怕是个404页面也比连接被拒绝强。
大小写和全半角问题
域名匹配规则在大多数实现里不区分英文大小写,但你要是在域名后面带了句号、逗号或者中文输入法的字符，匹配一定失败，有些浏览器或客户端会自动把域名转成小写，你规则里写了大写，测试时用大写域名能通，实际用户用小写访问却匹配不上。
与HTTPS证书的关系没理清
做HTTPS监听时,主机头匹配和SSL证书的域名是两码事。证书决定握手阶段是否受信任，主机头决定握手之后流量往哪转发，如果你有多个HTTPS域名，需要每个域名都有对应的证书，但主机头规则可以指向同一个后端，也可以指向不同后端，在云厂商控制台配置HTTPS监听时，通常要先把证书绑定到监听器上，然后再配置转发规则里的域名。
多域名场景下主机头的进阶玩法
当你需要管理的域名超过三个,单纯的“一对一”配置就不够用了，这里有几个实践中被反复验证的技巧。
泛域名匹配
部分负载均衡产品支持通配符域名,比如.example.com，这样blog.example.com、news.example.com可以走同一条规则。注意通配符只匹配一级，a.b.example.com不会被`.example.com`命中，需要单独配置或使用更深的通配。
主机头与后端健康检查的联动
有的团队问过：为什么后端服务器明明活着，负载均衡却显示不健康？这时候要看一下健康检查的请求头。健康检查默认发出的Host可能是IP地址或实例ID，后端应用如果开启了域名白名单，会直接拒绝这个请求
，解决办法是在健康检查里配置自定义Host，让探测请求带上后端能识别的域名。
主机头匹配做A/B测试
用两个域名指向同一个负载均衡,一个对外是正式域名www.example.com，一个内部测试域名beta.example.com，测试域的规则指向新版本后端，正式域规则指向稳定版后端，等新版本观察一段时间没问题，改一下规则里的后端组，就完成平滑上线。不需要动DNS，也不需要改任何业务代码。
负载均衡转发规则主机头匹配常见问题
负载均衡主机头匹配不到是什么原因造成的
先确认请求确实到达了这台负载均衡器,再检查规则里填写的域名是否和实际请求的Host完全一致（泛域名看层级），然后确认路径条件没有和域名条件形成交集冲突，如果规则列表里有多条相似规则，匹配顺序是按照精确度排序的，最精确的优先，不是按你创建的先后顺序。
主机头匹配和SNI是一回事吗
不是,SNI（Server Name Indication）是TLS握手阶段扩展，客户端在加密之前告诉服务器想访问哪个域名，用于选择正确的SSL证书，主机头匹配发生在HTTP层，TLS握手完成、解密之后，配置HTTPS监听时，两者会同时协同工作，但作用阶段完全不同，如果只需要分发流量，只配主机头就够了；如果想多个HTTPS域名共用同一个IP和443端口，SNI也需要配。
一个负载均衡实例最多能配多少条主机头规则
不同云产品限制不同,多数云厂商的控制台没有硬性数量上限，但规则越多，匹配性能损耗和排查复杂度都会上升，建议把主机头规则保持在50条以内，超出这个量级就该考虑拆分到多个负载均衡实例或使用更上层的网关产品，据业内专家指出，规则数量与性能之间并非线性关系，更多的规则往往意味着更长的匹配时间，虽然大多数情况下这个差异在毫秒级。
主机头匹配的价值并不在于功能多高级,而在于它把“域名”和“服务”之间的黏合变得清晰可控，掌握它的用法，意味着你在多域名架构中拥有了最直接的调度手段，无论是复用现有机器还是支撑业务快速迭代，先把主机头匹配弄清楚，很多转发问题都会迎刃而解。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/635016.html
