TCP包头本身不直接携带域名，但通过TLS握手时的SNI扩展字段，域名信息确实能被明文暴露在网络上。当用户访问HTTPS网站时，TCP作为传输层协议负责建立连接，而域名信息的传递发生在更上层的TLS协议中SNI字段在TCP三次握手后、加密通道建立前的关键时刻被发送出去，形同“在锁上门之前先喊出目的地”。
域名到底藏在哪里？先看清TCP包头的真实布局
TCP包头是一个高度结构化的数据块，标准长度为20字节，核心字段包括源端口、目的端口、序列号、确认号、数据偏移、标志位和窗口大小等，这些字段各司其职，但其中并没有一个名为“域名”的字段。
要理解这个问题，需要先区分网络分层模型中的不同角色，TCP负责的是“数据能否可靠到达”，它关心的是IP地址和端口号，域名则是应用层概念，由HTTP协议或DNS协议处理，当浏览器访问一个网址时，真正发出TCP请求的目标是服务器的IP地址,而非域名本身。
那么大众常说的“TCP包头藏域名”到底是怎么回事？实际场景中,域名信息是通过三种路径暴露的：
- HTTP请求的Host头：明文HTTP协议中，请求行之后会跟随Host字段，完整的域名以明文方式出现在数据包中
- TLS的SNI扩展：HTTPS加密后，HTTP内容不可见，但TLS握手阶段的SNI字段仍需明文传输服务器名称
- DNS查询阶段：TCP连接建立前，系统会先向DNS服务器发起域名解析请求，这个阶段的域名同样是明文的
这里需要特别说明一个时间顺序问题：DNS查询发生在TCP三次握手之前，而SNI字段的传输发生在TCP三次握手之后。严格意义上说，抓包工具看到的“TCP包”里是否含域名，取决于抓包位置和分析方式，如果仅解析TCP包头本身，确实找不到域名；但如果查看TCP负载数据，即上层协议内容,就能看到明文传输的域名信息。
SNI字段的运作原理：握手阶段如何泄露域名
SNI是Server Name Indication的缩写，它是TLS协议的一个扩展字段，作用是在TLS握手初期告知服务器客户端想要访问的域名，这个设计的初衷是为了解决
一台服务器托管多个HTTPS网站（即虚拟主机）时,服务器无法提前知道该返回哪张SSL证书的问题。
SNI在TCP连接中的具体位置
整个过程的步骤非常明确,可以精确还原如下：
TCP三次握手（对应第1-3个包）中不含有任何域名信息，三次握手包的内容主要是SYN、SYN-ACK和ACK标志位，负载为空或极短，即便全量抓包,从这三个包里也提取不出域名。
真正的域名泄露发生在第4.5个包之前TCP握手完成的瞬间，客户端立即开始TLS握手，发送ClientHello消息，在这个消息的扩展区域，SNI字段携带着访问域名的明文内容，抓包工具如果在这个位置进行过滤，能清楚看到类似server_name=example.com的信息。
加密与透明之间的尴尬平衡
TLS设计的核心目标是加密应用层数据，但SNI字段在协议设计上被刻意保留为明文，原因很现实：CDN节点、负载均衡器和防火墙都需要通过SNI来判断流量去向，如果SNI也加密,这些网络设备将无法正常工作。
这个矛盾直接引出了一个经典议题：HTTPS加密的是内容，而非目的地，业内专家指出，这种设计在安全性上属于“已知的妥协”，后续推出的ECH协议虽然试图加密SNI，但由于部署复杂度和兼容性问题,至今尚未大规模普及。
真实网络场景中的域名暴露风险
理解SNI机制后，实际网络环境中的域名暴露情况远比想象中更频繁，对于需要在特定场景下排查问题或分析流量的用户来说,掌握这些知识有实际价值。
运营商与防火墙的域名审查原理
在国内网络环境下，域名信息的可见性影响着内容分发、合规审查和网络管理，当用户访问一个网站时,沿途的路由器和运营商设备能在以下节点清晰看到域名：
- DNS解析阶段：访问目标域名的DNS请求完全透明，即便开启了DoH加密，传统DNS请求依然会被某些网络设备拦截识别
- TCP握手后的TLS阶段：ClientHello报文中的SNI字段虽然属于TLS协议，但网络设备不需要解密就能读取
- 证书传输阶段：服务器返回的证书链中包含证书的Common Name和Subject Alternative Name，同样以明文传输
这意味着，即便用户访问的是经过HTTPS加密的网站，网络链路上的旁路设备依然能通过SNI识别出访问目标是哪个域名，一些流量分析系统就是不通过解密内容,仅通过SNI来统计用户访问行为的。
域名信息服务商与CDN的协作逻辑
分发网络的高效运作也依赖SNI字段，当一个请求到达CDN边缘节点时，节点会根据SNI携带的域名信息判断应该调度到哪个源站，以及应用哪套缓存策略，换句话说，CDN服务的整个调度逻辑是建立在明文SNI之上的。
在实际运维场景中，这种机制还衍生了一个常见问题证书配置错误，比如一张SSL证书绑定了十个域名，当其中一个域名解析到CDN后，边缘节点可能需要通过SNI逐一匹配证书，如果SNI字段中包含的是一个未配置的域名，服务器会回退到默认证书，从而导致浏览器报证书错误，这提醒网站管理员在配置CDN和证书时，务必确认SNI与证书域名列表的一致性。
域名信息的实际抓取方法与判断技巧
对于网络工程师和运维人员，掌握数据包中域名信息的抓取方法是排查问题的基本功,下面介绍几个实用的操作路径。
使用Wireshark过滤域名信息
Wireshark是最常用的抓包工具,其操作路径非常直观：
- 启动抓包后，在过滤器栏直接输入
tls.handshake.extensions_server_name - 或者使用更宽泛的过滤条件
tls.handshake.type == 1筛选所有ClientHello包 - 展开包的详细信息树，路径依次为：Transmission Control Protocol → TLS → Handshake → Extension: server_name
- 如果需要批量提取所有SNI域名，可以在Wireshark的“导出对象”菜单中选择“TLS”，即可看到所有明文SNI字段
在Linux服务器上排查网络问题时，还有一个更轻量的工具可用，运行tshark -i eth0 -Y "tls.handshake.extensions_server_name" -T fields -e tls.handshake.extensions_server_name命令，就可以实时输出所有经过网卡的SNI域名,这个操作在实际排障中非常高效。
同一个IP上多个域名的识别对比
大型网站的域名伪装或同IP部署多个业务的情况，往往需要通过SNI来做区分，服务器端识别域名的方式,可以从数据包和配置两个角度来理解：
应用层转发维度，Nginx通过server_name指令区分不同域名的配置块，当请求到达时，Nginx读取HTTP Host头或TLS层的SNI字段，然后匹配对应的server块,这个匹配逻辑决定了某个域名访问时返回的是A应用还是B应用页面。
网络层分析维度，针对同一个IP的访问请求，如果抓包发现SNI字段中包含不同的域名，说明该IP托管了多个网站，利用这个特征，可以判断一个CDN节点背后关联了多少业务,或者哪些域名共享了同一台源站服务器。
常见问题精讲
TLS 1.3的ECH协议能否彻底隐藏域名？
ECH协议确实旨在通过公钥加密SNI字段，解决域名泄露问题，但该协议的部署面临两重阻碍：其一，需要CDN和浏览器厂商同步支持；其二，加密SNI需要特定的DNS扩展记录，而这种记录本身可能被DNS劫持干扰。截至目前，大多数网站和服务端并未启用ECH，传统的明文SNI仍然是主流状态。
如果用户使用IP直接访问网站，SNI里还有域名吗？
如果浏览器地址栏输入的是纯IP地址，那么TLS握手中的SNI字段一般不会被填充，大多数浏览器在这种情况下会选择不发送SNI，导致部分服务器可能返回默认证书，个别情况下，服务器会因缺失SNI而拒绝握手，报错如no suitable server certificate found，这说明SNI字段在当下的HTTPS生态中已不仅是“信息泄露”的问题，更是虚拟主机正常工作的必要条件。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/tcp%e5%8c%85%e5%a4%b4%e9%87%8c%e5%a6%82%e4%bd%95%e8%97%8f%e5%9f%9f%e5%90%8d%e4%bf%a1%e6%81%af%ef%bc%8c%e6%98%af%e4%bb%80%e4%b9%88%e5%8e%9f%e7%90%86%ef%bc%9f/
