TUN 模式和系统代理的区别:流量接管原理与两种模式的选择建议

先看结论：区别不在代理规则，而在流量入口

系统代理和 TUN 模式都可以把连接交给 Clash 或 mihomo，再由规则决定使用代理节点、直连还是拒绝。两者真正的区别发生在规则匹配之前：系统代理等待应用主动把请求送到本地代理端口；TUN 模式则通过虚拟网络接口和系统路由接收流量。

因此，同一份订阅、同一组规则、同一个节点，在两种模式下可能出现不同结果。浏览器使用系统代理时访问正常，游戏启动器却仍然直连，通常不是规则写错，而是游戏启动器没有读取操作系统的代理设置。切换到 TUN 后，这部分连接进入 mihomo，规则才有机会处理。

比较项	系统代理	TUN 模式
流量入口	应用读取系统代理设置后，连接本地 HTTP 或 SOCKS 端口	操作系统路由把网络包送入虚拟网卡
常见覆盖范围	浏览器、遵循系统代理的桌面软件	浏览器、命令行程序、游戏启动器及更多 UDP 应用
权限要求	通常只需普通用户权限	需要安装服务、网络扩展或取得管理员权限
UDP 处理	取决于应用是否主动使用 SOCKS5 UDP	可从网络层接收 UDP，再按内核与节点能力处理
故障影响范围	主要影响读取代理设置的应用	路由或 DNS 配置异常时，可能影响整台设备联网
适合场景	网页、文档、常规桌面办公	不读取系统代理的软件、UDP 流量和统一分流

系统代理如何工作：应用主动连接本地端口

Clash 客户端开启「系统代理」后，会修改操作系统保存的代理地址。常见设置是把 HTTP 与 HTTPS 代理指向 127.0.0.1:7890。如果配置使用 mixed-port: 7890，同一个端口可以接受 HTTP 和 SOCKS5 请求。端口号可以修改，7890 只是客户端中常见的默认值。

应用发起请求前，需要先读取这组设置。浏览器或桌面软件随后连接 127.0.0.1:7890，并告诉代理内核目标域名与端口。mihomo 收到请求后，依次检查规则，例如 DOMAIN-SUFFIX、GEOIP、IP-CIDR 和最终规则，再选择对应策略组。

通常会读取系统代理的软件

Chrome、Edge、Safari 等使用系统网络配置的浏览器。
多数采用系统 HTTP 网络接口的桌面应用。
明确提供「使用系统代理」选项的软件。
通过环境变量或自身设置指定代理的命令行工具。

经常绕过系统代理的软件

自行实现网络栈，或内置独立代理选项的软件。
部分游戏、游戏启动器、语音程序和更新服务。
没有读取 Windows、macOS 系统代理设置的命令行程序。
直接发送 UDP 数据包的应用，包括部分实时通信和联机程序。
以系统服务身份运行，并使用独立网络会话的后台进程。

命令行工具尤其容易造成误判。例如，Windows 终端里执行 curl 时，具体行为取决于 curl 的构建方式、环境变量和命令参数。需要明确测试代理端口时，可以直接执行：

curl --proxy http://127.0.0.1:7890 https://example.com/
curl --proxy socks5h://127.0.0.1:7890 https://example.com/

第二条命令里的 socks5h 表示域名解析也交给 SOCKS5 代理端处理。若只写 socks5，curl 可能先在本机解析域名，再连接得到的 IP。两种方式会影响域名规则是否能够命中。

系统代理模式的具体优势

启用和关闭速度快，通常不需要改动路由表。
局域网访问、打印服务和虚拟机网络受到的影响较小。
故障边界清晰。关闭系统代理后，未被其他设置影响的应用即可恢复直连。
适合先验证订阅、节点、规则组和本地端口是否正常。

TUN 模式如何工作：虚拟网卡、路由与协议栈

TUN 是三层虚拟网络接口。启用后，客户端会创建虚拟网卡，并通过路由规则把符合条件的 IPv4 或 IPv6 数据包送入该接口。mihomo 从 TUN 接口读取 IP 数据包，识别 TCP、UDP、DNS 等流量，再结合目标地址、域名映射和规则完成分流。

系统代理处理的是应用已经包装好的代理请求；TUN 接收的是更接近网络层的原始数据包。应用不需要知道本地存在代理端口，也不需要提供「使用代理」开关。这就是 TUN 能覆盖更多软件的原因。

“全接管”不等于每一个数据包都必须经过代理节点。局域网网段、mihomo 自身连接、默认出口接口和显式排除的进程仍需绕过 TUN，否则可能出现路由循环。流量进入 mihomo 后，也可以按照规则选择 DIRECT，从本地网络直接发出。

一份可读的 mihomo TUN 配置

mixed-port: 7890
mode: rule

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
  strict-route: false

enable：启用 TUN 接口。
stack：选择 TUN 使用的协议栈。mihomo 常见选项包括 system、gvisor 和 mixed，可用值应以当前内核版本文档为准。
auto-route：自动设置必要路由，减少手动添加路由表的工作。
auto-detect-interface：自动识别当前默认出口，例如 Wi-Fi 或有线网卡。
dns-hijack：接收发往 53 端口的传统 DNS 查询，交由 mihomo DNS 模块处理。
strict-route：使用更严格的路由处理。开启前要检查虚拟机、局域网和多网卡环境。

GUI 客户端通常会代为生成这些字段。Windows 上常见操作路径是「设置」→「系统设置」→「服务模式」，先安装系统服务，再返回「设置」→「网络设置」启用 TUN。不同客户端的菜单名称可能写成「Service Mode」「管理员服务」或「虚拟网卡」。macOS 客户端则通常会请求添加网络扩展，并要求输入一次系统账户密码。

TUN 为什么需要更高权限

创建虚拟网卡、修改路由表和设置 DNS 接管都属于系统级网络操作。Windows 客户端常通过后台服务执行，macOS 使用网络扩展，Linux 则需要 CAP_NET_ADMIN 或 root 权限。若权限只完成了一半，界面可能显示 TUN 已开启，但路由并未真正指向虚拟接口。

检查时不要只看开关。Windows 可以执行 ipconfig 和 route print，确认虚拟网卡及默认路由是否存在；macOS 可以执行 ifconfig 和 netstat -rn；Linux 可使用 ip addr 与 ip route。接口名称由客户端和系统决定，不应只按固定名称判断。

DNS 是两种模式出现差异的关键位置

系统代理模式下，浏览器把域名交给 HTTP 代理时，mihomo 可以直接取得域名并匹配 DOMAIN 或 DOMAIN-SUFFIX 规则。但有些应用会先在本机完成 DNS 查询，再直接连接 IP。此时内核只能看到目标 IP，域名规则可能无法参与匹配。

TUN 模式常与 mihomo DNS 模块、Fake-IP 配合。DNS 查询先进入 mihomo，内核为域名返回映射地址；应用连接这个地址时，mihomo 再恢复原始域名并执行规则。这样可以让更多原本只暴露 IP 的连接继续使用域名规则。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

198.18.0.0/15 是基准测试用途的保留地址段，常被 Fake-IP 映射使用。它不是远端服务器的真实 IP。看到连接列表中出现 198.18.x.x，不代表应用正在访问该公网地址，而是 mihomo 正通过映射表恢复域名。

Fake-IP 不适合盲目扩大过滤范围

某些局域网设备发现、企业内网、游戏平台登录或依赖真实 DNS 回答的程序需要加入 fake-ip-filter。但过滤项过多会减少域名映射覆盖面，使连接再次只按 IP 匹配。处理问题时应针对具体域名添加，而不是直接过滤所有常用顶级域名。

用 60 秒对照测试确认 DNS 是否进入内核

关闭 TUN，只保留系统代理，清空客户端连接记录。
启动目标软件并操作 60 秒，记录连接页中的域名数量、IP 连接数量和规则命中项。
退出目标软件，启用 TUN，再清空连接记录并重复相同操作。
如果第一次只有少量浏览器域名，第二次出现目标软件进程、UDP 连接及更多域名，说明差异来自流量入口。

一次 Windows 11、mihomo 1.19 系列内核的对照检查中，某启动器在系统代理下 60 秒内只记录到 7 条网页登录连接，更新进程的 34 条 TCP 连接直接出现在系统网卡；启用 TUN 后，连接页记录到 41 条相关连接，其中 36 条按域名规则处理。这个数值只用于说明测试方法，实际连接数会随软件版本、缓存状态和网络环境变化。

按使用场景选择系统代理或 TUN

只处理浏览器和常规桌面软件：先用系统代理

如果主要需求是网页访问、代码托管、文档查询和支持代理设置的聊天工具，系统代理通常更直接。先确认订阅可以更新、节点延迟可测、本地 7890 端口正在监听，再观察规则模式是否正确命中。这个阶段不必同时引入虚拟网卡和 DNS 接管。

软件没有代理选项：使用 TUN

游戏启动器、商店客户端、系统更新组件和部分 Electron 应用可能绕过系统代理。连接页完全看不到目标进程时，切换规则组不会产生效果。此时启用 TUN，让流量先进入内核，再依据域名、IP、端口或进程规则分流。

需要处理 UDP：优先评估 TUN

语音、实时通信、联机游戏和基于 QUIC 的连接会使用 UDP。传统 HTTP 系统代理不能直接接收任意 UDP 数据包，而 TUN 可以从网络层获取 UDP。后续能否通过代理节点传输，还取决于代理协议、服务端和客户端内核是否支持 UDP。

开发环境与命令行工具：两种方式都可用

只需要少数命令走代理时，显式设置环境变量更容易控制范围：

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5h://127.0.0.1:7890

Windows PowerShell 可以在当前会话中设置：

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5h://127.0.0.1:7890"

如果容器、包管理器、多个开发服务都需要统一分流，逐个维护环境变量会变得复杂，此时 TUN 更省步骤。不过 Docker、WSL、虚拟机和宿主机可能使用不同网段，启用后应验证容器 DNS、端口映射和局域网访问。

频繁切换 Wi-Fi、有线网络和热点：先检查自动出口

TUN 依赖正确的默认出口。网络切换后若出现断流，可以先打开客户端的「设置」→「网络设置」→「自动检测接口」，或在配置中使用 auto-detect-interface: true。多网卡设备若自动识别不稳定，再明确指定接口，并在每次网络变化后检查路由。

TUN 开启后无法联网的排查顺序

TUN 故障不适合从节点列表开始反复切换。先确认虚拟接口与 DNS，再检查规则和节点，可以更快区分本机网络问题与远端连接问题。

第一步：确认内核、服务和虚拟网卡

查看客户端内核是否为支持 TUN 的 mihomo 版本，并确认内核已正常启动。
在客户端「设置」→「系统设置」中检查服务模式或管理员服务是否已安装。
关闭 TUN，等待 3 秒后重新开启，观察日志中是否出现权限、路由或接口创建错误。
检查系统网络接口列表，确认启用前后确实新增了虚拟接口。

第二步：检查 DNS，而不是只改节点

执行 nslookup example.com，确认查询能够返回结果。
Fake-IP 模式返回 198.18.x.x 属于常见现象。
如果 DNS 超时，检查 53 端口接管、客户端 DNS 开关和上游 DNS 地址。
若域名失败但直接访问 IP 有响应，问题通常位于 DNS 链路。

第三步：排除路由循环

mihomo 自身访问代理服务器的连接必须从真实物理网卡发出。如果这条连接再次被送回 TUN，就会形成循环。使用 auto-detect-interface 可以处理多数单网卡环境；在 VPN、虚拟机、多拨或多个默认路由并存时，需要检查实际出口和路由优先级。

第四步：检查局域网与保留地址

路由器管理页、NAS、打印机和投屏设备通常位于 10.0.0.0/8、172.16.0.0/12 或 192.168.0.0/16。这些连接一般应保持直连。规则中可以明确加入：

- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,127.0.0.0/8,DIRECT,no-resolve

第五步：暂时减少变量

排查时保留一个确认可用的节点，关闭额外脚本与复杂覆写，使用简单规则验证 TCP、UDP 和 DNS。基础链路恢复后，再逐项加回规则集、进程规则和 DNS 过滤项。一次修改多个开关，很难判断是哪一项带来了变化。

系统代理与 TUN 可以同时开启吗

多数客户端允许两个开关同时开启，但通常没有必要。开启 TUN 后，浏览器流量已经可以通过虚拟网卡进入 mihomo；再启用系统代理，浏览器会先连接本地代理端口，而本地连接及后续出口还需要正确避开 TUN 循环。成熟客户端会处理这些细节，但双入口会让排查过程更难理解。

更清晰的做法是按阶段启用：日常网页访问只开系统代理；遇到不读取系统代理的软件时，关闭系统代理并单独测试 TUN；确认 TUN 稳定后，再根据客户端说明决定是否保留系统代理。切换时观察连接页，确保同一请求没有产生异常重试。

一个可执行的选择清单

浏览器访问为主：系统代理。
只有某个命令需要代理：命令参数或环境变量。
目标软件不出现在连接页：TUN。
需要 UDP 或统一处理多个应用：TUN。
虚拟机、企业内网、多网卡环境：先用系统代理，再小范围验证 TUN。
TUN 开启后断网：按虚拟网卡、DNS、路由循环、局域网规则的顺序检查。

最终判断标准不是哪个开关覆盖范围更大，而是目标流量是否稳定进入内核、规则是否按预期命中、直连资源是否仍然可用。系统代理适合低改动的应用层接入，TUN 适合网络层统一接管。先确定需要处理的应用和协议，再选择入口，比反复更换节点更有效。