代理上网的原理：从客户端到出口节点，一次访问经历了什么

先说结论

一次代理访问可以拆成六个环节：接管流量 → 分流判断 → 域名解析 → 协议封装 → 入口与线路 → 出口访问。前四个环节发生在你的设备上，由客户端负责；后两个发生在机场的网络里。目标网站只和出口节点直接通信，所以它看到的是出口 IP；而一次访问快不快、稳不稳，取决于这六个环节里最差的那一个。

本文是“代理与网络原理”专题的主文章，按顺序把每个环节讲清楚，并给出各环节的延伸阅读。这里默认你已经导入过订阅、用过客户端；如果机场、节点、订阅这些概念还不熟，可以先看 机场是什么。

六个环节一览

第一步：流量怎么进入客户端

客户端装好之后并不会自动“接管网络”，必须由操作系统把流量交给它。方式有两种。

系统代理。 客户端在本机开一个代理端口（Clash Verge Rev 默认是 7897），再把操作系统的代理设置指向这个端口。浏览器等遵守系统代理设置的程序，会把请求发到这里。访问 HTTPS 网站时，浏览器发给代理的是一条 CONNECT 请求，RFC 9110 规定它的目标写法就是“主机名:端口”，例如 CONNECT www.example.com:443。也就是说，客户端从一开始拿到的就是域名，浏览器自己不需要先查 DNS。

TUN 模式。 客户端创建一块虚拟网卡并修改路由表，让所有程序的 IP 流量都先经过它，程序不需要任何配合。代价是，交到客户端手里的已经是发往某个 IP 的数据包——程序在连接之前已经自己做过一次 DNS 查询。

这个差别看起来很小，却决定了后面域名解析要怎么处理。两种方式各自覆盖哪些程序、什么时候该开 TUN、开启时要注意什么，见 TUN 模式和系统代理有什么区别。

第二步：按规则决定直连还是代理

流量进入客户端后，内核对每个连接从上到下逐条匹配规则，命中第一条就按它处理。处理结果只有三种：直连（DIRECT）、交给某个代理组、拦截（REJECT）。下面是一个说明结构的例子：

rules:
  - DOMAIN-SUFFIX,example.com,节点选择   # 按域名后缀匹配，不需要解析
  - GEOIP,CN,DIRECT                     # 按目标 IP 的归属地匹配，需要知道 IP
  - MATCH,节点选择                       # 兜底：前面都没命中的走代理

规则可以粗分为两类：

• 按域名匹配（DOMAIN、DOMAIN-SUFFIX、GEOSITE 等）：只看域名，不需要解析；
• 按 IP 匹配（IP-CIDR、GEOIP 等）：需要知道目标 IP。mihomo 文档说明，一个只有域名的请求走到 IP 类规则时，内核会触发一次 DNS 解析来检查是否匹配，在规则末尾加 no-resolve 可以跳过这次解析。

所以规则文件通常把域名规则放在前面：大部分请求在域名阶段就能分完，不必为了分流专门查一次 DNS。规则、全局、直连三种模式怎么切换，自定义规则写在哪里，见 Clash 使用教程。

第三步：域名在哪里解析

这是代理原理里最容易被误解的一段。“把域名换成 IP”这件事，可能发生在你的设备上，也可能发生在出口节点上。

本地解析

直连的请求在本地完成 DNS 查询，再直接连接查到的 IP，这没有问题。但如果走代理的请求也先在本地解析、再把 IP 交给节点，会带来两个麻烦：

1. 查询记录留在本地网络。 你要访问哪些境外域名，会以 DNS 查询的形式发给本地网络的 DNS 服务器，这就是常说的 DNS 泄露；
2. CDN 地址可能不合适。 大型网站普遍使用 CDN，会按查询者的位置返回最近的服务器。在本地解析，拿到的是“离你近”的地址，出口节点去连它可能要绕远路，甚至连不通。

远程解析

更合理的做法是把域名本身交给出口节点，由它在当地解析。代理协议普遍支持这样做：以 SOCKS5 为例，RFC 1928 规定请求中的地址类型可以是 IPv4、IPv6 或域名（类型值 X’03’）；机场常用的 Shadowsocks、VMess、VLESS、Trojan 等协议同样可以直接携带域名。系统代理模式下，客户端从 CONNECT 请求里拿到的就是域名，天然适合远程解析。

fake-ip：在 TUN 模式下把域名“找回来”

TUN 模式的难点是：程序连接之前已经查过 DNS，客户端收到的只有 IP。为了仍然按域名分流、仍然把域名交给出口，客户端会接管系统发出的 DNS 查询（DNS 劫持），并用 fake-ip 的方式应答：

1. 程序查询 www.example.com，客户端不真正解析，而是从一个保留网段里分配一个假地址返回，同时在内存中记下“这个假地址对应这个域名”；
2. 程序向假地址发起连接，数据包经虚拟网卡进入客户端；
3. 客户端查表把假地址还原成域名，再按域名匹配规则：需要代理的，把域名交给节点远程解析；需要直连的，再在本地做真实解析。

这个思路并不新。2001 年发布的 RFC 3089 就描述过类似的“DNS 解析委托”：用一段“从不用于真实通信的保留地址”临时代表域名，连接时再换回域名交给网关。mihomo 文档示例配置里的 fake-ip 网段是 198.18.0.1/16，它落在 IANA 登记为网络基准测试专用的 198.18.0.0/15 范围内，正常的互联网通信不会用到。

mihomo 还提供 redir-host 模式（文档注明它是默认值）。这种模式向程序返回真实 IP，客户端再借助 DNS 查询时留下的映射记录，以及“域名嗅探”（从 HTTP、TLS、QUIC 流量中读出域名）补回域名信息。机场提供的订阅一般已经写好了 DNS 配置，普通用户不需要自己改。

第四步：协议层负责加密与伪装

分流和解析之后，需要代理的请求要按节点使用的代理协议“打包”，再发往节点。协议在这一步做三件事：

• 认证：证明你是这个节点的合法用户，凭据（密码、UUID 等）就写在订阅里；
• 加密：让途中的网络设备看不到你要访问的域名和传输的内容；
• 伪装：让这条连接的外观接近某种常见流量，例如普通的 HTTPS 网站访问或 HTTP/3。

各协议的取舍不同：Shadowsocks 追求简单、开销小；Trojan 和 VLESS + REALITY 让连接看起来像标准 TLS；Hysteria2 建立在 QUIC（UDP）之上。协议主要影响“能不能稳定连上”和额外开销，一般不决定带宽上限。五种主流协议的完整对比见 代理协议怎么选。

还要分清加密保护的范围：协议的加密覆盖的是你的设备到出口节点这一段。出口节点解开协议后，再以普通方式访问目标网站。如果目标是 HTTPS 网站，网页内容在浏览器和网站之间另有一层 TLS，节点能知道你连接的域名，看不到网页内容。

第五步：入口、中转与出口

机场的一个“节点”，通常不是一台服务器，而是一条路径：

• 入口：客户端实际连接的地址。直连节点的入口就是海外服务器本身；中转和专线节点的入口在国内；
• 中转与线路：入口到出口之间的那一段。普通中转经过公共国际出口，IPLC、IEPL 专线则走私有的跨境链路；
• 出口（落地）：最终替你访问目标网站的服务器，决定你“看起来在哪里”。

很多中转节点的入口只做转发：把收到的数据原样交给出口，协议层的加密和解密仍在你的客户端与出口服务器之间完成。也正因为如此，晚高峰最容易拥堵的跨境段，质量完全取决于机场买的是什么线路。专线为什么更稳、为什么更贵，见 IEPL 是什么。

第六步：为什么目标网站看到的是出口 IP

TCP 连接是两台机器之间的直接连接。在代理链路里，和目标网站建立连接的是出口节点，你的设备与入口、中转之间的连接，目标网站完全看不到。由此有几个直接结果：

• 网站按出口 IP 判断访问者所在的国家或地区，页面语言、内容版权范围、服务是否开放都以此为准；
• 一个出口 IP 往往由许多用户共用，网站看到的是“很多人从同一个地址访问”；
• 出口 IP 属于哪类网络（数据中心或家庭宽带），也是一些网站判断访问来源的参考。

有一个例外容易被忽略：被规则判定为直连的请求，以及根本没有进入客户端的程序，用的仍然是你本地的 IP。所以“开了代理”不等于所有流量都从出口出去了。

AI 服务对访问地区有明确的支持范围，选择出口时的一般原则见 AI 稳定机场怎么选。无论使用哪个出口，都应遵守对应服务的使用条款。

用这条链路定位问题

理解了六个环节，遇到问题时就可以先判断出在哪一段，再对症处理：

“延迟测试很低、速度却上不去”是另一类常见困惑，它涉及延迟、带宽和丢包三者的关系，单独见 机场延迟低为什么速度还是慢。

总结

代理上网是一条六段的链路：系统代理或 TUN 把流量交给客户端，规则决定去向，域名尽量交给出口节点解析，协议负责加密和伪装，机场的入口、线路和出口负责把请求送到目标网站。目标网站只看得到出口 IP；体验好不好，取决于链路上最弱的一环。遇到问题时按环节逐段排查，比反复换节点更有效。