一个 IP 上放着很多网站：服务器怎么知道你要哪一个

授权与合规声明
本文全部操作对象均为自建隔离靶场（本机容器或隔离虚拟机），涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款，须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离，不含任何攻击步骤、利用载荷与绕过手法，请勿将文中环境指向任何非自有系统。

一个 IP 凭什么能同时放很多站

很多网站共用一个 IP，是极常见的部署方式。你 ping 几个不同的域名，回来的地址可能是同一个；你在同一台机器上放了好几份站点内容，浏览器访问不同域名却各进各家。服务器凭什么分得清？

「路由依据」这个身份，是规范给的

先把这句话原样搬出来，因为本文后面所有内容都从它长出来。RFC 9110 §7.2 的原文是：

The “Host” header field in a request provides the host and port information from the target URI, enabling the origin server to distinguish among resources while servicing requests for multiple host names.

这句的每一处用词都值得盯住：Host 提供的是来自目标 URI 的主机与端口信息；它的作用是让源服务器在"同时服务多个主机名"时，能够区分资源。换句话说，Host 不是网址的装饰，也不是某种加密标记，它是一份路由信息——服务端拿到它，才知道这一次请求要落到哪一份内容上。规范把这件事的机制称为 application-level routing mechanism，中文口径就是应用层的路由依据。

理解了这个身份，很多现象就不再奇怪：为什么同一个 IP 上能放很多站、为什么请求里总有这一行、为什么它既被正常路由依赖又被规范专门点名——都能顺着"它是路由依据"这条线解释下来。

还要注意「区分资源」这四个字的分寸。规范说的不是"服务器会去猜你要什么"，而是服务端在应答之前必须先知道"这一次请求该落到哪一份资源上"。Host 提供的正是做这个判断所需的那份信息：它是判断的输入，不是判断的结果，更不是内容本身。

一个地址配多个名字，靠什么对齐

Host 的语法本身短得出奇，RFC 9110 §7.2 里写作：

Host = uri-host [ “:” port ] ; Section 4

也就是说，它由"目标 URI 里的主机分量"加一个可选的端口组成。主机分量怎么取值，规范指向 §4；这部分本文只作定性，不展开。你要记住的是：它携带的信息来自目标 URI，而不是凭空生成的一个标签。

再读一遍那条语法：Host = uri-host [ ":" port ]。方括号在语法记号里表示"可选"，也就是说端口可写可不写；写出来时，取值就是目标 URI 里的端口。这意味着 Host 承载的信息，可以细到"同一个主机名下的不同端口"，也可以只到"哪一个主机名"。正因为它是从目标 URI 里取出来的，后面几章里那些"对得上、对不上"才都围绕它展开。

把常见的几种现象摊开对照一下，能看清它到底在管什么。

本章可以带走的一句：Host 的身份是应用层的路由依据，它不是网址的装饰，而是源服务器在"一个地址多个站点"时用来区分"你要哪一个"的依据。

请求里那行 Host 是从哪来的

如果它是路由依据，那这份信息是本来就有的，还是每次都得随请求带上？规范把这件事说得相当硬。

用户代理必须发，而且被建议放在首位

RFC 9110 §7.2 的原文：

The target URI’s authority information is critical for handling a request. A user agent MUST generate a Host header field in a request unless it sends that information as an “:authority” pseudo-header field. A user agent that sends Host SHOULD send it as the first field in the header section of a request.

拆成两件事看：一来，目标 URI 的权威信息对处理请求至关重要，所以用户代理 MUST 生成 Host 字段——除非它改用 :authority 伪首部来承载这份信息（这一条留到第 4 章细说）；二来，发 Host 时 SHOULD 把它放在请求头部的第一位。

这里要分清 MUST 与 SHOULD：MUST 是硬要求，没有"看情况"的空间；SHOULD 是"除非有充分理由，否则应当这样做"。放在首位这条属于后者——它是一个强建议，不是铁律。

把这条规定放进排查里看，MUST 那一句说明：请求里携带主机信息，是用户代理的义务，不是可选装饰；如果一次请求里这份信息出了问题，从规范角度看，是用户代理这一侧没有尽到它该尽的义务。SHOULD 那一句则说明：位置靠前是被期望的写法，不是硬性约束——所以你看到它并不总在第一位时，也不必立刻判成异常。把"硬要求"和"强建议"分开，能少制造一批假的"异常"。

规范自带的那两行样例

规范里给了一个最小示例，原文只有两行：

GET /pub/WWW/ HTTP/1.1
Host: www.example.org

本文只引这两行，不再构造任何其它报文样例。你能从这两行里看到的东西是：请求行之后，紧随其后的就是那一行主机信息——位置靠前，内容来自前面那个 URL 里的主机名。

想看真实请求里这一行长什么样，可以借助命令行工具做一次纯观察，不改写任何内容。

⚠️ 代码待验证

# 用 -v 观察一个请求的头部里是否出现主机信息这一行（只观察，不修改请求内容）
curl -v http://example.org/ -o /dev/null

说明一句：-v 会把请求的头部打到终端，你可以对照看到那一行。这里做的是观察动作，不是构造动作。

另一处值得留意的是：规范在这个位置只给了两行，并没有给"完整请求应该长什么样"的整段样例。它定义的是字段、语法和位置，而不是外观。也正因为如此，本文除这两行之外不再另外构造任何请求样例——那既不是规范给的，也容易把"某个工具的写法"误当成"协议的规定"。

有地址，不等于真的有服务器

还有一个容易想当然的地方，规范专门提示过。RFC 9110 §4.2 的原文：

Note that the presence of an “http” or “https” URI does not imply that there is always an HTTP server at the identified origin listening for connections. Anyone can mint a URI, whether or not a server exists and whether or not that server currently maps that identifier to a resource.

翻译成排查口径：URI 里写着 http 或 https，并不代表那个 origin 上一定有个 HTTP 服务器在监听连接。任何人都可以"造"出一个 URI，不管那台服务器存不存在、也不管它当下有没有把这个标识符映射到某个资源上。

所以排查时不要从"URI 里写的是这个主机"直接推出"这个主机上一定有服务在等我"。这两件事之间没有必然关系。

换个说法：URI 里写着某个主机，是名字层面的事；那个主机上有没有服务在听，是运行层面的事，二者相互独立。排查时把它们分开，能避开一个很常见的误判——因为 URL 看起来"很正常"，就默认对面一定有东西在应答。

本章可以带走的一句：请求里的主机信息是用户代理必须生成、并被建议放在首位的；而 URI 里写着某个主机，并不代表那个主机上一定有个服务在等你的连接。

服务端拿到请求之后先看什么

请求送到了，服务端并不是"看到就答"。规范把它的决策过程写得很清楚。

先解析出目标 URI，再决定怎么处置

RFC 9110 §7.4 的原文：

Once a request is received by a server and parsed sufficiently to determine its target URI, the server decides whether to process the request itself, forward the request to another server, redirect the client to a different resource, respond with an error, or drop the connection. This decision can be influenced by anything about the request or connection context, but is specifically directed at whether the server has been configured to process requests for that target URI and whether the connection context is appropriate for that request.

拆开看，顺序是固定的：收到请求 → 解析到"足以确定目标 URI"的程度 → 然后做五选一的判断：自己处理、转发给另一台服务器、重定向客户端、回一个错误、或者直接断开连接。

而这五选一具体怎么选，规范点明了两个专门指向的因素：一是这台服务器有没有被配置为处理这个目标 URI；二是收到请求的这条连接上下文，对这个请求合不合适。注意规范用的是"can be influenced by anything about the request or connection context, but is specifically directed at"——影响面可以很宽，但落点就这两处。

把这五类处置再念一遍，会发现它们是递进的：先看能不能自己答；不能，就考虑转给别人；再不行，考虑把客户端引到别处；还不行，回一个错误；最后才是断开连接。规范把它们并列给出，恰好说明"服务端该不该答"从来不取决于请求"长什么样"，而取决于它自己的配置边界与这条连接是否合适。

（依据：HT06）

想看"服务端到底答没答、答成了哪一类"，同样可以用工具只看响应这一侧。

⚠️ 代码待验证

# 只看响应头与状态行，响应正文丢弃；用于判断服务端如何处置这个请求
curl -sS -D – -o /dev/null http://example.org/

主机信息与连接对不上，意味着什么

还有一种情形规范专门提了：请求里携带的主机信息，与收到这条请求的连接的主机或端口对不上。RFC 9110 §7.4 的原文（本文只取它的定性，不往下写任何一种做法）：

For example, a request might have been misdirected, deliberately or accidentally, such that the information within a received Host header field differs from the connection’s host or port. If the connection is from a trusted gateway, such inconsistency might be expected; otherwise, it might indicate an attempt to bypass security filters, trick the server into delivering non-public content, or poison a cache.

规范把这种情况分两类：如果连接来自可信网关，这种不一致可能是预期之内的；否则，它可能是想绕过安全过滤、诱导服务器吐出非公开内容、或者污染缓存。本文只到这句定性为止，任何一种"怎么做"都不在本文范围内。 作为一个在自建环境里排查的人，你需要带走的是：主机信息与连接上下文是否一致，本身就是服务端做判断时会看的输入之一。

规范为什么要特意把它分成"可信网关"与"否则"两类？因为这条判断背后有一个前提问题：这条连接究竟是谁送来的。请求经由你信任的中间环节进来时，主机信息与连接"对不上"可能是链路的正常结果；请求若是直接来的，这种不一致就更值得警惕。本文不展开任何一种利用方式，但这条判断逻辑可以带走——它看的是"这份信息与这条连接是否自洽"。

本章可以带走的一句：服务端先解析出目标 URI，再决定自己答、转给别人、重定向、报错还是断连；主机信息与连接上下文相不相符，是它判断时会看的输入之一。

换成 HTTP/2、HTTP/3 之后，那行 Host 去哪了

讲到这里，Host 一直待在请求头里。可如果你在新一代协议下抓包，可能会发现"这一行不见了"。它去哪了？

它有了一个替身

RFC 9110 §7.2 里紧跟着一句说明，本文只引这一句，不展开版本之间的完整差异：

In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], the Host header field is, in some cases, supplanted by the “:authority” pseudo-header field of a request’s control data.

关键在 “in some cases”——是某些情况下被取代，不是一律被取代。也就是说，在较新的协议版本里，承载"你要哪一个主机"这份信息的位置，可能从请求头部挪到了请求控制数据里的 :authority 伪首部。承载它的信息没有丢，换了个位置而已。

换个角度说：变的只是承载位置，不是信息本身。路由依据这个身份没有变——服务端依然要靠"你要哪一个主机"来做区分，只是在新协议里，这份信息被放进了请求的控制数据。记住这一点，比记住某个字段名更有用。

⚠️ 代码待验证

# 用支持 HTTP/2 的客户端发起请求，观察承载主机信息的位置与 HTTP/1.1 下的呈现不同
curl –http2 -v https://example.org/ -o /dev/null

说明：能不能在输出里直接看到那个伪首部，取决于客户端与它的输出方式，本文未核具体的呈现形式，这里只做观察，不据此下结论。

知道有替身，排查时少绕一圈

抓包时如果发现"这一版的请求里看不到主机那一行"，先别急着下"没有主机信息"的结论。按 HT02 的口径，它很可能就是被 :authority 取代了。知道有这么一个替身，能省掉一轮误判——这属于排查里的"少绕一圈"。

本章可以带走的一句：在新一代协议里，主机信息的替身是请求控制数据里的 :authority，而且是"某些情况下"取代，不是一律取代。

它为什么既是路由依据，也被规范点名为风险点

同一份信息，一边被路由依赖，一边被规范专门点名，这件事值得单独说清楚。

规范自己就说它是常被盯上的目标

RFC 9110 §7.2 的原文（本文只取性质，不写手法）：

Since the host and port information acts as an application-level routing mechanism, it is a frequent target for malware seeking to poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it relies on the host and port information for redirecting requests to internal servers, or for use as a cache key in a shared cache, without first verifying that the intercepted connection is targeting a valid IP address for that host.

这句话的信息量在"为什么"：正因为主机与端口信息扮演的是应用层路由机制的角色，它才成了常见的目标。规范点出的脆弱环节也很具体——凡是拿它来把请求转给内网服务器、或拿它当共享缓存的键、却没有先核实"这条连接的目标地址是否真的是这个主机的合法地址"的中间环节，尤其危险。

请把边界记清楚：规范讲的是"常见的目标"以及"哪些环节脆弱"，本文一句手法都不往下写。

为什么"路由依据"几乎注定要成为风险面？因为它会被信任。一个中间环节如果把主机信息当成"可信的路由指令"，就等于把"往哪儿送、拿什么当缓存键"的决定权，交给了请求方提供的内容。规范点到的那类脆弱，本质都是"先用了、却没有先核实"。这个道理可以带走：凡是拿请求里的信息去做路由或缓存决策的环节，都该先问一句——这条连接真的指向那个主机吗。

https 资源上的那条硬要求

https 资源上还有一条更硬的。RFC 9110 §7.4 的原文：

Unless the connection is from a trusted gateway, an origin server MUST reject a request if any scheme-specific requirements for the target URI are not met. In particular, a request for an “https” resource MUST be rejected unless it has been received over a connection that has been secured via a certificate valid for that target URI’s origin, as defined by Section 4.2.2.

译成排查口径：除非连接来自可信网关，源服务器一旦发现"目标 URI 的 scheme 相关要求没有被满足"，就 MUST 拒绝。落到 https 资源上更具体——这条连接必须经过一张对该目标 URI 的 origin 有效的证书保护，否则必须拒绝。

这就解释了一个常见的困惑：靶场里"端口通、连接也建起来了，服务端却还是拒"。它拒的不是"你不该连过来"，而是"这个 origin 还没有以它能接受的方式被证明过"。§4.2.2 本身的内容本文未核，只引到这里的引用句。

注意 MUST reject 的分量——拒绝在这里不是"可选应对"，而是规范认定的默认正确动作。这条要求也解释了一种常见的困惑：连接建立成功，和"这条连接能不能代表那个 origin"是两回事，后者才是 https 资源真正关心的门槛。

421：服务器说「你找错地方了」

对应地，规范给了一个明确的状态码。RFC 9110 §15.5.20 的原文：

The 421 (Misdirected Request) status code indicates that the request was directed at a server that is unable or unwilling to produce an authoritative response for the target URI. An origin server (or gateway acting on behalf of the origin server) sends 421 to reject a target URI that does not match an origin for which the server has been configured (Section 4.3.1) or does not match the connection context over which the request was received (Section 7.4).

客户端侧它也给了话：

A client that receives a 421 (Misdirected Request) response MAY retry the request, whether or not the request method is idempotent, over a different connection …

归纳一下：421 的含义是"这台服务器不能或者不愿为这个目标 URI 给出权威应答"。触发它的两类典型情形是——目标 URI 不匹配这台服务器被配置的 origin，或者不匹配收到请求的那条连接上下文。而客户端这一侧，收到 421 之后 MAY（可以，不是必须）换一条连接重试，规范特意点了"无论请求方法是否幂等"。

客户端那侧的 MAY 也值得记一下：规范并没有要求客户端"必须重试"，只说它"可以"，而且是换一条连接去重试。这意味着客户端有自主判断的空间——它得先想清楚"是不是自己选错了服务器"，再决定要不要重来。读规范读到这种地方，就能解释"为什么同样的请求，客户端有时会自己再试一次"。

把三种"拒"放在一起对照，边界会更清楚。

⚠️ 代码待验证

# 观察 TLS 握手里客户端声明的目标主机名，用于理解"连接上下文"是否匹配
# 注意：它与 Host 的关系本文未核，这里只做观察，不据此下结论
openssl s_client -connect example.org:443 -servername example.org </dev/null

⚠️ 代码待验证

# 只看状态码，判断某个请求是否被拒，以及被拒成了哪一类
curl -sS -o /dev/null -w '%{http_code}\\n' https://example.org/

本章可以带走的一句：主机信息是应用层的路由依据，所以它既被路由器依赖，也被规范点名为风险点；在 https 资源上，连接无法证明该 origin 时，源服务器必须拒绝。

完整版协议对照资料：这份资料把 HTTP 语义里与请求路由相关的几个字段、状态码与必要条件整理成一页对照，正好对应本章讲到的"路由依据 + 硬要求 + 421"。放在资料包里，扫码即可获取：

四个常见判断，逐个说清

初学时最容易把几件事揉成一句"连不上"。这里拆成四问，逐个对。

前两个：它们直接就是路由问题

一、域名解析到多个 IP。 这就意味着同一个名字可能被送到不同的机器上。但要注意：请求里携带的主机信息并不会因此改变——它来自目标 URI（HT01）。所以"解析变了"和"路由依据变了"是两件事。名字解析这一段本文不复述，另有专文写过。

二、同一 IP 上多个域名。 这正是 Host 存在的理由（HT01）。服务端按请求里的主机信息区分目标资源；你看到"同一个地址，回来内容不同"，就是这一步在工作。

把这两问放在一起，能看出一条分界线：**"请求送到哪台机器"与"这台机器该给哪份内容"是两个独立的问题。**前者和地址有关，后者和请求里携带的主机信息有关。弄清楚这条线，很多"地址明明没写错、却进错了站"的困惑就能解释。

后两个：一个未核，一个要分段看

三、Host 与 SNI 的关系。 本文未核。 规范里 Host 是 HTTP 层的字段（HT01、HT02），而 TLS 握手里还有一个"客户端声明的目标主机名"的位置；两者是不是总一致、由谁生成，本文没有核到一手依据，标"待验证"。排查时如果发现两者看起来不一致，不要凭印象下结论。

四、改了本地的名字记录，能不能连上。 本地记录作用在名字解析这一段——本文不复述这条轴。你需要分清的是：请求里携带的主机信息来自目标 URI 的 authority（HT01、HT02 语法），而各客户端具体如何填充这一字段，本文未核（HT11）。所以"能不能连上"要么卡在"请求有没有送到该去的地方"，要么卡在"送到之后服务端认不认"，这是两段，要分开看。

这四问的排列也有用意：前两问能直接用已核事实回答；后两问里，一个明确标着"未核"，一个需要把两段分开看。把"我知道的"和"我还没核的"摆在一起，本身就是一种诚实——规范之外的东西，不该靠印象去补。

本章可以带走的一句：名字解析、路由依据、TLS 握手这几件事各管一段，不要揉成一句"连不上"。

一张排查顺序表

把前六章的事实压成一张顺序表，遇到问题照着问。

按这个顺序问四个问题

第一步问连接：请求有没有送到对的地址？第二步问路由依据：请求里携带的主机信息是什么？第三步问配置：服务端被配置为处理这个目标 URI 吗（HT06）？第四步问连接上下文：这条连接合格吗，尤其 https（HT07、HT08）？

为什么把"送对地址"放在第一步？因为它是最外层的前提：请求没到该去的地方，后面三步都无从谈起。为什么把"连接上下文"放在最后？因为它最容易被忽略，而 https 上的拒绝恰恰常常卡在这里。顺序本身就是一层经验排序。

⚠️ 代码待验证

# 一次把过程看清楚：连接、请求头、响应，按上面四步逐个对照
curl -v https://example.org/ -o /dev/null

回到开头那个问题

服务器凭什么知道你要哪一个？凭请求里那份来自目标 URI 的主机信息（HT01）。它是用户代理必须生成的（HT03）；在服务端，它被用来区分资源（HT01）、决定怎么处置这次请求（HT06）；在 https 上，它还要配合"连接能证明该 origin"这条硬要求（HT08），证明不了就会吃到 421 一类的拒绝（HT09）；如果换了协议版本，它可能改由 :authority 承载（HT02）。

一路看下来会发现：所谓"服务器知道你要哪一个"，其实不是服务器会读心，而是请求每次都把这份信息带上了，服务端按它做判断而已。

还要意识到，这几个环节是层层递进的，不是并列的选项：地址先对了，才轮到看主机信息；主机信息有了，才轮到服务端判断配置；配置覆盖了，才轮到检查连接上下文。任何一环不满足，后面都无从进行——这也解释了为什么排障时"跳步"往往越查越乱。

本章可以带走的一句：排查"一个地址多个站点"的问题，按"送到对地址 → 看主机信息 → 看配置是否覆盖 → 看连接上下文是否合格"四步走，比一上来就猜服务端要靠谱得多。

完整版协议速查卡：把本文用到的 RFC 9110 条款（§7.2、§7.4、§4.2、§15.5.20）压成一张速查卡，排查时对着条号回溯一手原文。放在资料包里，扫码即可获取：

附表 A：本文引用事实与官方出处对照表

附表 B：术语速查表

写在最后：这篇用到的资料

写这篇文章时，把 RFC 9110 里和"一个地址多个站点"相关的几条原文逐字核了一遍，顺手也整理了几份配套的东西：

• 靶场环境对照表：DVWA、upload-labs 在 Windows / macOS / Linux 三平台的可行性与推荐路径
• Web 安全学习路线图：从基础打牢到安全管理，四个阶段各学什么
• 常用靶场清单：每个靶场练什么、适合哪个阶段

资料是我自己整理的，放在下面这个码上，扫码即可获取：

添加时备注「靶场」，优先通过。

拿到之后建议先看环境对照表那一份，把靶场的地址与主机名对齐再抓包，本文讲的那些字段会对得上号。