原理进阶 预计阅读 12 分钟

Clash TUN 模式详解:虚拟网卡接管全局流量的原理与开启步骤

讲清 TUN 与系统代理的区别、虚拟网卡如何接管不走代理设置的程序流量,以及服务模式安装、DNS 劫持与开启后的验证方法。

TUN 与系统代理的区别

浏览器能访问，命令行工具却超时；网页正常，游戏或桌面程序仍然直连。这类现象先看流量入口，不要急着换节点。Windows 系统代理只是告诉愿意读取该设置的程序：把请求交给指定的 HTTP 代理。程序不读取系统代理，连接就不会因为那个开关而自动进入 Clash。

TUN 则在网络层增加一张虚拟网卡，配合路由把符合接管条件的 IP 数据包送入内核。程序不必认识 HTTP 代理，也不必提供代理设置入口。内核收到流量后，再按规则决定直连、代理或拒绝。

比较项系统代理TUN 模式
接入位置应用读取代理设置后主动连接监听端口。系统路由把流量送入虚拟网卡。
常见用途浏览器、遵循系统代理的桌面软件。不读取系统代理的程序，以及需要接管的 UDP 流量。
权限要求设置本机代理通常不需要安装系统服务。通常需要有权限的后台服务或提升权限运行的内核。
处理范围取决于应用是否采用代理配置。取决于路由、接口、地址排除项和协议支持。

虚拟网卡如何接管连接

可以把一次连接拆成四步。先确认数据有没有进入内核，再看命中了什么规则，最后才判断节点性能。只看到虚拟网卡出现，并不能证明接管已经完成。

  1. 程序发起请求。程序向目标 IP 发送 TCP 或 UDP 数据；如果使用域名，还会先进行名称解析。
  2. Windows 选择路由。客户端启用自动路由后，会添加相应路由，使目标流量进入 TUN 接口。更具体的路由、排除地址和其他 VPN 都可能影响结果。
  3. 内核识别并匹配规则。通过 DNS 映射等信息获得域名，结合域名、IP 或进程规则选择策略。不能恢复域名时，域名规则未必能命中。
  4. 建立实际出站连接。直连流量从物理网卡发出；代理流量通过所选节点转发。客户端需要避免把自身出站再次送回 TUN，形成循环。

因此，TUN 不是把物理网卡替换掉。Wi-Fi、以太网仍负责实际联网，虚拟网卡负责把指定流量交给内核处理。节点不支持 UDP 时，打开 TUN 也不会凭空补出 UDP 转发能力；游戏、语音和 QUIC 是否可用，还要看节点协议、服务端配置及网络环境。

开启前：客户端与服务模式

先建立可用的基础连接

  • 导入可信来源的订阅，在客户端选中实际使用的配置，而不是仅下载订阅文件。
  • 进入代理组，手动选定一个节点；先用系统代理验证浏览器能正常建立连接。
  • 记下当前监听端口。常见示例为 7890，但应以客户端实际值为准，不要把别人的端口直接套用。
  • 暂时退出其他 VPN、加速器和另一套代理客户端，避免多套虚拟网卡同时修改路由。
  • 保存原配置、DNS 设置与现有 VPN 信息。远程连接中的电脑不要贸然切换路由，优先在本机操作。

服务模式不是 TUN 开关

在旧版 Clash for Windows 中，服务管理入口通常位于 General → Service Mode 旁的齿轮按钮。打开管理窗口后，使用其中的 Install 安装服务，并按提示完成 Windows 权限确认。不同归档版本的按钮位置与状态文字可能不同，找不到时先核对所用版本，不要反复安装来源不明的驱动。

服务模式解决的是后台进程执行特权操作的问题，TUN 开关控制的是虚拟网卡接管。安装服务成功后，仍需确认服务正在运行，再开启 TUN Mode。两者不能互相替代，也不意味着必须长期把整个图形界面以管理员身份运行。

使用其他客户端时，应在其设置中查找“服务模式”“系统服务”或“TUN 模式”的实际入口。不要为了照搬旧版界面教程而降级。若安装服务时报错，先记录完整错误和内核日志，检查权限、安全软件拦截记录及旧服务残留，不要直接关闭系统安全防护。

mihomo TUN 配置与 DNS 劫持

下面是面向 mihomo 的字段示意片段，不是可以单独导入的完整订阅。它没有节点、代理组和分流规则，不能替代现有配置。旧版 Clash for Windows 不一定支持其中所有字段；客户端若由界面生成 TUN 与 DNS 设置，应优先使用界面或其覆写功能，避免订阅更新后丢失修改。

mode: rule
mixed-port: 7890

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

关键字段分别解决什么问题

  • auto-route：让内核自动设置接管所需路由。仅创建网卡而没有正确路由，程序流量仍可能绕过它。
  • auto-detect-interface：尝试自动识别出站接口。多网卡、企业 VPN 或同时使用有线与无线时，仍需检查日志中的实际出口。
  • stack: mixed：在 mihomo 中使用混合协议栈。协议栈支持与实现取决于内核版本，遇到特定程序兼容问题时再按文档比较其他可用选项。
  • dns-hijack：把进入接管范围、发往指定端口的 DNS 流量交给内置 DNS。这里分别列出 UDP 53 与 TCP 53，并不代表能识别所有加密 DNS。
  • listen: 127.0.0.1:1053：让内置 DNS 监听本机回环地址的 1053 端口。它不是把 Windows DNS 服务器地址填写成带端口的字符串。
  • fake-ip：为域名分配合成地址，帮助内核把后续连接对应回域名。示例地址池是 198.18.0.1/16，它不是节点地址。

示例中的两个上游是普通 DNS 地址，只用于展示字段结构，不代表适合所有网络或提供加密解析。实际部署还要考虑上游可达性、节点域名解析、分流解析和企业内部域名。需要这些设置时，继续查阅配置参考，不要把演示片段当成通用最佳配置。

为什么 DNS 会影响规则命中

域名规则需要域名信息。应用自行完成加密解析，或者使用旧缓存直接连接 IP 时，内核未必能获得预期的域名映射。发往 53 端口的 DNS 劫持不能自动覆盖 HTTPS 上的 DoH 或 TLS 上的 DoT。浏览器的安全 DNS、程序内置解析器和 Windows 加密 DNS设置，都可能改变实际解析路径。

排查时可暂时关闭测试应用的自定义安全 DNS，使用系统解析做对照，测试完再恢复。不要仅凭一次解析结果认定“DNS 泄漏”，也不要把所有域名解析到 fake-ip 当作成功标准。局域网设备名、企业内部域名和少数特殊应用，可能需要按客户端文档配置例外与专用上游。

开启步骤：一次只改一个变量

  1. 确认基础代理可用。保持规则模式，选择一个已验证可连接的节点。此时先不开 TUN，确认订阅与节点本身没有问题。
  2. 安装并启动服务。在客户端服务管理入口完成操作，确认状态正常。如果服务启动失败，先解决权限或残留服务，不要继续叠加配置。
  3. 开启 TUN。观察日志是否出现权限不足、接口创建失败、路由添加失败或 DNS 端口占用等错误。出现错误时先关闭 TUN，保留日志。
  4. 关闭系统代理做隔离测试。这一步用来判断接管是否来自 TUN，不是说两者不能同时开启。否则浏览器成功可能只是仍在使用 HTTP 代理。
  5. 重建测试连接。完全退出并重新打开测试程序，或重新发起请求。长连接和旧 DNS 缓存可能保留开启前的路径。
  6. 检查连接详情。在客户端连接列表中查看目标、规则与策略链。验证完成后，再按日常需求决定是否保留系统代理。

如果只是浏览网页，系统代理已满足需求，就不必为了“覆盖更广”而强行启用 TUN。增加接管层意味着也要处理局域网发现、企业网络、睡眠恢复和多网卡切换等兼容问题。

Windows 验证：网卡、路由与连接记录

验证不要只看开关颜色。依次检查虚拟接口、路由变化和实际连接，三项互相印证。下面命令用于观察状态，不会主动修改网卡或删除路由。

第一步：查看接口与路由

打开 PowerShell，分别在关闭和开启 TUN 时运行以下命令。比较新增接口和路由，不要假定虚拟网卡一定叫某个固定名称。

Get-NetAdapter -IncludeHidden |
  Format-Table Name, InterfaceDescription, Status, ifIndex

Get-NetRoute -AddressFamily IPv4 |
  Sort-Object InterfaceIndex, DestinationPrefix |
  Format-Table DestinationPrefix, NextHop, InterfaceIndex, RouteMetric

Get-DnsClientServerAddress -AddressFamily IPv4

新增接口是线索，不是结论。TUN 可能通过多条路由覆盖地址范围，不一定表现为一条熟悉的默认路由。还要留意其他 VPN 的更具体路由。若实际流量使用 IPv6，仅查看上面的 IPv4 输出也不足以证明已完整接管。

第二步：绕过显式代理发起请求

在系统代理已关闭的前提下，执行下面的请求。--noproxy "*" 用于让 curl 不使用显式代理，包括环境变量指定的代理；它不会绕过操作系统的 TUN 路由。

curl.exe --noproxy "*" -I --connect-timeout 10 https://example.com/

返回 HTTP 响应只能证明这次请求成功，不能单独证明走了代理，因为目标也可能直连可达。立即打开客户端的连接列表，按目标域名或地址查找该请求，确认命中的规则以及最终的 DIRECT 或节点策略。如果请求太快消失，可同时查看客户端日志；是否记录连接取决于日志设置。

第三步：验证真正需要接管的程序

重新启动原先不走系统代理的程序，执行一次联网操作，再看它是否进入连接列表。浏览器测试不能替代游戏 UDP 测试；TCP 请求成功也不能证明语音通道可用。需要确认远端出口时，使用可信的出口查询服务，并与连接详情对照，不能只凭网页显示的地区判断整个系统。

对 IPv6 也应单独验证。检查客户端的 IPv6 与路由设置、系统是否获得 IPv6 地址，以及目标是否使用 AAAA 记录。不要在未测试时宣称所有 IPv6 都已接管，也不要把全局关闭 IPv6 当作默认修复动作。

常见故障与排查顺序

现象优先检查下一步操作
TUN 开关自动回落服务状态、权限、接口创建错误。记录第一条错误，确认服务运行，再检查旧虚拟接口或安全软件记录。
开启后域名全部失败内置 DNS 是否启用、上游是否可达、监听端口是否冲突。核对 1053 等实际端口，检查解析日志，先恢复一组可用上游。
有连接但始终直连模式、规则顺序、代理组选择。查看连接命中的具体规则，确认不是 Direct 模式或前置直连规则。
网页正常，游戏失败UDP 支持、节点服务端、游戏自身网络限制。验证对应 UDP 连接，不要仅依据延迟测试结果判断。
打印机或 NAS 无法访问局域网路由、DNS 与广播发现。对比直接访问设备 IP；按实际网段配置绕过，检查其他 VPN 的路由。
退出客户端后断网残留系统代理、服务状态、DNS 与路由是否恢复。先正常关闭接管和服务，再检查系统代理，避免直接删除全部网络设置。

局域网问题要分层处理。把某个私有地址段设为 DIRECT，只改变进入内核后的出站策略，并不等同于让该地址段完全绕过虚拟网卡。依赖广播、多播或特殊发现协议的设备，还可能需要路由排除。网段必须按实际网络填写，不能假定所有家庭网络都是 192.168.1.0/24。

DNS 修改后仍命中旧结果，可在保存必要信息后运行 ipconfig /flushdns 清理 Windows DNS 缓存，再重启测试应用。它不会清理所有浏览器内部缓存，也不能修复错误的上游或路由。不要把连续执行网络重置命令当作排障流程。

关闭与回退检查

测试失败时，先关闭 TUN，再通过客户端正常退出或停止相关服务。到 Windows 11 的“设置 → 网络和 Internet → 代理 → 手动设置代理”检查是否仍留着本机代理；Windows 10 可在“设置 → 网络和 Internet → 代理”中检查相应开关。若原来由单位配置代理，不要覆盖单位设置。

  • 确认停用接管后，普通网页和局域网设备恢复到测试前的状态。
  • 如果手动修改过 DNS，恢复记录下来的原值，不要一律改为自动获取。
  • 再次查看接口与路由，确认没有另一套 VPN 或代理仍在接管。
  • 提交问题时附上系统版本、客户端与内核版本、报错时间及已脱敏日志，删除订阅地址、访问令牌与节点凭据。

判断 TUN 是否配置正确，最终看三件事：需要接管的程序确实进入内核，连接命中了预期规则，退出后网络能正常恢复。把入口、DNS、规则和出站分开验证，比反复切换节点更容易定位问题。

下载客户端