Clash TUN 模式原理与开启方法:虚拟网卡如何接管全局流量

TUN 模式与系统代理：接管入口不同

Clash 的系统代理与 TUN 模式解决的是同一个前置问题：应用发出的连接怎样进入内核。系统代理把本机 HTTP 或 SOCKS 代理地址提供给应用；TUN 则创建三层虚拟网络接口，借助操作系统路由，把符合条件的 IP 数据包送入内核。两者都不是节点协议，也不会替代订阅中的代理服务器。

浏览器通常遵循系统代理，但部分游戏、命令行工具和使用自有网络栈的应用不会读取这项设置。此时，即使浏览器已经走代理，其他程序仍可能直连。TUN 不要求这些程序理解 HTTP 代理，不过它的覆盖范围仍受路由、排除项、权限和协议支持限制。

对照项目	系统代理	TUN 模式
接入方式	应用连接本地代理端口	系统路由将 IP 数据包交给虚拟网卡
典型入口	例如本机混合端口 7890	TUN 接口与对应路由，无须应用填写代理端口
UDP 流量	系统 HTTP 代理通常不能覆盖	可接管，但还需出站节点支持 UDP
权限要求	通常只需修改用户代理设置	桌面端需要相应系统权限，Android 需要 VPN 授权
常见影响	不遵循设置的应用绕过代理	可能与其他 VPN、虚拟网卡或路由规则冲突

虚拟网卡、路由与出站连接的工作链路

以一条访问网站的 TCP 连接为例，应用先获得目标 IP，再由操作系统查路由表。启用自动路由后，符合接管条件的数据包进入 TUN 接口；内核读取目标地址与可用的域名信息，按顺序匹配规则，最后建立直连或代理出站连接。

应用发包：应用仍按普通网络连接工作，不必填写 127.0.0.1:7890。
路由选路：内核配置的路由决定哪些地址进入虚拟网卡。物理接口、局域网路由和排除规则同样参与判断。
协议处理：TUN 协议栈处理接收到的 IP 流量，再交给规则与出站模块。
选择出口：命中的策略可能是 DIRECT、拒绝策略或某个代理组，并非固定使用同一个节点。
返回数据：内核把响应送回应用，同时确保代理服务器连接本身能经真实网络出口发出，避免循环进入 TUN。

因此，“TUN 已开启”只能说明入口的一部分配置已生效。节点不可用、代理组选择错误、DNS 超时、出口接口选错，都可能让应用继续报错。排障时应区分虚拟网卡是否创建、连接是否进入内核、最终选择了什么出站，不能只看开关颜色。

DNS 劫持与 fake-ip：保留域名匹配条件

大多数应用先解析域名再连接 IP。如果 DNS 查询完全绕过内核，内核可能只看到目标 IP，域名规则便缺少直接匹配依据。DNS 接管可以让查询进入内核的解析模块，配合缓存映射或其他域名识别机制，为分流提供信息。

端口 53 的接管边界

在 mihomo 的 TUN 配置中，dns-hijack 可指定接管目的端口为 53 的 DNS 流量。any:53 通常用于 UDP DNS，tcp://any:53 用于 TCP DNS。它不是对所有加密解析的通用拦截：应用自带的 DoH 通常经 HTTPS 端口 443 发送，DoT 通常使用端口 853，不会因为配置了 53 端口就自动变成内核 DNS 查询。

fake-ip 不是实际服务器地址

fake-ip 模式会给符合条件的域名返回保留地址段中的映射地址，例如 198.18.0.0/16 范围内的地址。应用连接这个地址后，内核根据映射找回域名，再进行规则判断与实际出站处理。它是本地映射机制，不是远端网站把真实地址改到了该网段。

局域网域名：路由器管理地址、打印机和企业内部服务可能需要真实解析结果。应结合内网 DNS 设置 fake-ip-filter 或域名专用解析策略。
缓存残留：关闭 TUN 后，应用如果继续使用缓存中的 fake-ip 地址，可能暂时无法连接。应重启受影响的应用，必要时刷新系统 DNS 缓存。
浏览器加密 DNS：排障时先临时关闭浏览器自定义安全 DNS，统一解析路径；确认原因后再决定是否保留该设置。
IPv6：IPv4 能通不代表 IPv6 同样被接管。需要同时核对内核、DNS、路由和节点的 IPv6 支持。

mihomo 配置示例：先确认内核，再合并字段

以下片段面向支持相应字段的 mihomo 内核。Clash 是客户端生态中的常用名称，但不同客户端捆绑的内核并不相同，原版 Clash 的不同构建也不能直接套用这份配置。先在客户端的“关于”或运行日志中确认内核名称，再检查客户端是否会通过图形设置覆盖这些字段。

此片段只演示 DNS 与 TUN，不包含节点、代理组和分流规则，不能作为完整订阅直接导入。请合并到现有配置的对应顶层字段，避免出现两个 dns: 或两个 tun:。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query

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

字段	作用与检查点
`listen: 127.0.0.1:1053`	本地 DNS 监听地址。1053 不是代理端口，也不意味着系统会自动使用它。
`stack: mixed`	在支持的 mihomo 构建中组合使用不同协议栈处理 TCP 与 UDP。遇到兼容问题时，可按当前内核文档测试其他栈。
`auto-route`	自动配置接管路由。关闭后通常需要自行维护路由，不适合作为首次排障的默认操作。
`auto-detect-interface`	自动识别出站接口。存在多个活动网卡时仍应核对实际出口。
`default-nameserver`	用于解析 DNS 上游的域名。示例中的上游必须在当前网络可达，不能把示例地址视为所有网络的固定答案。

Windows、macOS、Android 的开启步骤

Windows：先完成服务或管理员权限配置

先保持 TUN 关闭，确认当前订阅能通过系统代理正常访问目标站点。若此时就失败，应先处理节点或订阅问题。
在客户端中查找服务模式、服务安装或权限相关选项。支持后台服务的客户端通常需要先完成一次管理员授权；其他实现可能要求提升客户端权限，以客户端说明为准。
关闭其他 VPN 的自动连接，启用客户端中的“TUN 模式”，检查日志是否出现接口创建、路由添加或 DNS 监听错误。
临时关闭系统代理，再测试普通应用和原本不遵循系统代理的应用，避免把系统代理生效误判成 TUN 生效。

Windows 11 的系统代理可在“设置”→“网络和 Internet”→“代理”中核对。排障时可用 route print 查看路由，用 PowerShell 的 Get-NetAdapter 查看网卡。虚拟网卡名称由客户端决定，不应凭某一个固定名称判断是否成功。

macOS：确认辅助服务授权与网络出口

确认客户端及其内核支持 TUN。按提示安装或授权必要的特权辅助服务，不要把系统代理开关当成 TUN 开关。
启用 TUN 后，检查客户端日志和系统路由。可在终端使用 ifconfig 查看接口，使用 netstat -rn 查看路由。
切换 Wi-Fi、有线网或手机热点后重新测试。若旧出口仍被选中，先重启内核或重新启用 TUN，再核对接口识别结果。

系统代理通常位于“系统设置”→“网络”→当前网络服务→“详细信息”→“代理”。系统中出现 utun 接口本身并不证明它属于当前客户端，因为其他网络服务也可能创建同类接口。应结合开启时间和日志判断。

Android：VPN 授权是流量入口

Android 客户端通常使用系统 VpnService 建立虚拟网络接口。首次连接时会弹出系统 VPN 授权；没有授权就无法建立相应接管路径。它不等于给客户端授予 root 权限，也不代表订阅已成功连通。

导入订阅并选择可用策略，点击客户端的连接按钮，确认系统 VPN 授权。
检查应用分流或绕过列表，确认目标应用未被排除；部分客户端还区分“仅代理所选应用”和“绕过所选应用”。
在系统设置中检查始终开启的 VPN，以及“无 VPN 时阻止连接”一类选项。不同厂商名称不同，这些选项可能阻止其他客户端建立连接。
若熄屏后断连，再检查后台运行和电池优化限制，不要通过反复更换 DNS 掩盖进程被系统停止的问题。

同一 Android 用户或工作资料空间通常只能保持一个活动的 VPN 服务。使用 VPN 接口的防火墙、过滤工具与代理客户端可能互相替换。桌面端 YAML 的 TUN 字段也不一定是 Android 客户端的有效配置入口，应优先使用客户端提供的设置。

TUN 开启后无法联网：按链路逐层排查

建议每次只改一项，并保留修改前的配置。先判断是所有应用失败、只有某个域名失败，还是只有 UDP 功能失败；三种现象对应的排查方向不同。

现象	优先检查	具体操作
开关立即回退或接口创建失败	权限、服务状态、接口冲突	查看首条错误日志，确认服务已启动，暂时停用其他 VPN 后重试。
域名访问失败	DNS 上游与接管路径	检查 DNS 超时日志；使用 `nslookup example.com` 观察系统查询结果，但不要把它当成浏览器解析路径的证明。
网页可用，语音或游戏失败	UDP 出站能力、规则和 MTU	确认节点协议及服务端允许 UDP，先看连接记录，再按当前内核文档调整 MTU。
打印机、NAS 或内网域名不可达	局域网路由与内部 DNS	核对实际网段、直连规则及 TUN 路由排除项，避免把整个内网送到远端节点。
连接出现但出口错误	模式、命中规则、代理组	在连接记录中查看规则及完整策略链，检查是否命中 `DIRECT` 或错误的兜底策略。
关闭 TUN 后仍无法上网	残留代理、DNS 缓存、路由	退出客户端后检查系统代理，重启受影响应用，再检查路由是否恢复。

局域网排除与 DIRECT 不是同一层操作

在规则中给内网地址指定 DIRECT，表示连接进入内核后选择直连；在 TUN 路由层排除网段，则可能让流量根本不进入内核。两者用途不同。企业 VPN 场景尤其需要先了解公司网段和 DNS 下发方式，不宜照抄覆盖所有私有地址的排除清单。

MTU 与双 VPN 冲突放到后面检查

只有部分大响应、上传或特定 UDP 会话卡住时，才值得进一步检查路径 MTU。单纯降低 MTU 无法修复 DNS 不可达或节点失效。两套 VPN 同时修改默认路由时，也可能产生回环或出口漂移；先分别验证两者独立工作，再讨论高级路由组合。

开启后的验证清单与回退方法

确认入口：在系统代理关闭、TUN 保持开启的条件下测试目标应用，并查看连接记录是否出现对应连接。
确认分流：分别访问一个应直连和一个应代理的目标，在记录中核对命中规则与策略链。出口 IP 查询只能辅助验证，不能说明所有应用都被接管。
确认 DNS：检查解析是否成功、是否符合预期的 fake-ip 或真实地址模式，以及内网域名能否正常访问。
确认必要功能：实际测试需要的语音、游戏或其他 UDP 功能。ping 使用 ICMP，结果不能单独证明 TCP、UDP 代理链路正常或异常。
确认恢复：关闭 TUN，检查正常网络是否恢复。Windows 可按需运行 ipconfig /flushdns 刷新系统 DNS 缓存，同时重启持有旧地址的应用。

如果只是浏览器和遵循系统代理的应用需要代理，系统代理通常更便于观察和维护。如果确实需要覆盖不读取代理设置的程序，或需要统一处理 UDP，再启用 TUN，并保留一套已验证的回退配置。稳定配置的判断标准是入口、解析、规则与出口都可解释，而不是开关数量更多。