TUN 模式下的
分流与 DNS 劫持之道

互联网的本质，是把电信号从 A 点送到 B 点。所以第一个真正的问题永远是：A 和 B 在哪？后面所有关于代理、分流、DNS 的讨论，本质上都是围绕这个朴素问题展开。在我们正式讲 TUN 之前，必须先把这本「数字世界的地址簿」翻清楚——否则后面所有的黑魔法都看不到根基。

IP：互联网的门牌号

每一台连接互联网的设备都需要一个唯一的地址，就像每一栋楼都有门牌号。这个地址叫 IP 地址 (Internet Protocol Address)。它工作在网络分层中的第三层（网络层 / L3），所有上层协议（TCP/UDP、HTTP、Socks……）最终都要装进 IP 包里才能上路。

IP 有两个版本，今天的互联网两个版本同时在用：

IPv4 早在 2011 年就分完了。过去十几年靠 NAT（家用路由器把多个内网设备共享同一个公网 IP）勉强续命。但根本解决方案是 IPv6——它的地址多到「这辈子用不完」的程度。

今天的网络是 双栈 (Dual-Stack) 状态：绝大多数主流服务（Google、Cloudflare、Apple……）同时部署 v4 和 v6，你的设备也通常同时拿到两种地址。当你访问一个网站时，浏览器会同时尝试 v4 和 v6（这个算法叫 Happy Eyeballs），哪个先建立 TCP 就用哪个。

这件事对代理用户极其重要：如果你的代理只接管了 v4 流量，那 v6 流量就会绕过代理直接出去，俗称「IPv6 漏代理」。我们会在第 6 章把这个隐患单独拎出来讲。

地址的「特殊段位」：不是所有 IP 都对等

你可能以为 IPv4 的 43 亿个地址都是平等的——其实远远不是。IANA（互联网号码分配机构）在切蛋糕时，划出了一大堆保留段，每段都有特殊使命：有的留给内网用、有的指向本机、有的纯粹是给文档示例。你在这份讲义后面看到的所有「IP 黑魔法」——为什么 192.168.x 不能进代理、为什么污染常返回 127.0.0.1、为什么 Fake-IP 选 198.18 这个怪段位——根都在这张表里。

这些段位看似抽象，但每一段都在我们后面的故事里有重大戏份：

IPv6 也有完全对应的一套：::1/128 是 v6 版的环回（相当于 v4 的 127.0.0.1）；fe80::/10 是链路本地（只在同一个网段内有效，永远不出本机）；fc00::/7 是 ULA（Unique Local Address，v6 版本的「RFC 1918 私有段」）—— 第 6 章里 IPv6 Fake-IP 用的 fc00::/18 正是这个母段的子集。

把这张「段位表」记进脑子里，你看任何代理工具的 rules 规则表都会突然开窍——开头那一排 IP-CIDR 不是装饰，每一行都对应这张图上的一个保留段，作用是把本不该出本机的流量拦截在隧道之外。这就是一份正经代理配置的「兜底之手」。

DNS：把名字翻译成 IP

人脑记不住 IP——你能记住几个像 142.250.179.196 这样的数字？所以我们用名字：baidu.com、twitter.com、anthropic.com。

这就引出第二个问题：怎么从名字找到 IP？这正是 DNS (Domain Name System) 干的事——它是一本分布式、层级化的全球电话本。注意「分布式」三个字：没有任何一台机器存了全世界所有域名，整个系统是按层级分散在几十万台服务器上的。

当你输入 www.example.com，幕后真实发生的过程，比你想象的要绕得多：

几个值得知道的细节：

• 记录类型：A 记录把域名映射到 IPv4 地址，AAAA 记录映射到 IPv6（名字来源：A 的 4 倍，4 字节 vs 16 字节）。还有 CNAME（别名）、MX（邮件）、TXT（任意文本）等。
• TTL (Time To Live)：每条记录都有一个有效期，常见 300 秒到 1 小时不等。TTL 期内递归解析器会用缓存，过期才重新爬层级。这是为什么改了 DNS 要等几小时才生效。
• 「递归解析器」 是整套系统的劳模。8.8.8.8（Google）、1.1.1.1（Cloudflare）、114.114.114.114（中国某 ISP 联盟）都是常见的公共递归解析器。你 PC 上配的 DNS 服务器，绝大多数情况就是指它。

DNS 的命门：为什么这本电话本会被改写

DNS 是 1983 年设计的协议。那年代网络上没什么坏人，所以设计极度天真——四个致命特征：

1. 用 UDP 协议（端口 53）——速度优先，没有连接握手
2. 无状态、无认证——你发问，谁先回答你就信谁
3. 完全明文传输——内容人人可见
4. 「第一个应答就算数」——后到的应答会被丢弃

这些设计在今天看来个个都是漏洞。任何能在网络路径上看到你 DNS 包的设备（运营商、机房、ISP 中转节点……）都可以「抢答」——在真正的 DNS 服务器回应之前，先伪造一个错误的应答塞给你。这就是 DNS 污染 (DNS Pollution / DNS Spoofing)。

GFW 的污染战术

GFW 在中国出境网络节点上部署了庞大的「检测 + 注入」设备。看到一个 UDP 53 端口的查询时，会判断域名是否在敏感清单上（如 google.com、twitter.com、facebook.com）：

• 不去拦截你的查询包——让它继续流向真 DNS 服务器（这样你和真 DNS 都不会察觉）
• 同时伪造一个 DNS 应答，源 IP 写成你查询的那个 DNS（比如 8.8.8.8），抢在真正应答之前发回来
• 伪造应答里的 IP 通常是 0.0.0.0、127.0.0.1，或某个无意义的境内 IP
• 你的设备拿到这个假 IP 去连接，连接当然失败——但 DNS「查到了」结果，不会重试

值得注意的是：这个攻击对 IPv6 的 AAAA 记录同样有效——所以你不能指望「我用 IPv6 就没事了」。GFW 对 v4 v6 一视同仁。

对抗：加密 DNS 的崛起

业界过去十年发明了一堆「加密 DNS」协议来对抗污染，核心思路是：让监听设备看不到你在问什么，自然就无法抢答。

代理工具都内置了对这些的支持——这就是为什么 Clash / sing-box 配置里你能看到 https://dns.cloudflare.com/dns-query 这种字符串。

到这里你已经具备了理解所有 TUN / 代理黑魔法的基础语言：IP 是地址，地址有「公网/私有/保留」之分，DNS 是名字翻译机，DNS 容易被污染，IPv6 是不可忽视的第二条路径。
带着这些武器，我们正式进入代理的世界。

你打开 Clash，第一眼看到两个开关：系统代理和 TUN 模式。教程会让你打勾，但很少有人告诉你它们差在哪。其实这是两套截然不同的世界观——它们工作的「楼层」根本不同。

要理解这件事，先回忆一下网络分层。从下往上：物理层 → 数据链路层 → 网络层（IP） → 传输层（TCP/UDP） → 应用层（HTTP/HTTPS/Socks）。流量从应用发出，每经过一层就被「贴一张标签」（封装），最后变成一串电信号发出去。

系统代理：在「门口」拦人

系统代理工作在应用层。它本质上是在操作系统里挂了一个公告：「以后所有 HTTP/HTTPS/Socks 请求，都先发给 127.0.0.1:7890，那里是我们的代理软件。」于是浏览器、curl、Postman 这些认这个公告的程序，会乖乖把请求送过去。

问题：不是所有程序都认这个公告。很多游戏、Telegram、Steam、命令行小工具、各种系统服务，它们要么不读系统代理设置，要么用的是 UDP（系统代理只管 TCP 的 HTTP/Socks），要么直接走原生 socket。这些流量就「绕开了」代理，俗称漏代理。

TUN 模式：在「楼底」截胡

TUN 模式工作在网络层（L3）。代理软件创建一块虚拟网卡（叫 utun0 或 Meta），然后修改系统路由表，把「默认路由」指向这块假网卡。结果是：整台机器所有出网的 IP 包，无论是 TCP/UDP/ICMP、无论哪个程序发的，全部经过代理软件。

代理软件收到的是裸的 IP 包（有源 IP、目的 IP、协议号、载荷），而不是 HTTP 请求。它要自己重组 TCP 流、自己解析 DNS、自己决定每一个包是直连还是入隧道——相当于代理软件自己成了「半个内核」。

那么 TUN 是不是万能？——并不

这正是后面三章存在的理由。当代理软件在 L3 接管全部流量后，它失去了应用层的语义信息——拿到一个 IP 包，它不知道这是哪个域名、属于哪个网站、该走国内直连还是走代理。这就埋下了 TUN 模式独有的三大难题：

所以你看到的所有「TUN 黑魔法」——DNS 劫持、SNI 嗅探、Fake-IP——本质上都是在给 L3 层重新装回 L7 的语义信息。这就是这份讲义剩下三章要讲的事。

第 1 章我们讲过：DNS 协议自身就脆弱——明文、无认证、谁先回应谁算数。在裸的国内网络环境下，这种脆弱表现为「污染」；而一旦你开了 TUN 模式，它会被放大成另一种更暴力的失败模式。这一章就是这个故事。

TUN 模式开启之后，整台机器所有的出网流量都要先「报备」给代理软件。这里有个看似无害但实际致命的细节：DNS 查询，也是流量。

你访问 www.baidu.com 的时候，发生的第一件事不是连百度——而是先发一个 UDP 包到 114.114.114.114:53，问它「百度的 IP 是多少」。这个 UDP 包，在 TUN 模式下，同样会被那块 utun0 虚拟网卡抓走。

如果你不告诉代理软件「DNS 服务器必须直连」，会怎样？

代理软件看到一个去 114.114.114.114:53 的 UDP 包，它不认识这个 IP，也没规则说它应该直连，于是按默认规则——送进海外代理隧道。

下面这张图把这条死亡链路画出来了。你可以点「开始播放」一步步看：

三种典型的「DNS 死法」

把图上的失败路径展开说，你日常遇到的所有「开 TUN 后国内网络瘫痪」基本都是这几种之一：

解决方案：DNS 流量必须「强制直连」+ 由代理自己接管

所有现代代理工具的标准操作有两步：

1. 对一切 DNS 服务器 IP（53 端口、DoH/DoT 端口）声明「绕过 TUN 直连」——告诉代理软件「这些包不要抢，让系统自己发」。
2. 代理软件自己内置一个 DNS 解析器，所有应用查询的域名先交给代理软件回答，由它根据规则决定「这个域名应该问国内 DNS 还是问海外 DNS」。这条规则在 Clash 配置里叫 dns.nameserver / fallback / fallback-filter，在 Sing-box 里叫 dns.servers + dns.rules。

这就是为什么任何一份正经的 Clash/Sing-box 配置，开头几十行总是在写 DNS 规则。它不是装饰，是续命设置。

上一章解决了「我自己查 DNS」的场景。但现实里，并不是所有应用都老老实实通过系统 DNS 解析——很多流量到达 TUN 时，根本就没有「域名」这条线索。具体来说有这么几种典型情况：

• App 内置了 DoH——浏览器（Firefox、Chrome）和 iOS / Android 上越来越多的应用，自己用 HTTPS 直接问 Cloudflare 或 Google DNS，完全跳过系统 DNS 模块。代理软件根本看不到这个查询。
• 硬编码 IP 直连——很多游戏服务器、P2P bootstrap 节点、IoT 设备的回调地址，把 IP 写死在客户端里，从来不查 DNS。
• WebRTC / 实时通话——拿到对端候选 IP 后直接发 UDP，全程不经过域名解析。
• 推送系统——服务端把目标 IP 通过其他通道（如 push notification）推过来，客户端拿到就连。

这些情况下，代理软件在 utun0 看到的只是一条裸 IP 连接，比如 TCP → 142.250.179.196:443。这是 Google？是国内某 CDN？是某个游戏？——只看 IP，没有任何线索。这一章就讲代理软件怎么在「无域名」的劣势条件下，还能做出准确的分流决策。

分流的第一道防线：GeoIP 二进制字典

代理软件本地会带一份叫 geoip.dat 的二进制文件，里面是各个国家/地区的 IP 段汇总（CN、US、JP、HK……）。看到 IP 后第一步：查这个 IP 属于哪个国家。

这一步解决了大部分场景：114.114.114.114 属于 CN，那就直连；142.250.x.x 属于 US，那就走代理。完事。

但 GeoIP 不够用——同一个 IP 可能代表完全不同的服务

Cloudflare、Akamai、Google 都用任播 (Anycast)。同一个美国 IP，可能服务的是 Discord，也可能是 Twitter、Tumblr。你想代理 Twitter 但不想代理 Discord——只看 IP 办不到。

这时候就用到了代理软件最神奇的一招：流量嗅探（Traffic Sniffing）。

嗅探：拆开 TLS 握手包，从明文里偷域名

关键事实：HTTPS 在握手阶段是明文的。

你访问任何 HTTPS 网站，TCP 连接建立后的第一个包叫 Client Hello，里面写着「我想和 twitter.com 这台服务器握手」——这个字段叫 SNI (Server Name Indication)。它必须是明文，因为服务端要根据 SNI 决定用哪张证书。

代理软件抓住这点，在转发流量之前先暂停一下，拆开 TCP 流的前几个包，找到 Client Hello，提取出 SNI 字段。一瞬间，「一条裸 IP 连接」就变成了「一条去 twitter.com 的连接」——L7 信息凭空回来了。

除了 TLS SNI，还能嗅什么？

嗅探在 Clash.Meta / sing-box 配置里通常叫 sniffer / sniff。打开它，你的分流准确率会显著提升——尤其对那些「自己查 DNS」的应用。

但嗅探也有代价：每条连接都要先缓存一小段、解析一下，再放行。这会带来几毫秒到几十毫秒的延迟。所以大多数工具默认只对 443/80 端口开启嗅探。

嗅探解决了不少问题，但还有一类硬骨头啃不下来——应用查 DNS 这件事本身是慢的。

想象一下：你点开 Twitter 链接，浏览器先发 DNS 查询，DNS 包要往返代理隧道，国外 DNS 解析 + 回程，整个 DNS 解析可能要 200~500ms。这段时间页面是白屏的。如果 DNS 走得不顺（DNS 污染、超时、上游故障），可能直接卡死。

于是有人想出了一个鬼才方案：既然查 DNS 这么麻烦，那我干脆不查真的，先随便给一个假 IP 让你赶紧连上来，等你连上来我再慢慢搞清楚你想干什么。这就是 Fake-IP。

Fake-IP 的核心思想：用「假地址 + 内部账本」换速度与可控

代理软件在内部预留一段 本不会出现在公网的 IP 段——正是第 1 章段位表里那个「IANA 自留地」：198.18.0.0/15（RFC 2544 基准测试保留段，全球路由表里永远不会出现）。这就是 Fake-IP 整套机制能站住脚的物理基础。

当应用问「twitter.com 的 IP 是？」，代理软件做以下几件事：

1. 0.001ms 内立刻吐出一个假 IP，比如 198.18.0.42。不查任何上游 DNS。
2. 把这条映射记到一本「账本」里：198.18.0.42 ⇄ twitter.com。
3. 应用拿到假 IP 后立即发起连接：TCP → 198.18.0.42:443。这个包当然又被 TUN 抓住了。
4. 代理软件一看目的 IP 在 198.18/15 段——这是我的假 IP！反向查账本：找到这是 twitter.com。
5. 有了真域名，再走规则判断：twitter 走代理，传送门打开。

下面这张图把整个生命周期演示出来——这是 Fake-IP 最值得反复看的一张图：

它为什么是「降维打击」？

对比这三种模式你就懂了：

Fake-IP 的额外妙处

• 彻底告别 DNS 污染：本机根本不发 DNS 出去，没法被污染。
• 分流绝对精准：账本里直接存着真域名，每一条连接都带域名标签，不用嗅探不用 GeoIP 兜底。
• 不会有 DNS 死循环：DNS 查询本身被代理软件本地应答，根本不会跑去隧道里转圈。
• 资源极轻：账本是一个 LRU 哈希表，几万条映射常驻内存毫无压力。

它也不是完美无瑕

现在回头看这四章，其实它们讲的是同一件事的四个层面——代理软件在 L3 接管流量后，如何一步一步把 L7 的语义信息「找回来」，以便做出正确的分流决策。

第六块拼图：IPv6 双栈下的隐形陷阱

前面五章的逻辑都默认了「IP」是 IPv4。但回想第 1 章——你的设备其实是双栈的，每次连接都在 v4 / v6 之间做选择。这就埋下了几个独立于前面所有讨论的隐形陷阱：

换句话说：本讲义的每一招（DNS 直连、嗅探、Fake-IP）都要在 v4 和 v6 上各做一遍。一旦遗漏了某一边，整套防线就有一个洞。这是新手最容易踩、却最难自己排查的坑。

三句话总结

• TUN 模式 = 在 L3 接管全部流量，代价是丢掉 L7 语义。
• DNS 直连 + 嗅探 + Fake-IP = 三种逐步精准地把 L7 语义找回来的方法。
• 所有代理软件做的事都一样，区别只在「这三件事各自做得有多好、配合得有多顺滑」。