連線疑難排解 · Clash 技術部落格

Clash Verge Rev TUN 回環崩潰怎麼修？

Windows 上 Clash Verge Rev 的 TUN 報 reject loopback、CPU 衝高或核心崩潰，核對出口網路介面卡並固定實際物理介面。檢查錯誤循環、實際請求與停用後的網路恢復。

閱讀正文回到部落格
  • Clash Verge Rev
  • Windows
  • TUN
  • reject loopback
  • 虛擬網路介面卡
本文目錄
文章作者
Clash 官方
發布日期
更新時間
預計閱讀
約 9 分鐘

開啟虛擬網卡代理後，電腦突然反覆出現錯誤，最重要的是停止繼續觸發，而不是等待用戶端自行恢復。原本的系統代理能否連網、日誌中的撥號是否繞回自身、實際使用哪張網卡，需要一起核對；只有證據相符時，才將出口指定為真正連網的介面。

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 或服務模式。

Windows TUN 出口誤選後的回環路徑
  1. verge-mihomo.exe向目前代理節點發起出站撥號
  2. 誤選的虛擬網路介面卡auto-detect-interface 沒有使用實際物理出口
  3. Mihomo TUN核心自己的撥號再次進入 TUN
  4. 回環檢測與重試持續 reject loopback，CPU 與執行緒快速增長

把出站介面固定為目前預設路由使用的實體網卡後，核心連線不再繞回自己的 TUN。回環錯誤日誌應停止，CPU 使用量和執行緒數也應恢復正常。

關閉 TUN 後檢查原節點與系統代理

發現日誌密集重複時，先關閉 TUN，不要同時切節點、改 DNS 或反覆重載核心。等待 CPU 回落後，用原 Profile、原節點開啟系統代理做一次網頁存取；系統代理恢復，說明訂閱和節點仍有可用基礎，故障更集中在 TUN 出口選擇。

若介面已卡住、無法正常退出，可用工作管理員結束 Clash Verge Rev。之後檢查 Windows 系統代理，避免繼續指向已停止的本機連接埠；不要把結束 GUI 當成 TUN 或服務已停止。恢復直連後再匯出日誌、執行設定與網路介面卡清單，公開副本遮蓋訂閱 token、節點位址與密碼。

恢復連線並保留覆寫記錄

  1. 關閉 TUN

    停止新的回環撥號，等待 CPU 和日誌寫入恢復正常。

  2. 驗證系統代理

    保持原 Profile 與節點不變，只開啟系統代理發起一次新請求。

  3. 儲存目前 Merge

    複製正在使用的覆寫和最終設定，後續只改出口介面兩個欄位。

  4. 保留首段日誌

    記錄用戶端、核心與 Windows 版本，以及第一條 reject loopback 前後的脫敏內容。

用三個信號限定問題範圍

信號本問題中的表現不符合時
觸發動作開啟 TUN 後數秒開始系統代理也失敗時先查共同鏈路
日誌主體verge-mihomo.exe 撥號節點並反覆 reject loopback只有普通應用超時不算同一故障
資源變化CPU 快速升高，可能出現 thread exhaustion資源穩定時，依第一則錯誤訊息找出對應原因

查出目前真正聯網的實體網路介面卡

保持 TUN 關閉，在 PowerShell 中同時查看可見網路介面卡和 IPv4 預設路由。Get-NetAdapter 的 Name 是後面需要填寫的介面名；Get-NetRoute 則能說明此刻哪張網路介面卡承擔預設出口。無線網路可能叫 Wi-Fi，有線網路可能叫以太網或 Ethernet，必須使用本機結果。

Windows 只讀檢查網路介面卡與目前預設路由
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。

把「以太网」替換成上一步查到的實際 Name
interface-name: "以太网"
tun:
  auto-detect-interface: false

讓改動保持最小

  1. 確認介面名完全一致

    包括空格、連字元和語言，不使用 InterfaceDescription 代替 Name。

  2. 儲存並執行設定驗證

    interface-name 位於頂層，auto-detect-interface 只在 tun 下縮進兩個空格。

  3. 保持其他欄位不變

    繼續使用原節點、規則、DNS、stack 和 strict-route，避免一次引入第二個變數。

  4. 完整重啟核心

    確認新執行設定已經包含兩個覆寫值，再進行一次受控 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 並重複只讀檢查，不要把舊介面名永久留在所有網路環境。

覆寫無效時恢復原狀態

  1. 關閉 TUN

    確認 Windows 直連恢復後再編輯 Merge。

  2. 恢復兩個欄位的原狀態

    依保存的 Merge 還原 interface-name 與 tun.auto-detect-interface 的原值；原本沒有的欄位才刪除。不要連帶移除其他 TUN 覆寫。

  3. 重新載入原 Profile

    用系統代理確認原訂閱、節點與規則仍可工作。

  4. 保留脫敏證據

    提交實際網路介面卡清單、首條錯誤和執行設定差異，不公開訂閱與節點認證資訊。

參考資料