本文目录
确认日志正在形成 TUN 回环风暴
本文只处理一组明确的 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 或服务模式。
用三个信号限定问题范围
| 信号 | 本问题中的表现 | 不符合时 |
|---|---|---|
| 触发动作 | 开启 TUN 后数秒开始 | 系统代理也失败时先查共同链路 |
| 日志主体 | verge-mihomo.exe 拨号节点并反复 reject loopback | 只有普通应用超时不算同一故障 |
| 资源变化 | CPU 快速升高，可能出现 thread exhaustion | 资源稳定时继续按首条错误分流 |
- verge-mihomo.exe向当前代理节点发起出站拨号
- 误选的虚拟网卡auto-detect-interface 没有使用真实物理出口
- Mihomo TUN核心自己的拨号再次进入 TUN
- 回环检测与重试持续 reject loopback，CPU 与线程快速增长
把出站接口固定为当前默认路由使用的物理网卡后，核心拨号不再回到自己的 TUN，回环日志与资源风暴应同时停止。
关闭 TUN，先让电脑恢复稳定
发现日志密集重复时，先关闭 TUN，不要同时切节点、改 DNS 或反复重载内核。等待 CPU 回落后，用原 Profile、原节点开启系统代理做一次网页访问；系统代理恢复，说明订阅和节点仍有可用基础，故障更集中在 TUN 出口选择。
若界面已经卡住，先从任务管理器正常结束 Clash Verge Rev，再确认 Windows 系统代理没有继续指向已停止的本地端口。恢复直连后再导出应用日志、当前运行配置和网卡列表，配置副本必须去掉订阅 token、节点地址与密码。
建立可回退的排查基线
关闭 TUN
停止新的回环拨号，等待 CPU 和日志写入恢复正常。
验证系统代理
保持原 Profile 与节点不变，只开启系统代理发起一次新请求。
保存当前 Merge
复制正在使用的覆写和最终配置，后续只改出口接口两个字段。
保留首段日志
记录客户端、内核与 Windows 版本，以及第一条 reject loopback 前后的脱敏内容。
查出当前真正联网的物理网卡
保持 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 后系统直连仍能立即恢复
回环消失后，剩余 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。
移除两个字段
删除顶层 interface-name 和本次加入的 tun.auto-detect-interface。
重新载入原 Profile
用系统代理确认原订阅、节点与规则仍可工作。
保留脱敏证据
提交实际网卡列表、首条错误和运行配置差异，不公开订阅与节点凭据。
六项检查确认 Windows TUN 已恢复
最终验证清单
- 系统代理可用，开启 TUN 后原请求仍能正常完成
- 新日志没有 reject loopback、thread exhaustion 或核心替换循环
- 运行配置中的 interface-name 与当前默认路由接口一致
- 任务管理器观察一段时间后 CPU 与线程没有持续增长
- 切换节点或发起新连接时，连接页能显示预期规则与出口
- 关闭 TUN 和退出客户端后，Windows 普通网络可以恢复