Clash TUN 模式与系统代理的区别:流量接管范围和适用场景

先选接管方式，再检查分流规则

浏览器日常访问先用系统代理；应用不读取代理设置、需要接管 UDP，或希望统一处理多类应用时，再考虑 TUN 模式。两者解决的是“流量怎样进入内核”，并不直接决定流量最终直连还是走节点。

使用 mihomo 内核时，可以把一次连接拆成三步：先进入代理端口或 TUN 虚拟网卡，再匹配规则，最后交给直连出口或某个代理节点。入口、规则和出口是三个独立环节。只切换入口，不一定改变规则命中结果。

“接管全部流量”是对 TUN 使用目标的概括，不是无条件保证。路由排除、其他虚拟网卡、IPv6 配置、应用绑定网卡以及客户端实现，都可能影响实际覆盖范围。节点自身连接还需要正确绕过 TUN，避免形成回环。

系统代理：应用主动连接本地代理端口

系统代理怎样工作

开启客户端的“系统代理”后，客户端通常会修改操作系统的代理设置，指向本机监听地址，例如 127.0.0.1:7890。读取这套设置的应用会把请求交给该地址；忽略设置的应用仍按原来的网络路径连接。

7890 在本文中只是配置示例，不是所有客户端的固定端口。先到客户端设置页核对“混合端口”或“HTTP 端口”。如果页面显示其他值，命令和应用代理设置也必须同步替换。不要把控制接口端口当作代理端口。

• 浏览器：通常可以读取系统代理，但浏览器内的单独代理设置可能覆盖系统设置。
• 命令行工具：不保证读取桌面系统代理，可能需要代理参数或环境变量。
• 游戏与实时通信：原生 UDP 通信通常不会因为打开 HTTP 系统代理就自动进入内核。
• 自行实现网络连接的应用：可能绕过系统代理，也可能只让登录页面走代理，主连接仍然直连。

用显式代理确认端口可用

下面的命令明确要求请求经过本地 HTTP 代理。Windows 终端可使用 curl.exe，避免部分终端环境中的同名命令产生歧义；其他系统通常使用 curl。

curl --head --proxy http://127.0.0.1:7890 https://clash67.com/

执行后查看客户端连接记录。能看到目标域名和规则命中，才说明该请求确实进入内核。返回状态码只反映该站点当时的响应，不能证明所有网站都可访问；这个测试也不能证明系统代理开关已经正确写入操作系统，因为命令已经显式指定了代理。

TUN 模式：通过虚拟网卡和路由接管连接

TUN 是三层虚拟网络接口。客户端创建接口并配置路由后，符合路由条件的 IP 数据包进入内核处理。应用不必主动理解 HTTP 或 SOCKS 代理，因此 TUN 更适合覆盖不遵守系统代理设置的程序。

这种接管通常需要更高的系统权限。桌面客户端可能通过后台服务或提权进程设置网卡与路由；安卓客户端常通过系统 VPN 授权接管选定应用的流量。不同平台的实现和开关名称并不完全相同，不能把桌面端参数机械地套到手机上。

mihomo 的 TUN 配置示例

以下片段展示常见入口参数，不包含节点、策略组和完整 DNS 配置。把它与当前有效配置合并，而不是直接替换整份订阅。若已有 tun 或其他同名顶层键，应修改原有字段，避免重复定义。

mixed-port: 7890
allow-lan: false
mode: rule

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

• mixed-port：同一端口接受 HTTP 和 SOCKS 代理连接；启用 TUN 后仍可保留这个入口。
• allow-lan: false：不向局域网开放代理服务；本机使用 TUN 不需要因此开启局域网访问。
• stack: mixed：选择 mihomo 支持的混合协议栈，不表示“同时开启系统代理”。实际可用性以客户端所带内核为准。
• auto-route：让内核自动配置相关路由。仅创建虚拟网卡而没有正确路由，仍可能接不到目标流量。
• auto-detect-interface：自动检测出站接口。多网卡环境仍需检查日志和实际选中的出口。
• dns-hijack：接管匹配的传统 DNS 请求。这里包含 UDP 53 和 TCP 53，不会直接解密应用内的加密 DNS。

系统代理与 TUN 的适用场景对比

游戏：接管 UDP 不代表节点支持 UDP

TUN 可以让游戏数据进入内核，但出口仍必须支持相应传输。若节点或服务端不支持 UDP，切换 TUN 不能补齐这项能力。先在连接面板查找游戏连接，确认网络类型、目标地址、命中规则和所选节点，再判断问题位于入口还是出口。

游戏启动器、登录服务和对局连接可能使用不同域名与地址。登录成功不能证明对局流量已走代理。也不要仅凭一次延迟测试断言 TUN 更快；延迟还取决于网络路径、节点负载和目标服务器位置。

命令行：单个工具优先显式配置

只运行一个支持代理参数的工具时，显式配置通常更容易追踪，也不会改变其他应用的路径。HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY 是否生效，由工具实现决定；变量名包含 HTTPS，也不意味着变量值必须使用 HTTPS 代理协议。

UWP：区分代理限制和沙箱回环限制

部分 UWP 应用访问本机代理时可能受回环限制影响。这与节点是否可用不是同一问题。若系统代理下无法连接，可以先用浏览器确认本地端口正常，再查看应用是否需要针对自身的回环授权，或改用 TUN 验证。不要为排查单个应用一次性放开所有应用的权限。

DNS 与 Fake-IP：TUN 能连接但打不开域名时先查这里

TUN 接管的是连接，DNS 负责把域名转换成可连接的地址。两条链路需要配合。典型症状是：开启后浏览器一直等待，日志出现解析超时，或同一域名在不同应用中表现不一致。此时继续切换节点，未必能解决入口 DNS 的问题。

• 确认 DNS 模块启用：检查当前运行配置中的 dns.enable，以及客户端是否通过自己的设置生成 DNS 配置。
• 检查端口 53 的接管：传统 DNS 通常使用 UDP 53，也可能使用 TCP 53；只检查其中一种不够完整。
• 识别应用内加密 DNS：应用通过 HTTPS 或 TLS 发送解析请求时，不会简单命中端口 53 的劫持设置。
• 检查解析上游可达性：确认 DNS 上游本身可以连接，避免上游依赖尚未建立的代理连接而形成循环依赖。

Fake-IP 会给符合条件的域名返回合成地址，由内核维护域名与地址之间的映射。常见示例地址池是 198.18.0.1/16。看到这类解析结果不一定是故障，但相关连接必须按预期回到内核，才能正确恢复目标。

关闭 TUN 后，如果应用仍缓存着合成地址，可能出现暂时无法访问。先重新建立应用连接，再按系统方式清理 DNS 缓存；Windows 可在终端执行 ipconfig /flushdns。浏览器自己的解析缓存可能需要另外清理。遇到局域网发现、设备管理或特定内网域名问题，应按实际需求检查 Fake-IP 过滤和直连解析策略，而不是把所有域名都加入过滤列表。

按四步验证：入口、规则、出口、回退

1. 先建立可用基线。

   关闭 TUN，确认订阅已启用，选择一个可用节点，用显式代理命令测试本地端口。在客户端连接面板记录目标域名、命中规则和策略组。基线不可用时，先处理订阅、端口或节点，不要叠加 TUN 排查。

2. 单独验证 TUN 接管。

   开启必要的服务或系统授权，启用 TUN，临时关闭系统代理，并确认测试工具没有继承代理环境变量。可执行 curl --head --noproxy "*" https://clash67.com/，再观察连接记录。这里的 --noproxy "*" 只是让 curl 不使用显式代理，不能绕过操作系统的 TUN 路由。

3. 核对规则和出口。

   找到刚才的请求，检查它是否命中预期规则，以及最终使用的是直连还是代理节点。能打开网页只能说明连接成功；若目标本来就能直连，单看页面结果无法证明代理出口生效。

4. 测试回退和特殊网络。

   关闭 TUN 后重新连接，确认普通网络恢复。再测试局域网设备、单位内网、IPv6 目标和游戏 UDP。每次只改一个选项，记录修改前后的差异，避免同时调整 DNS、路由和策略组后无法归因。

常见问题：双开、断网与局域网访问

最终选择以可验证的连接记录为准。系统代理满足需求时就保留简单入口；需要覆盖更多应用时启用 TUN，并逐项确认权限、路由、DNS 和 UDP 出口。关于内核与规则字段，可继续查阅本站协议参考中的 mihomo 内核说明。