先区分流量接管与出站规则

系统代理和 TUN 解决的是同一个前置问题：应用发出的连接，怎样进入 Clash 内核。进入内核以后，再由运行模式、分流规则和策略组决定直连、代理或拒绝。开启 TUN 不等于开启全局代理；开启系统代理也不等于所有进程都会遵从它。

本文以使用 mihomo 内核的 Clash 客户端为例。不同客户端、内核和操作系统的 TUN 实现并不完全相同，不能把某个客户端的开关名称直接套到所有软件上。操作前先在客户端的内核信息中确认实际运行的是 mihomo，再对照它支持的配置字段。

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

浏览器怎样把连接交给 Clash

客户端打开“系统代理”后，通常会把操作系统的 HTTP、HTTPS 代理地址改成本地监听地址。例如，配置中的 mixed-port: 7890 表示在同一个端口接受 HTTP 代理和 SOCKS 请求。这里的 7890 是示例值，检查时应以当前生效配置为准。

支持系统代理的浏览器读取设置后，先连接 127.0.0.1:7890。访问 HTTPS 网站时，通常通过 HTTP CONNECT 建立隧道，再在隧道中进行 TLS 通信。普通代理转发不需要给浏览器安装用于解密网站流量的根证书。

支持系统代理的应用
  → 127.0.0.1:7890
  → mihomo 规则匹配
  → DIRECT 或所选代理节点

系统设置不等于所有程序的设置

因此，“浏览器能访问、终端不能访问”不一定是节点失效。两者可能根本没有经过同一条接管路径。类似地，Windows 的 WinHTTP 代理与用户界面的代理设置并非同一套状态，不能只凭 netsh winhttp show proxy 的输出判断浏览器是否使用代理。

TUN：通过虚拟网卡与路由接管

TUN 是三层虚拟网络接口。启用后，客户端或辅助服务创建虚拟网卡，并按配置调整路由。目标地址命中这些路由的 IP 数据包被送入内核处理，不要求应用先理解 HTTP 代理或 SOCKS 协议。

应用发出 IP 数据包
  → 操作系统路由选择
  → TUN 虚拟网卡
  → mihomo 网络栈与规则匹配
  → DIRECT 或所选代理节点

这条路径使不遵从系统代理的应用也有机会进入分流规则。它不保证所有协议都能通过任意代理节点转发：例如游戏语音需要 UDP，仍然要求节点协议、服务端和相关设置支持 UDP；ICMP 能否获得符合预期的响应，也不能用来直接推断 HTTPS 代理是否正常。

三个常见字段分别负责什么

字段作用检查重点
auto-route自动配置通向 TUN 的路由是否与公司 VPN、其他虚拟网卡冲突
auto-detect-interface自动识别用于出站的网络接口切换 Wi-Fi、有线网络后是否选对出口
stack选择 TUN 使用的网络栈根据内核支持情况与系统兼容性选择

创建网卡和修改路由通常需要管理员权限、系统服务或平台授权。客户端的“服务模式”常用于让辅助服务承担这些操作，不等于代理服务器，也不意味着服务安装成功后节点就一定可用。若 TUN 开关立即回弹，应先查看权限、服务和网卡创建日志，再排查节点。

DNS 与 fake-ip：域名如何参与分流

系统代理场景下，应用可能把域名直接交给本地代理，也可能先在本地解析；具体行为取决于应用与代理协议。TUN 收到的则是 IP 数据包，若内核没有相应域名映射，仅凭目标 IP 无法始终准确还原应用原先访问的域名。

fake-ip 模式通过给域名返回一个合成地址，保存域名与地址的对应关系。例如 mihomo 常用的 198.18.0.0/16 范围用于这类映射，并不代表网站真实出口地址。应用随后连接合成地址时，内核可取回域名，再让 DOMAIN-SUFFIX 等规则参与匹配。

配置片段要合并进已有 Profile

下面是用于说明字段关系的 mihomo YAML 片段，不含节点与策略组，不能作为完整订阅使用。它采用 IPv4 DNS 示例；不要直接覆盖已有 Profile，也不要在文件中重复添加第二个顶层 dns 或 tun。若客户端使用覆写或合并机制，应检查最终生效配置。

mixed-port: 7890
mode: rule

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5

dns-hijack 中的 any:53 表示对被 TUN 捕获的相应传统 DNS 请求进行劫持，默认匹配 UDP；需要处理 TCP DNS 时，可按内核文档增加 tcp://any:53。它不是把所有 DNS 协议强制转换成本地解析：浏览器内置 DoH 通常使用 HTTPS，不能只靠端口 53 的规则接管。

怎么选：先按应用需求判断

使用场景优先尝试验证方法
浏览器、读取系统代理的桌面应用系统代理打开网页，确认客户端连接记录中出现对应域名
单个命令行工具工具自己的代理参数显式指定本地端口，对比不指定代理时的结果
忽略系统代理的应用TUN关闭系统代理后，检查应用新连接是否仍进入内核
游戏、语音等 UDP 应用TUN 与支持 UDP 的节点检查 UDP 连接、策略组选择与实际会话是否正常
同时使用公司 VPN先保留已有网络方案检查内网路由、域名解析和地址排除项，再逐项启用

两种方式可以同时开启，但第一次排查时不建议这样做。支持系统代理的应用可能继续连接本地代理端口，其他应用则走 TUN，连接记录看起来都正常，却难以确定究竟是哪种接管方式生效。先把单一路径验证清楚，再按实际需求组合。

也不要用“开启 TUN 后延迟更低”作为通用判断。TUN 改变的是本机接管路径，远端出口地区、线路负载和服务端状态仍由节点决定。比较时至少固定目标网站、节点、规则模式和测试工具，避免把换节点带来的变化归因于虚拟网卡。

切换步骤：每次只改变一个变量

  1. 保存当前配置。记录 Profile 名称、本地端口、运行模式和策略组选择。复制自定义覆写，避免订阅更新后无法恢复。
  2. 先验证本地代理入口。暂时关闭 TUN，保持内核运行，用显式代理命令访问测试地址。失败时先处理端口、节点或规则问题。
  3. 验证系统代理。打开系统代理，用浏览器访问相同地址，在客户端连接页查看域名、命中规则和实际出站。测试后关闭系统代理。
  4. 单独启用 TUN。按客户端要求授权或启动服务，确认没有网卡创建失败、路由写入失败等日志，再测试不设置代理的应用。
  5. 检查业务之外的连接。测试局域网设备、公司内网、语音和休眠唤醒后的网络。确认需要保留的直连没有被错误送往远端节点。

用命令区分端口问题与路由问题

下面的地址仅作测试示例。Windows 可使用 curl.exe，macOS、Linux 可使用 curl。将示例端口替换成当前配置中的实际值；第二条命令清除本次请求的显式代理影响，但在 TUN 已开启时，数据包仍可能被虚拟网卡接管。

# 测试本地 HTTP 代理入口
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com/

# 不使用 curl 的代理入口，观察系统路由路径
curl --proxy "" --noproxy "*" --connect-timeout 10 -I https://example.com/

返回 HTTP 状态只能说明该次请求获得了响应，不能独立证明是否走代理。还要在客户端连接页核对该请求是否出现、命中哪条规则，以及最后选择的是 DIRECT 还是代理节点。浏览器可能复用旧连接，切换后应关闭旧连接或重启测试应用再观察。

常见故障按入口、DNS、路由排查

系统代理可用，TUN 不通

网页正常，游戏或语音不通

先确认应用连接是否进入 TUN，再确认相应策略组实际选中的节点支持 UDP。网页主要测试的是 TCP 或浏览器自身的连接路径，不能证明游戏的 UDP 通道可用。也不要只看节点延迟测试结果；测试 URL 成功和业务协议成功是两件事。

退出客户端后仍无法联网

先检查系统代理是否仍指向已停止监听的 127.0.0.1 端口，再通过客户端正常关闭 TUN，确认路由与 DNS 设置恢复。若客户端异常退出，可重新启动后执行正常关闭；仍有问题时，保存日志并按操作系统网络设置逐项恢复，不要直接批量删除全部网卡或路由。