本文目錄
確認日誌正在形成 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 普通網路可以恢復