目录

暗夜里的窥探:Windows TUN 模式下的 DNS 泄露溯源

为什么开了代理,运营商依然对你的行踪了如指掌?

夜里三点,书房里只有显示器幽暗的光。

一切看起来都很完美。Clash 运行在后台,TUN 虚拟网卡模式已开启,所有的流量理应被妥当地接管、加密,然后安静地穿透那堵高墙。但在关机前,我鬼使神差地打开了 BrowserLeaks 网页。

屏幕上跳出的结果让我瞬间清醒:在几十个海外 DNS 节点中,赫然夹杂着几个极其扎眼的国内运营商 DNS IP。

这就意味着,即便在全局代理的假象下,我的每一次域名请求,都在被运营商默默记录。系统在暗处,开了一扇我不常察觉的窗。

1. 裂缝初现:完美代理的错觉

问题是怎么出现的?其实它一直都在,只是被表象掩盖了。

在过去的几个月里,网络访问出奇地顺畅。无论是流媒体的加载速度,还是终端里的 git clone,TUN 模式都展现出了它强大的全局接管能力。它在系统里创建了一张虚拟网卡,强制所有软件的流量走入这条隧道。

但那次偶然的 DNS 泄露测试打碎了这种错觉。浏览器并没有报错,目标网站也正常加载,可检测工具无情地指出了一个事实:部分 DNS 解析请求,根本没有走隧道。

/2026/03/21/windows-tun-mode-dns-leak-investigation/images/01-illusion.webp
看似严丝合缝的代理,实则暗藏裂缝

2. 惯性怀疑与误导的表象

最开始我怀疑了什么?和大多数人的第一反应一样,我认为是 Clash 的分流规则(Rules)写错了,或者是 GeoIP 数据库太旧导致国内外的域名判断失误。

我花了一个小时重新梳理了 yaml 配置文件,把 match 规则和 dns 字段里的 fallback 配置翻来覆去地改。我还怀疑过是不是浏览器的 DoH(DNS over HTTPS)在捣鬼,于是把所有浏览器的内置安全 DNS 统统关闭。

但这些表象其实全是误导。

因为当我打开控制台查看实时日志时,发现规则匹配是完全正确的,代理软件确实收到了流量。可那个国内运营商的 DNS 依然幽灵般地出现在测试结果里。配置没有错,代理软件本身也没有错。错误发生在流量进入代理软件之前

3. 锁定关键证据

既然软件没问题,那就是操作系统的行为。

我打开了抓包工具,清空系统 DNS 缓存(ipconfig /flushdns),然后发起一次新的网络请求。数据包的流向立刻暴露了真相。

我看到了关键证据:当我在浏览器里敲下回车的那一瞬间,系统并没有老老实实地只把 DNS 请求发给虚拟网卡,而是同时向物理网卡(连接着家用路由器的网卡)和虚拟网卡发送了 UDP 的 53 端口请求。

就像一个人在路口迷了路,他不是找一个最靠谱的向导,而是同时向周围所有人大喊。

4. 真正根因:Windows 的“聪明”机制

真相浮出水面。这一切的罪魁祸首,是 Windows 10/11 系统自带的一个特性:智能多宿主名称解析(Smart Multi-Homed Name Resolution, SMHNR)

微软设计这个机制的初衷是好的。在现代设备中,我们经常同时连着 Wi-Fi 和有线网,或者连着公司内网的 VPN。为了让你以最快速度打开网页,Windows 会并行地向所有可用的网络接口发送 DNS 查询请求,谁先返回结果,就用谁的。

当我们在系统中开启代理软件的 TUN 模式时,其实就是多出了一张虚拟网卡。 于是,当你访问被墙的网站时,Windows 为了追求“效率”,把这个极其敏感的域名同时发给了:

  1. TUN 虚拟网卡(被加密,送往海外服务器)
  2. 本地的真实物理网卡(无加密,直接送给国内运营商)

物理网卡的请求是明文的。这就是为什么运营商依然能精准地记录你的浏览痕迹——即便最终的网页数据是通过代理隧道传回来的,但你推开那扇门前的一句问询,已经被听得一清二楚。

5. 最终修复方案:斩断多余的触角

找到了病因,手术就非常明确了。我们需要强行关闭 Windows 的这种“自作聪明”。

这里不需要去动代理软件的配置,而是要修改系统底层的策略。

对于专业版/企业版 Windows:

  1. 按下 Win + R 输入 gpedit.msc 打开组策略编辑器。

  2. 导航至:计算机配置 -> 管理模板 -> 网络 -> DNS 客户端

/2026/03/21/windows-tun-mode-dns-leak-investigation/images/02-investigation.webp
`计算机配置` -> `管理模板` -> `网络` -> `DNS 客户端`

  1. 找到 关闭智能多宿主名称解析(Turn off smart multi-homed name resolution)。

  2. 将其状态改为 已启用 (Enabled)

/2026/03/21/windows-tun-mode-dns-leak-investigation/images/03-rootcause.webp
禁用智能多宿主名称解析

对于家庭版 Windows(或者更直接的方式),直接修改注册表:

# 以管理员身份运行 PowerShell 执行以下命令:
Set-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient" -Name "DisableSmartNameResolution" -Value 1 -Type DWord

注:如果路径不存在,可以手动在注册表中新建相应的项和 DWORD 值。

执行完成后,重启电脑。 再次打开 BrowserLeaks,那些扎眼的国内节点终于彻底消失了。世界安静了下来。

/2026/03/21/windows-tun-mode-dns-leak-investigation/images/04-resolution.webp
修改策略,重建秩序

6. 写在最后:经验与反思

这次排查最值得记住的经验是什么?

是**“永远不要把信任完全托付给上层应用,因为底层可以轻易将其架空”**。

我们习惯于在软件 UI 里寻找安全感:看到绿色的“Connected”,看到全局模式的图标,就以为隐私得到了庇护。但技术是一个层层叠加的系统,操作系统作为最底层的仲裁者,它的默认策略往往偏向于“连通性”和“效率”,而非“绝对隐私”。

真正的安全和控制感,来源于对数据流向的清晰认知。遇到灵异现象,不要急于推翻自己写好的配置,往下看,看底层的网络协议,看操作系统的原生逻辑。

夜深了,屏幕上的流量图平稳地跳动着。合上电脑前,我知道,这次的隧道,才算是真正挖通了。


“同频之人,终会相遇;同行之路,终有光亮。”

若你有故事想讲、有困惑想聊、或是想找个人说说心里话,甚至只是吐槽发泄一下情绪,都欢迎来找我聊聊:

希望我写的每一个字,成为我自己和某个人活下去、拼下去的力量。

“技术终归是工具,而我们一次次认真把问题理顺,守住的其实不只是页面样式和代码输出,还有那一点不愿被混乱打败的心气,是每一个深夜仍愿点灯前行的人。”

「码艺轩・以技立身,实干谋生」系列 · 持续更新

本文采用 CC BY-NC-SA 4.0 许可协议,转载请注明来自:https://oklife.me。

文尾配图水墨画图片