内容摘要：打开浏览器，输入 `www.example.com`，DNS 把它解析到 `93.184.216.34`。再输入 `api.example.com`，解析结果一模一样。服务器收到请求，怎么知道你要访问

打开浏览器，域名输入 `www.example.com`，域名DNS 把它解析到 `93.184.216.34`。域名再输入 `api.example.com`，域名解析结果一模一样。域名服务器收到请求，域名怎么知道你要访问的域名是哪个网站？答案藏在 HTTP 请求头里——`Host` 字段。

这事比很多人想的域名要普遍。一台服务器跑几十个网站，域名是域名虚拟主机的日常操作。Nginx 配置里写几个 `server` 块，域名每个块监听同一个 80 端口，域名靠 `server_name` 区分。域名请求进来，域名Nginx 读 `Host` 头，域名匹配到哪个 `server_name`，就把请求交给哪个站点处理。匹配不上？走 `default_server`，通常返回一个空白页或者 444。

我自己的小服务器上跑着四个域名。一个主站，一个图床，一个用来测试的临时环境，还有一个给朋友挂的博客。四个域名在 DNS 里都指向同一个公网 IP，Nginx 用四个配置文件分开管。图床那个域名配了单独的 `client_max_body_size`，不然传大图直接 413。临时环境加了 IP 白名单，只有我自己的宽带能访问。这些差异化配置能生效，全靠 `Host` 头把请求路由对了地方。

HTTPS 时代这件事变得稍微复杂了一点。TLS 握手发生在 HTTP 之前，服务器这时候还没看到 `Host` 头。那它怎么知道该出示哪张证书？靠 SNI——Server Name Indication。客户端在 ClientHello 里把目标域名明文带上，服务器据此选择证书。SNI 不加密，所以旁观者能看出你在访问哪个域名，但看不到具体内容。如果客户端不支持 SNI，服务器只能返回默认证书，浏览器大概率报证书错误。好在这年头不支持 SNI 的客户端基本绝迹了。

有人会问：那我直接用 IP 访问不行吗？行，但有限制。直接访问 IP，请求头里没有 `Host`，或者 `Host` 就是那个 IP 地址。Nginx 匹配不到任何 `server_name`，走默认站点。如果你的默认站点恰好是你想访问的那个，那没问题。但多数情况下你会看到一个不属于任何域名的页面，或者直接被拒。更麻烦的是 HTTPS——证书是绑域名的，用 IP 访问必然证书不匹配，浏览器先给你一屏红色警告。

还有一种情况：多个域名指向同一个 IP，但跑在不同的端口上。比如 `a.com` 走 443，`b.com` 走 8443。这种就不依赖 `Host` 头了，靠端口区分。但用户得记住端口号，体验差，实际中不常见。更常见的变体是同一个域名不同子域走不同后端——`www` 走静态文件，`api` 走反向代理到本地 3000 端口，`ws` 走 WebSocket 升级。Nginx 配置里用 `location` 块继续细分，但入口仍然是同一个 IP 的 443 端口，靠 SNI 和 `Host` 两级路由。

DNS 层面也有玩法。同一个域名可以配置多条 A 记录，指向不同 IP，这叫 DNS 轮询。但题目说的是多个域名指向同一个 IP，方向反过来。实现上简单得过分：在 DNS 服务商那里加几条 A 记录，值都填同一个 IP。等 TTL 过期，解析生效。剩下的交给 Web 服务器。

有个坑值得提。如果你用 CDN，多个域名指向同一个 CDN 边缘 IP，那 CDN 回源时怎么区分？靠回源请求里的 `Host` 头。CDN 边缘节点收到用户请求，根据 `Host` 找到对应的源站配置，回源时把原始 `Host` 带上。源站 Nginx 再根据这个 `Host` 路由到正确的站点。整条链路上，`Host` 头像一根线，把域名和最终的服务串起来。

所以多个域名指向同一个 IP，技术上没有任何神秘之处。DNS 只管把域名翻译成 IP，不关心后面有几个网站共享这个 IP。Web 服务器靠 `Host` 头和 SNI 做虚拟主机路由，各站点互不干扰。配置对了，一切安静运行；配置错了，要么串站，要么 502。我见过最离谱的一次，是朋友把两个域名的 Nginx 配置写反了，结果主站显示图床的目录列表，图床返回主站的 404 页面。排查了半天，最后发现是 `server_name` 里两个域名顺序颠倒。改回来，十秒钟的事。