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 更适合接管不遵守系统代理设置的程式。

这类接管通常需要较高的系统权限。桌面用戶端可能通过背景服务或提权程序设置网卡与路由；Android 用戶端则常透过系统 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 上游是否可连线：确认 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 内核说明。