系统代理与 TUN：入口不同，分流规则仍然生效

浏览器可以访问，终端、游戏启动器却连接失败，常见原因是这些程序没有读取 Windows 的系统代理设置。系统代理提供一个代理地址，例如 127.0.0.1:7890，由应用决定是否使用；它不会自动把电脑上所有网络连接转交给 Clash。

TUN 则创建虚拟网络接口，通过路由把符合条件的 IP 流量送入内核。应用不必支持 HTTP 或 SOCKS 代理，连接也有机会被接管。本文以 Windows 10、Windows 11 和使用 mihomo 内核的 Clash 客户端为范围；旧版 Clash 内核的字段、驱动和界面可能不同，不能直接套用全部配置。

比较项系统代理TUN 虚拟网卡
接管入口应用连接本地 HTTP 或 SOCKS 端口系统路由把 IP 流量交给虚拟接口
应用配合需要读取系统设置或手动设置代理通常不需要应用内配置代理
UDP 流量常规 HTTP 系统代理不能直接接管可接管，但还要看节点和协议支持
权限要求通常可在当前用户下设置创建接口、修改路由通常需要提升权限
分流方式进入内核后按当前模式和规则处理进入内核后仍按当前模式和规则处理

开启前准备：订阅、内核与网络基线

不要把首次导入订阅、切换节点、修改 DNS 和开启 TUN 放在同一次操作里。先建立一个可用基线，发生异常时才能判断问题来自哪一层。

  1. 记录客户端与内核信息。在「设置」→「关于」或客户端的内核信息区域查看版本。确认运行的是 mihomo，而不是仅凭客户端名称判断功能。
  2. 验证订阅能用。更新配置，选择一个可连接的节点；暂时开启系统代理，用浏览器访问一个需要代理的网站，再访问一个直连网站。
  3. 记录本地端口。例如混合端口为 7890。这是 HTTP/SOCKS 入口，不是虚拟网卡的端口，也不是 DNS 监听端口。
  4. 记录其他网络组件。包括企业 VPN、游戏加速器、其他代理客户端，以及 Hyper-V、WSL、Docker 创建的虚拟接口。
  5. 准备恢复方式。记住 TUN 开关位置；远程桌面环境下改路由前，应有现场操作或其他管理通道，避免连接断开后无法恢复。

初次测试建议退出其他代理与加速器，仅保留当前需要的网络连接。企业管理设备应先确认网络策略，不要为了让开关变绿而关闭安全软件、防火墙或组织规定的访问控制。

安装服务模式，再启用 TUN 虚拟网卡

第一步：让内核具备所需权限

Windows 上创建 TUN 接口、调整路由需要相应权限。常见做法是安装客户端提供的后台服务，由服务执行需要提升权限的操作。服务模式解决的是运行权限和后台管理问题，不是节点质量，也不会自动开启 TUN。

  1. 打开客户端的「设置」，查找「服务模式」「Service Mode」或「Clash 服务」。部分客户端把它放在「设置」→「Clash 设置」中；菜单以当前版本实际显示为准。
  2. 点击「安装」或「安装服务」，确认 Windows 用户账户控制提示。安装过程中不要移动客户端所在目录。
  3. 等待界面显示“已安装”或“运行中”。若提示需要重启内核或客户端，先保存配置，再执行重启。
  4. 如果安装失败，先查看安装日志与安全软件记录。临时以管理员身份启动可用于区分权限问题，但不应反复安装未知来源的驱动包。

需要辅助检查服务时，可在 PowerShell 执行下面的只读命令。不同客户端的服务名称不一致，因此筛选结果只能作为线索，最终还要与客户端日志、服务可执行文件路径核对。

Get-Service | Where-Object {
  $_.Name -match 'clash|mihomo|verge' -or
  $_.DisplayName -match 'clash|mihomo|verge'
} | Format-Table Status, Name, DisplayName -AutoSize

第二步：开启 TUN，先保持 Rule 模式

  1. 在客户端设置或首页开关区找到「TUN 模式」；若它位于子页面，进入后启用虚拟网卡。
  2. 初次使用保留客户端推荐的协议栈，开启自动路由；不要同时调整 MTU、接口名称和接口绑定。
  3. 保持 Rule 模式，使用刚才验证过的节点或策略组。
  4. 查看日志是否出现创建接口、配置路由成功的信息。仅有界面开关亮起，不能证明实际接管成功。

按 Win + R，输入 ncpa.cpl，可打开“网络连接”查看新增接口。接口名称由客户端或配置决定，不一定就叫“TUN”。不要修改它的共享属性，也不要手动给它填写默认网关。

DNS 劫持与 fake-ip：为什么域名解析也要检查

连接进入 TUN，不代表 DNS 一定按预期处理。应用可能仍向路由器发送 DNS 查询，也可能通过浏览器的安全 DNS 使用 HTTPS 解析。内核若无法把目标 IP 与域名关联，一些依赖域名的分流规则就可能无法按预期命中。

mihomo 的 dns-hijack 可以把经过 TUN 的指定 DNS 流量交给内置 DNS 模块处理。常见配置拦截 UDP 53 和 TCP 53；这不是对所有解析方式的通用拦截，DoH 通常使用 HTTPS 的 443 端口，DoT 通常使用 853 端口，都不等同于普通 53 端口 DNS。

mihomo 配置字段示例

下面是便于理解字段的配置片段，不是完整订阅。它不包含节点、策略组和分流规则。已有配置包含 tun: 或 dns: 时，应合并到原有区块，不能在同一级重复粘贴同名键。

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://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
    - 1.1.1.1
  • auto-route：让内核设置接管需要的路由。若关闭，就需要自行规划路由，不适合作为首次排查方案。
  • auto-detect-interface：尝试识别流量出口。多网卡、企业 VPN 环境可能仍需按实际接口调整，不能保证所有环境都识别正确。
  • stack: system：使用系统协议栈方案。若当前客户端推荐其他栈，先遵循其默认值；切换栈主要用于兼容排查，不代表固定的速度排名。
  • listen: 127.0.0.1:1053：内置 DNS 的本机监听地址。普通 Windows DNS 地址输入框不能填写端口，因此不能直接把它当作“系统 DNS 地址加端口”使用。
  • fake-ip：为域名分配映射地址，便于连接与域名关联。示例中的 198.18.0.0/16 地址属于预期映射范围，不是远端网站的真实地址。

示例 DNS 服务器使用普通 DNS，是否可达取决于当前网络，也不提供加密解析。实际使用应沿用已验证的 DNS 方案；节点服务器域名的解析、企业内部域名和分流 DNS 可能还需要独立配置，不能靠替换这两行服务器地址解决全部问题。

应用配置后清理缓存

优先使用客户端的覆写、扩展配置或 TUN/DNS 设置入口，避免直接修改每次订阅更新都会覆盖的文件。应用后重启内核，并在命令提示符中清理 Windows DNS 缓存：

ipconfig /flushdns

随后完全退出并重新打开待测应用。浏览器可能保留自己的 DNS 缓存；若结果仍不一致，可暂时关闭浏览器“安全 DNS”做对照测试，记录结果后恢复所需设置。不要把永久关闭所有加密 DNS 当作开启 TUN 的必需步骤。

验证接管：终端、游戏与连接日志一起看

终端测试：绕开显式代理，但保留 TUN

在 Windows PowerShell 中建议明确运行 curl.exe，避免某些环境把 curl 解释为其他命令。先关闭客户端系统代理，再执行：

curl.exe --noproxy "*" --connect-timeout 10 -I https://example.com/

--noproxy "*" 让本次 curl 请求不使用显式代理，包括常见代理环境变量；它不会绕过系统路由，也不会绕过 TUN。因此，这个测试适合验证“不支持或不使用系统代理的程序”能否经由 TUN 进入内核。返回 HTTP 响应只说明请求有结果，不能单凭它判断最终用了哪个节点。

  • 打开客户端的「连接」页面，按目标域名、目标 IP 或进程信息筛选这次请求。
  • 检查命中的规则和策略链。如果显示 DIRECT，说明当前策略要求直连，不一定是 TUN 失效。
  • 关闭 TUN 后再次执行同一命令，形成对照。一个原本就能直连的网站，两次都成功是正常现象。
  • 若要验证代理链，使用已知需要代理且允许访问的目标，同时确认对应规则确实选择了代理策略。

查看接口与路由时，可运行以下只读命令。输出用于观察变化，不需要照着其他电脑的接口编号手动添加路由。

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status -AutoSize
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object InterfaceIndex, DestinationPrefix |
  Format-Table InterfaceIndex, DestinationPrefix, NextHop, RouteMetric -AutoSize

游戏测试：先分清 TCP 登录与 UDP 对局

启动器、登录、下载和实际对局可能使用不同的域名与协议。登录成功但进房失败时，应该检查对局 UDP，而不是只看浏览器测速。TUN 能把 UDP 连接送入内核，但所选节点、传输协议、服务端及配置也必须支持相应的 UDP 转发。

  1. 完全退出游戏和启动器，开启 TUN 后重新启动，让新连接使用当前路由。
  2. 在「连接」中观察游戏对应的 TCP、UDP 记录、目标地址和命中规则。
  3. 核对游戏流量是否被局域网规则、目标 IP 规则或进程规则分到 DIRECT。
  4. 更换一个明确支持 UDP 的节点做对照；节点延迟测试成功，不代表游戏 UDP 链路可用。

TUN 不是专门的游戏加速线路。跨区路径、节点拥塞、游戏服务器位置和反作弊兼容性都会影响结果；不应承诺开启后降低延迟。受管理的游戏或工作环境还应遵守相应服务规则。

常见故障：按权限、路由、DNS、策略顺序排查

现象优先检查下一步
开关自动关闭或提示创建接口失败服务状态、权限、内核启动日志重启已安装服务，检查安装路径和安全软件记录
浏览器能用，终端不通浏览器是否仍在使用系统代理关闭系统代理，用 curl.exe 对照并检查连接记录
开启后大部分域名超时DNS 配置、上游可达性、出口路由恢复之前可用的 DNS 设置，一次只修改一项
游戏登录成功，对局失败UDP 支持、分流规则、其他加速器查看 UDP 连接，换支持 UDP 的节点复测
公司内网或打印机失联局域网路由、内部 DNS、严格路由选项恢复内网直连和企业 DNS，必要时停用 TUN
部分 IPv6 网站异常IPv6 地址、路由与 DNS 是否一致比较 A/AAAA 解析和连接，不只检查 IPv4

WSL、Docker 与其他 VPN 不按普通桌面应用处理

WSL 2、容器和虚拟机可能经过独立的虚拟交换机、NAT 或镜像网络。宿主机应用进入 TUN，不代表来宾环境一定沿用相同路径。应在对应环境里分别测试 DNS、默认路由和连接记录，不能仅凭 Windows 浏览器成功就判断接管范围。

如果企业 VPN 开启后才断网，先查看两者是否同时修改路由或 DNS。不要随意开启严格路由来“强制覆盖”另一套网络：它可能改变局域网和其他接口的可达性。多网卡环境应明确需要保留的内网路径，再决定接口绑定和绕过规则。

无法联网时的恢复顺序

  1. 关闭 TUN，等待接口和路由恢复，再测试普通直连网络。
  2. 如果准备退出客户端，同时关闭系统代理，避免 Windows 继续指向已经停止监听的 127.0.0.1:7890。
  3. 恢复刚才改动的 DNS 或覆写配置，再重启客户端内核。
  4. 若仍异常，保存日志与接口信息后重启 Windows。不要把卸载全部网卡、重置整个网络栈作为第一步。

开启后的验收清单

一个可用的 TUN 配置，应同时满足“接口建立、应用进入内核、规则命中正确、日常网络可用”四项，而不是只看开关状态。完成下面的检查后，再考虑让客户端随 Windows 启动。

  • 权限：后台服务正常运行，内核日志没有重复的接口创建失败或权限错误。
  • 接管：系统代理关闭时，测试终端请求仍能在客户端连接页面中找到。
  • 策略：代理目标命中预期策略组，直连目标和局域网资源保持预期路径。
  • DNS：常用域名解析正常，内部域名没有被错误送往公共解析器。
  • 协议：需要使用的 UDP 应用单独验证，不用 TCP 下载速度代替游戏测试。
  • 恢复：关闭 TUN、退出客户端后，系统代理与网络访问状态符合预期。

后续若只有单个应用异常，先查看该应用的连接与规则，不要立刻更换整套配置。关于基础端口、订阅和分流设置，可继续查看Clash 使用教程；需要核对配置字段时，可查阅协议手册。