TCP、UDP、TLS、DNS 与代理连接的关系

开着代理客户端打开一个网页，背后的过程比平时复杂得多：浏览器、客户端内核、代理服务器和目标网站之间，至少会出现两段连接、多次握手，还有一个经常被忽略的问题——域名到底在哪里被解析。很多看似“玄学”的故障，比如全部节点超时、显示已连接却打不开网页、DNS 泄漏检测不通过，其实都能在这条路径上找到对应的位置。

本文以“通过代理访问一个 HTTPS 网站”为例，按时间顺序把每一层拆开，说明 TCP、UDP、TLS 与 DNS 各自负责什么，以及它们与代理协议之间的关系。

全景：一次代理请求的四个阶段

假设你在规则模式下用浏览器访问 https://www.example.com，系统代理指向本地客户端。简化之后，数据会依次经历下面几个阶段：

浏览器 ──(本机回环)──▶ 代理客户端（mihomo / sing-box / Xray 等内核）
   │ ① 匹配规则，决定走代理；确定目标域名在哪里解析
   ▼
客户端 ──② TCP 或 UDP 连接──▶ 代理服务器（入口 / 落地）
   │ ③ 外层 TLS / Reality / 协议自带加密的握手
   ▼
代理服务器 ──④ 新的 TCP 连接 + 浏览器与网站之间的 TLS──▶ www.example.com

先建立一个基本概念：外层连接是设备到代理服务器之间的隧道，内层连接是浏览器与目标网站之间原本就会进行的通信。代理协议负责外层，网站的 HTTPS 负责内层，两者各管一段，互不替代。

阶段一：DNS 解析发生在哪里

DNS 的职责是把域名换成 IP 地址（基础规范见 RFC 1035）。在代理场景中，至少涉及两类域名的解析。

代理服务器自己的域名

订阅里的节点地址经常是域名而不是 IP。客户端要连接节点，必须先在本地解析这个域名，这一步使用客户端配置的 DNS 服务器——在 mihomo 中可以通过 proxy-server-nameserver 单独指定，留空时按普通的 nameserver 规则处理。如果这一步失败，表现就是节点超时，与代理服务器本身是否正常无关。

目标网站的域名

这是讨论“DNS 泄漏”时的重点。目标域名可能在三个位置被解析：

Fake-IP 模式的思路是：内核先给应用返回一个保留网段里的虚拟地址，等应用真正发起连接时，再根据虚拟地址找回原始域名，按域名匹配规则；如果结果是走代理，域名会交给服务器去解析。这样既减少了本地查询，也省去了等待真实解析的时间。

阶段二：TCP 握手连接到代理服务器

决定走代理之后，客户端会与节点的地址和端口建立连接。对于基于 TCP 的协议，这是一次标准的三次握手（SYN、SYN-ACK、ACK，定义见 RFC 9293），大约耗费一个往返时间（RTT）。

这里有两点容易被忽略：

1. 这次握手的对象是代理服务器，而不是目标网站。 节点能完成 TCP 握手，只说明入口端口可达，不代表服务器后面的链路一切正常。
2. TCP 保证数据可靠、有序。 发生丢包时它会重传并降低发送速率；只要前面有一个包没到，后面已经到达的数据也要等着，这就是所谓的队头阻塞。高丢包线路上 TCP 类协议速度明显下降，原因就在这里，详细分析可以阅读 网络延迟、丢包与带宽如何影响实际速度。

阶段三：外层加密与伪装——TLS 与 Reality

TCP 连通后，代理协议开始自己的握手。不同协议在这一层的做法差别很大：

• Trojan 直接使用标准 TLS，服务器需要有效的域名与证书，客户端会校验证书。
• VLESS + Reality：VLESS 本身不加密，由外层的 Reality 负责。服务器在握手中借用一个真实网站的 TLS 特征，因此无需为代理准备自己的证书；客户端则通过预先配置的公钥、短 ID 等参数确认对方身份。
• VMess 与 Shadowsocks 自带加密，不依赖 TLS；VMess 还可以叠加 TLS、WebSocket 等传输方式。

TLS 1.3（RFC 8446）完成一次完整握手通常需要一个 RTT。握手开头的 ClientHello 里，SNI（服务器名称指示）一般以明文发送，这也是各类伪装方案都非常在意 SNI 取值的原因。

阶段四：内层流量——浏览器自己的 HTTPS

外层隧道建立后，客户端把“我要访问 www.example.com 的 443 端口”这一请求连同后续数据一起交给代理服务器。服务器（或最终的落地服务器）再与目标网站建立一条新的 TCP 连接，浏览器随后通过整条隧道，与网站完成它自己的 TLS 握手。

由此可以得出三个结论：

• 访问 HTTPS 网站时，代理服务器知道你要访问的域名和端口，但看不到网页内容；
• 访问 HTTP 明文网站时，外层加密只保护到代理服务器为止，服务器到网站这一段是明文；
• 第一次打开一个网站需要叠加多次握手：外层 TCP、外层 TLS、服务器到网站的 TCP，以及内层 TLS。RTT 越大，“点开后要等一下”的感觉越明显——这就是高延迟节点“打开慢，下载却不一定慢”的原因。

客户端通常会复用已经建立的外层连接，或通过多路复用减少握手次数，具体效果取决于协议与配置。

UDP 与基于 QUIC 的代理协议

UDP 不建立连接，也不保证送达（RFC 768），开销小，适合 DNS 查询、语音通话和游戏这类“宁可丢一点，也不要等”的数据。QUIC（RFC 9000）在 UDP 之上实现了可靠传输、多路复用和连接迁移，并把 TLS 1.3 直接集成到握手中，HTTP/3 就运行在 QUIC 之上。

Hysteria2 与 TUIC 都是基于 QUIC 的代理协议：

• 一条 QUIC 连接中的多个流彼此独立，一个流丢包不会卡住其他流，缓解了 TCP 的队头阻塞；
• Hysteria2 在用户设定带宽时使用名为 Brutal 的拥塞控制，按设定速率发送，不因丢包大幅退让，未设定时则回退到 BBR 等常规算法；TUIC 更强调低握手延迟与原生 UDP 转发；
• 代价是依赖 UDP 的可达性。部分运营商、校园网或公司网络会对 UDP 限速、降低优先级甚至阻断，这时 QUIC 类协议可能比 TCP 类更慢，甚至完全不可用。

另外，“协议基于 TCP”并不等于“不能转发 UDP”。Trojan、VLESS、VMess 都可以把 UDP 数据封装在 TCP 连接中传输，Shadowsocks 则有独立的 UDP 转发方式。玩游戏或进行语音通话时需要节点支持 UDP，选择服务前可以先确认这一点。

常见协议与传输层对照表

表格反映的是常见用法，具体行为会因内核版本和服务端配置而有所不同。

系统时间为什么能让所有节点“同时失效”

时间问题之所以常见，是因为它会同时影响多个层次：

• TLS 证书校验：证书带有生效时间和到期时间。设备时钟快了或慢了很多，客户端会判定证书“尚未生效”或“已经过期”，Trojan 等依赖证书的节点会全部握手失败。
• VMess 的时间校验：VMess 的认证信息包含时间戳，V2Ray 文档要求客户端与服务器的 UTC 时间误差保持在 90 秒以内，超出即被拒绝。
• Reality 等方案：部分服务端也可以配置允许的最大时间差。

判断标准是 UTC 时间，而不是界面上显示的本地时间。如果时区设错了，又手动把时钟调到“看起来正确”，实际的 UTC 时间仍然是错的。最稳妥的做法是开启系统的自动时间同步。遇到所有节点同时超时，可以对照 节点全部超时的排查步骤 逐项检查。

DNS 泄漏常出现在哪些环节

DNS 泄漏指本应交给代理处理的域名查询，被发到了本地网络的 DNS 服务器。常见来源包括：

1. IP 类规则触发本地解析：GEOIP、IP-CIDR 等规则需要 IP，域名请求走到这些规则时，内核会先进行解析。在 mihomo 中，可以给不需要解析的 IP 规则加上 no-resolve，并把常用域名规则放在前面，规则的匹配顺序见 规则模式、全局模式与直连模式的区别。
2. 应用自行解析：通过 SOCKS5 连接代理、但没有启用远程解析的程序，会先在本地查好 IP 再连接代理。
3. 绕过系统代理的程序：不读取系统代理设置的应用会直接使用系统 DNS，TUN 模式配合 DNS 劫持可以接管这部分流量。
4. IPv6 路径：系统启用了 IPv6 而客户端没有正确处理时，部分查询与连接可能直接从 IPv6 出去。
5. 浏览器内置的安全 DNS：浏览器开启 DoH 后会自行发起解析，表现可能与客户端设置不一致。

连接后可以使用 网络检测工具 中的 DNS 泄漏测试确认实际情况；配置层面的问题，可以参考 DNS 与网络配置问题专题。

用命令行观察这几层

下面的命令可以直观看到解析、连接和握手的过程（www.example.com 是保留的示例域名，7897 只是示例端口，请以客户端中的实际端口为准）：

# 查看域名解析结果；第二条指定公共 DNS 服务器做对比
nslookup www.example.com
nslookup www.example.com 1.1.1.1

# 不经过代理：观察解析出的 IP、TCP 连接与 TLS 握手过程
curl -v -o /dev/null https://www.example.com

# 经过本地 HTTP 代理端口
curl -v -o /dev/null -x http://127.0.0.1:7897 https://www.example.com

# 经过 SOCKS5：socks5:// 由 curl 在本地解析，socks5h:// 把域名交给代理端解析
curl -v -o /dev/null -x socks5://127.0.0.1:7897 https://www.example.com
curl -v -o /dev/null -x socks5h://127.0.0.1:7897 https://www.example.com

观察要点：

• 直接访问时，-v 输出会依次显示解析得到的 IP、TCP 连接成功的提示、TLS 握手过程与证书信息，具体格式因 curl 版本和所用 TLS 库而略有差异；
• 通过 HTTP 代理时，可以看到 CONNECT www.example.com:443 这一行，说明交给代理的是域名而不是 IP；
• socks5:// 与 socks5h:// 的差别，正好对应上文“解析位置”表格中的前后两种情形。

Windows PowerShell 中的 curl 默认是另一个命令的别名，请输入 curl.exe 调用系统自带的 curl，并把 /dev/null 换成 NUL。另外，开启 TUN 模式后，即使不加 -x，流量也会被客户端接管，测试前先确认当前状态。

按层定位常见故障

如果遇到的是“客户端显示已连接，但浏览器打不开网站”，可以继续阅读 Clash Verge 连接成功却无法访问的排查方法，按系统代理、规则与 DNS 的顺序逐项确认。