TUN 模式和系统代理选哪个:两种流量接管机制的工作原理对比

先看结论：浏览器优先系统代理，全局接管再开 TUN

系统代理与 TUN 模式并不是两个不同的代理协议，而是两种把本机连接交给 Clash 或 Mihomo 内核的方法。最终是否直连、选择哪个节点，仍由配置中的规则、策略组和当前运行模式决定。两者真正的差异在于流量从哪里进入内核，以及哪些应用会被纳入处理范围。

如果主要需求是浏览网页、使用支持系统代理的桌面应用，先开系统代理通常更合适。它启动快、权限要求低，关闭后也容易恢复。遇到命令行工具、游戏启动器、部分商店客户端、UDP 应用不读取系统代理时，再启用 TUN 模式扩大接管范围。

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

开启系统代理后，Clash 客户端会把操作系统的 HTTP、HTTPS 或 SOCKS 代理地址指向本机监听端口。常见配置使用 mixed-port: 7890，同一个端口可以接收 HTTP 与 SOCKS5 连接；部分旧配置会分别使用 port: 7890 和 socks-port: 7891。这些端口只表示本机应用与代理内核之间的入口，不是远端节点端口。

应用必须主动读取并遵循系统代理设置，连接才会进入 Clash。Chrome、Edge、Safari 以及大量基于系统网络框架的桌面软件通常会这样做。应用连接到 127.0.0.1:7890 后，内核读取目标域名或目标地址，再依据 DOMAIN-SUFFIX、IP-CIDR、规则集与最终规则选择 DIRECT、REJECT 或某个代理策略组。

怎样确认系统代理已经写入

• Windows 11 可打开「设置」→「网络和 Internet」→「代理」，检查手动代理服务器是否指向 127.0.0.1 与客户端显示的端口。
• macOS 可打开「系统设置」→「网络」→当前网络→「详细信息」→「代理」，检查网页代理与安全网页代理项目。
• ClashX 可从菜单栏图标检查「设置为系统代理」状态，同时确认当前配置已启动。
• 使用 Mihomo 图形客户端时，应同时核对「设置」→「Clash 设置」中的混合端口；客户端版本不同，菜单名称可能略有差异。

为什么浏览器能走，终端却不走

curl、Git、npm、pip 等命令行工具对系统代理的处理并不统一。有些版本会读取环境变量，有些需要单独写配置。临时测试可在当前终端设置 HTTP_PROXY、HTTPS_PROXY 与 ALL_PROXY，并明确使用本地端口：

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

curl -I https://example.com

socks5h 中的字母 h 表示让 SOCKS 代理端处理域名解析，能够减少终端先在本地解析域名造成的结果差异。Windows PowerShell 可使用 $env:HTTPS_PROXY="http://127.0.0.1:7890" 为当前会话设置变量。关闭终端后，临时变量不会继续影响新会话。

TUN 模式如何工作：虚拟网卡接收 IP 流量

TUN 模式会创建虚拟三层网络接口，并通过路由表把符合条件的 IP 数据包导向该接口。Mihomo 内核读取数据包中的源地址、目标地址和传输协议，恢复连接信息后再执行代理规则。应用看到的仍是普通网络连接，因此不必理解 HTTP 或 SOCKS 代理，也不必主动读取系统代理设置。

这也是 TUN 能覆盖更多程序的原因。采用自有网络栈的游戏启动器、忽略系统代理的命令行程序，以及使用 UDP 的应用，都有机会进入 TUN 接管路径。不过，“开启 TUN”等于“所有数据一定走远端节点”并不准确：局域网地址、排除路由、DIRECT 规则、进程规则以及客户端设置都会改变最终路径。

Mihomo 的基础 TUN 配置

mixed-port: 7890
mode: rule

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

dns:
  enable: true
  enhanced-mode: fake-ip
  listen: 0.0.0.0:1053
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query

auto-route 用于自动添加必要路由，auto-detect-interface 尝试识别实际出站网卡，dns-hijack 则把匹配的 53 端口 DNS 请求交给内核 DNS 模块。stack: mixed 是 Mihomo 常用选择，会结合系统栈与用户态处理能力。不同系统、内核版本及客户端可能支持 system、gvisor 或 mixed，不能把其他内核的同名选项直接照搬。

生效范围对比：TCP、UDP、局域网与进程识别

TCP 与 UDP 的差异

系统 HTTP 代理主要面向基于 TCP 的 HTTP 与 HTTPS 连接。SOCKS5 本身可以扩展处理 UDP，但前提是应用明确支持 SOCKS5 UDP 转发；操作系统的普通“网页代理”开关不会自动把所有 UDP 数据交给 SOCKS 端口。语音、实时游戏、QUIC 与部分 DNS 请求因此可能绕过系统代理。

TUN 在 IP 层看到 TCP 与 UDP，更适合需要统一处理两种传输协议的场景。即便如此，远端节点协议也必须支持相应的 UDP 转发，策略组中的实际节点还要启用 UDP 能力。若日志显示 UDP 连接命中规则后仍失败，应继续检查节点协议、服务端配置与网络 MTU，而不是只反复切换 TUN 开关。

局域网设备与私有地址

打印机、NAS、路由器后台常使用 192.168.0.0/16、10.0.0.0/8 或 172.16.0.0/12。开启 TUN 后应保留局域网直连规则，并确认自动路由没有把这些网段导向错误接口。常见规则可以放在代理规则之前：

rules:
  - 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
  - MATCH,PROXY

如果企业内网也使用这些私有地址，仅靠网段直连还不够，还要确保公司 VPN 接口的路由优先级正确。出现“公网正常、内网域名打不开”时，应先比较开启 TUN 前后的路由表，而不是直接修改代理节点。

进程规则的可靠性

TUN 模式下，内核可在受支持的平台尝试识别发起连接的进程，并匹配 PROCESS-NAME 或 PROCESS-PATH。但进程识别受系统权限、应用沙盒、子进程模型和内核实现影响。浏览器网络服务可能运行在独立进程中，容器流量也可能只显示宿主侧进程。关键分流仍建议以域名、IP 与规则集为主，进程规则作为补充。

DNS 处理对比：域名在哪一步被解析

系统代理场景中，DNS 行为取决于应用和代理类型。浏览器可能自行启用加密 DNS，也可能先向操作系统解析，再连接解析后的 IP；SOCKS5 客户端则可选择把域名交给代理。若域名在进入 Clash 前已经变成 IP，内核可能只能依据目标 IP 匹配，域名规则的可见性会受到嗅探与映射状态影响。

TUN 常与 Mihomo DNS 模块、DNS 劫持和 Fake IP 一起使用。Fake IP 模式会从保留地址段返回临时地址，例如默认常见的 198.18.0.0/16，随后根据映射关系还原原始域名。这样可以在应用只发起 IP 连接时继续执行域名规则，并减少本地解析路径与代理路径不一致的问题。

Fake IP 不等于远端 DNS

Fake IP 是本机内核维护域名映射的机制，真正向上游查询时仍要看 nameserver、proxy-server-nameserver、规则 DNS 与当前代理配置。节点服务器域名本身还需要可用的解析链路，否则会形成“需要先连节点才能解析节点地址”的循环依赖。

• 网页出现证书域名错误时，检查 DNS 是否被其他软件改写，以及 Fake IP 映射是否仍有效。
• 局域网设备无法通过主机名访问时，可把相关域名加入 Fake IP 过滤列表，或为局域网域名配置专用 DNS。
• 应用内置 DoH 时，普通 53 端口劫持不一定能接管该查询；应检查浏览器的安全 DNS设置与规则命中情况。
• 休眠恢复后大量域名短暂失败，可先重载配置并刷新操作系统 DNS 缓存，再判断是否需要重建 TUN 接口。

权限、兼容性与性能开销怎么比较

权限要求

系统代理通常只需要修改当前用户的网络代理设置。TUN 则要创建虚拟网卡、调整路由表或调用系统网络扩展，因此 Windows 可能需要管理员授权，macOS 可能要求批准网络扩展或辅助服务，Linux 通常需要 CAP_NET_ADMIN、root 权限或由 systemd 为进程授予对应能力。

权限只应授予当前确认来源与版本的客户端。若 TUN 开关点击后立即回落，先查看客户端服务状态与内核日志；若提示创建接口失败，再检查系统权限。反复重装配置文件通常不能解决驱动、服务或能力授权问题。

与 VPN、虚拟机和容器共存

企业 VPN 与 TUN 都可能创建虚拟接口并写入默认路由。后启动的软件可能改变路由优先级，造成连接回环、内网中断或流量从错误网卡发出。常见处理顺序是先连接企业 VPN，再启动 Clash TUN，并通过 auto-detect-interface 或客户端的接口选项确认实际出口。若公司策略不允许改路由，改用系统代理更稳妥。

WSL2、Docker Desktop、Parallels 与 VMware 会维护自己的虚拟网段。宿主机 TUN 不一定自动覆盖虚拟机内部的全部流量，虚拟机也可能把宿主机视为网关。需要分别检查宿主系统、虚拟网卡和来宾系统的默认路由，不能只根据宿主浏览器结果判断。

性能开销看具体环境

TUN 会增加一次虚拟接口收发、协议栈处理和规则判断，理论路径比应用直接连接本地代理端口更长，但日常网页中的差距通常小于远端节点延迟。以下数据是固定环境下的对照样例，不代表所有设备：Windows 11 24H2、Mihomo 1.19.8、Ryzen 7 7840U、有线千兆网络，在同一节点与规则下连续测试 10 次。

这个样例中 TUN 首包增加约 0.8 ms，下载吞吐下降约 4.2%，但远端节点负载、加密协议、网卡卸载与 MTU 都可能造成更大波动。低功耗设备更应关注连续传输时的 CPU 与温度，而不是只看一次测速峰值。

按步骤选择并排查：不要同时改多个开关

方案一：先验证系统代理

1. 启动客户端并加载配置，确认本地混合端口为 7890 或界面显示的实际值。
2. 选择规则模式，先把测试域名对应的策略组固定到一个可用节点。
3. 打开系统代理，用浏览器访问测试页面，同时观察连接日志是否出现域名和策略名称。
4. 若浏览器正常，再分别测试终端、商店客户端或目标应用，记录哪些程序没有进入日志。
5. 只有确实存在覆盖缺口时，关闭系统代理测试项并启用 TUN，避免两条路径同时存在干扰判断。

方案二：启用 TUN 后检查四个位置

1. 查看日志中是否成功创建 TUN 接口，是否出现权限、路由或设备占用错误。
2. 检查默认路由和实际出口接口，确认没有把代理服务器连接再次送回 TUN 形成回环。
3. 检查 DNS 日志，确认查询进入 Mihomo DNS 模块，并能匹配预期的域名规则。
4. 分别测试 TCP、UDP、局域网地址与休眠恢复，不能只以单个网页打开作为完成标准。

常见现象与对应处理

最终选择：按应用范围而不是按“模式强弱”

系统代理更适合明确支持代理设置的浏览器与桌面应用。它对路由表影响较小，适合作为日常默认方案，也方便快速判断节点和规则是否正常。终端工具若只偶尔使用，可以单独设置环境变量，不必因此长期启用 TUN。

TUN 更适合需要覆盖 UDP、忽略系统代理的程序、复杂 DNS 分流或希望统一接管多类应用的场景。它带来的不是节点速度提升，而是更完整的流量入口；相应地，也需要处理权限、虚拟网卡、DNS 和路由冲突。

实际配置可以采用“系统代理常开，TUN 按需”的策略。首次部署先把系统代理、节点选择和规则命中跑通，再启用 TUN 扩展范围。出现问题时按流量入口、DNS、路由、规则、节点能力的顺序逐层检查，比在全局模式、规则模式和多个开关之间来回切换更容易找到原因。