本文目录
打开虚拟网卡代理后，电脑突然忙于重复报错，最紧要的是停止继续触发，而不是等客户端自己恢复。原来的系统代理能否联网、日志中的拨号是否绕回自身、实际使用哪张网卡，需要一起核对；只有证据对应时，才把出口固定到真实联网接口。
TUN 开启后 reject loopback 与 CPU 暴涨
结合联网状态与日志确认：Windows 上 Clash Verge Rev 的系统代理原本可用，开启 TUN 后却连续出现 reject loopback connection，verge-mihomo.exe 拨号反复失败且 CPU 上升；严重时出现 thread exhaustion 并导致内核崩溃。出现这组现象就停止触发。
官方 issue #7764 在服务模式、Clash Verge Rev v2.5.2 与 Mihomo v1.19.29、v1.19.30 上记录了这条故障链。报告者最终确认，自动检测选中了 v2rayN 的 Wintun 虚拟网卡；手动固定真实以太网接口后，回环日志、CPU 异常与线程耗尽都停止。
这是一台同时装有多块虚拟网卡的电脑上确认的结果，不代表所有 TUN 超时都来自接口选择。日志没有 reject loopback，或关闭 TUN 后系统代理也失败时，应先排查订阅、节点、DNS 或服务模式。
- verge-mihomo.exe向当前代理节点发起出站拨号
- 误选的虚拟网卡auto-detect-interface 没有使用真实物理出口
- Mihomo TUN核心自己的拨号再次进入 TUN
- 回环检测与重试持续 reject loopback，CPU 与线程快速增长
把出站接口固定为当前默认路由使用的物理网卡后，内核连接不再绕回自己的 TUN。回环日志应停止，CPU 占用和线程数也应恢复正常。
关闭 TUN 后检查原节点与系统代理
发现日志密集重复时，先关闭 TUN，不要同时切节点、改 DNS 或反复重载内核。等待 CPU 回落后，用原 Profile、原节点开启系统代理做一次网页访问；系统代理恢复，说明订阅和节点仍有可用基础，故障更集中在 TUN 出口选择。
若界面已经卡住、无法正常退出，可用任务管理器结束 Clash Verge Rev。随后检查 Windows 系统代理，避免继续指向已停止的本地端口；不要把结束 GUI 当成 TUN 或服务已经停止。恢复直连后再导出日志、运行配置和网卡列表，公开副本遮盖订阅 token、节点地址与密码。
恢复连接并保留覆写记录
关闭 TUN
停止新的回环拨号，等待 CPU 和日志写入恢复正常。
验证系统代理
保持原 Profile 与节点不变，只开启系统代理发起一次新请求。
保存当前 Merge
复制正在使用的覆写和最终配置，后续只改出口接口两个字段。
保留首段日志
记录客户端、内核与 Windows 版本，以及第一条 reject loopback 前后的脱敏内容。
用三个信号限定问题范围
| 信号 | 本问题中的表现 | 不符合时 |
|---|---|---|
| 触发动作 | 开启 TUN 后数秒开始 | 系统代理也失败时先查共同链路 |
| 日志主体 | verge-mihomo.exe 拨号节点并反复 reject loopback | 只有普通应用超时不算同一故障 |
| 资源变化 | CPU 快速升高，可能出现 thread exhaustion | 资源稳定时，按第一条错误查找对应原因 |
查出当前真正联网的物理网卡
保持 TUN 关闭，在 PowerShell 中同时查看可见网卡和 IPv4 默认路由。Get-NetAdapter 的 Name 是后面需要填写的接口名；Get-NetRoute 则能说明此刻哪张网卡承担默认出口。无线网络可能叫 Wi-Fi，有线网络可能叫以太网或 Ethernet，必须使用本机结果。
Get-NetAdapter -Name * |
Format-Table Name, InterfaceDescription, Status, LinkSpeed, ifIndex
Get-NetRoute -DestinationPrefix "0.0.0.0/0" |
Sort-Object RouteMetric |
Format-Table InterfaceAlias, NextHop, RouteMetric, InterfaceMetric从结果里排除错误候选
| 结果 | 判断 |
|---|---|
| Status 为 Up，且默认路由使用同一 InterfaceAlias | 优先作为当前真实出口候选 |
| 名称或描述含 Wintun、TAP、VMware、VirtualBox | 属于虚拟适配器时不能只凭 LinkSpeed 选择 |
| 网卡 Up，但没有当前默认路由 | 可能只服务虚拟机、VPN 或局域网 |
| 同时有 Wi-Fi 和以太网默认路由 | 先断开不用的一条，再重新确认实际出口 |
自动检测是否把出口指向了虚拟网卡
打开刚才保存的运行配置与本次启动日志，确认 auto-detect-interface 是否启用，并查找 Mihomo 实际采用的出站接口。若系统默认路由是物理 Wi-Fi 或以太网，日志却显示节点拨号绑定 Wintun、TAP 或 VMware 接口，这才与官方 issue 的根因一致。
不要根据虚拟网卡标称的高速率判断。#7764 的环境里，vgate0 报告 100 Gbps，自动检测却因此选错出口。接口证据一致后再添加覆写；找不到选择结果时，可以先把网卡列表与首段日志提交给项目维护者，而不是猜一个名称。
默认路由是以太网，运行日志却使用 vgate0
符合接口误选，继续做最小覆写。
默认路由和 Mihomo 都使用同一物理网卡
不符合已知根因，停止套用本文配置。
日志只有 dns resolve failed
先按 DNS 链路排查，不把它当 reject loopback。
关闭其他 VPN 后故障消失
记录冲突软件与网卡，不必再固定接口。
在 Merge 中只固定出口接口
Mihomo 官方配置把 interface-name 定义为顶层出站接口，把 auto-detect-interface 放在 tun 下。打开当前 Profile 的 Merge 或覆写，只添加这两个字段；不要复制 issue 中整段 TUN 和 DNS 配置，也不要把物理网卡名称写进 tun.device。
interface-name: "以太网"
tun:
auto-detect-interface: false让改动保持最小
确认接口名完全一致
包括空格、连字符和语言，不使用 InterfaceDescription 代替 Name。
保存并执行配置校验
interface-name 位于顶层，auto-detect-interface 只在 tun 下缩进两个空格。
保持其他字段不变
继续使用原节点、规则、DNS、stack 和 strict-route，避免一次引入第二个变量。
完整重启内核
确认新运行配置已经包含两个覆写值，再进行一次受控 TUN 测试。
用一次受控测试验证接口修复
重启核心后先打开日志，再开启 TUN。保持测试窗口可见，发起一个普通 HTTPS 请求；如果 reject loopback 再次密集出现，立即关闭 TUN。真正的修复必须同时改变日志、CPU、内核存活和真实连接，不能只看 TUN 开关保持开启。
官方 issue 的报告者在固定物理以太网后确认，回环风暴完全消失，CPU 恢复正常，v1.19.29 与 v1.19.30 都不再出现线程耗尽。上游 issue #3122 随后以无需 Mihomo 核心改动关闭，所以本案例不应写成某个新内核版本已经修复。
接口修复的完成标准
- 开启 TUN 后不再出现新的 reject loopback connection
- 任务管理器中的 verge-mihomo.exe CPU 保持稳定
- 内核持续运行，没有 thread exhaustion 或反复 reload
- 同一节点能完成一次新的 HTTPS 请求并出现在连接记录
- 关闭 TUN 和退出客户端后，Windows 普通网络可以恢复
- 运行配置中的 interface-name 与当前默认路由接口一致
- 切换节点或发起新连接时，连接页能显示预期规则与出口
回环消失后，剩余 DNS 错误另行处理
#7764 在接口问题解决后还暴露了独立 DNS 配置错误，其中一次来自 DoH 域名的自举循环。维护者也纠正了报告者对 proxy-server-nameserver 的早期判断。不要把 issue 里的 DoT、nameserver-policy 或整段 DNS 示例复制到自己的配置中。
如果 reject loopback 已消失、CPU 正常，但网页仍报 dns resolve failed，应保留已经验证的接口覆写，再以相同节点比较域名解析与直接访问。只有 DNS 证据明确时才改对应上游或策略，避免把两个已经分开的故障重新混在一起。
接口修复后的下一条错误
| 现象 | 处理 |
|---|---|
| 连接记录有域名，节点拨号正常 | 接口已选对，继续确认实际使用是否正常 |
| 只有 dns resolve failed | 检查 DNS 上游、自举和 proxy-server-nameserver |
| 仍然 reject loopback | 关闭 TUN，重新核对实际接口名与运行配置 |
| 配置校验失败 | 撤销覆写，检查顶层字段和 YAML 缩进 |
切网后重新选择出口接口，无效就撤销接口覆写
关闭自动检测后，Mihomo 会持续使用手动指定的网卡。从有线切到 Wi-Fi、手机热点或 USB 网卡时，原接口可能不再承担默认路由。切网后若 TUN 重新失效，先关闭 TUN 并重复只读检查，不要把旧接口名永久留在所有网络环境。
覆写无效时恢复原状态
关闭 TUN
确认 Windows 直连恢复后再编辑 Merge。
恢复两个字段的原状态
根据保存的 Merge 还原 interface-name 与 tun.auto-detect-interface 的原值；原来没有的字段才删除。不要连带移除其他 TUN 覆写。
重新载入原 Profile
用系统代理确认原订阅、节点与规则仍可工作。
保留脱敏证据
提交实际网卡列表、首条错误和运行配置差异，不公开订阅与节点凭据。