本文目錄
只有這組日誌才適合固定出口介面
這篇文章處理一個很具體的故障：Intel Mac 連線 iPhone 個人熱點後，系統直連正常，Clash Verge Rev 開啟 TUN 卻無法聯網。官方 issue #7576 記錄的環境是用戶端 v2.5.2 與 Mihomo v1.19.29，其他 Mac 只有出現相同日誌時才適合照此檢查。
關鍵不是網頁顯示超時，而是 TUN 剛啟動時依序出現 get empty name、<invalid>、interface not found，隨後才出現 dns resolve failed。它表示自動檢測出口時先拿到了空介面，DNS 和代理連線因此沒有可用出口。
先確認是否屬於同一問題
| 現象 | 判斷 | 下一步 |
|---|---|---|
| 關閉 TUN 後系統直連立即恢復 | 節點和系統網路至少不是一起失效 | 繼續檢查出口介面 |
| 日誌先出現 get empty name 或 <invalid> | 自動檢測沒有及時取得出口 | 查詢目前實體網路介面卡 |
| 日誌只有 operation not permitted | 這是權限或服務模式問題 | 不要修改出口介面 |
| 系統代理和 TUN 都無法連線 | 可能是節點、訂閱或核心故障 | 先處理共同故障 |
- iPhone 個人熱點為 Mac 提供目前網路出口
- macOS 實體網路介面卡route 命令顯示實際 interface
- Mihomo TUN使用該介面傳送 DNS 與連線
- 目標網站完成解析、規則匹配和存取
自動檢測在第二步取得空值時，後續 DNS 與出站都會失敗；固定介面只適用於該日誌特徵。
用系統路由查出熱點正在使用的網路介面卡
先關閉 TUN，讓 macOS 回到可以直連的狀態，再在終端查詢一個公用網路位址的路由。命令輸出中的 interface 才是此刻真正承載熱點流量的實體網路介面卡，不要根據別人的截圖猜名稱。
route -n get 223.5.5.5只記錄本機實際結果
確認直連可用
關閉 TUN 和系統代理，用瀏覽器開啟一個普通網頁，避免讀到故障狀態下的路由。
尋找 interface 行
issue 報告者看到的是 en0，但 Wi-Fi、USB 網路介面卡和以太網可能得到不同名稱。
重複執行一次
斷開再連線手機熱點後重新查詢，確認介面名稱沒有變化再寫入覆寫。
在 Merge 裡只覆寫兩個欄位
Mihomo 的 interface-name 是頂層出站介面，auto-detect-interface 則放在 tun 下。開啟目前 Profile 的 Merge 或覆寫設定，只加入這兩個鍵；不要複製 issue 中的整段 TUN、DNS 或 IPv6 設定，以免把原來能用的設定一並替換。
interface-name: en0
tun:
auto-detect-interface: false這裡的 en0 只是示例。也不要把它寫到 tun.device：官方文件說明 macOS 的 TUN 裝置名以 utun 開頭，而 interface-name 指的是 Mihomo 實際向外傳送流量的介面，兩者用途不同。
重啟核心後先看日誌，再測 DNS 和網頁
儲存覆寫並透過設定驗證後，完整重啟一次核心，再開啟 TUN。先看新產生的日誌，不要只看開關顏色；介面錯誤消失後，再發起一次新的 DNS 查詢和 HTTPS 存取。
按同一順序驗證
重載目前設定
確認仍選中原 Profile 和原節點，不同時更換訂閱、DNS 或代理模式。
重新開啟 TUN
從本次啟動位置開始讀日誌，檢查是否還出現 <invalid> 或 interface not found。
發起兩類請求
先開啟一個普通網頁，再查看連線頁是否出現對應網域、規則和實際出口。
關閉 TUN 做對照
確認系統直連仍能恢復，避免把一次快取命中誤判為修復完成。
空介面與 interface not found 都消失，網頁恢復
固定介面已避開本次自動檢測失敗，繼續完成切網驗證。
仍提示 interface not found
介面名稱寫錯或已經變化，關閉 TUN 後重新查詢系統路由。
介面錯誤消失，但仍是 dns resolve failed
停止增加 DNS 欄位，撤銷覆寫後按獨立 DNS 問題檢查。
設定驗證失敗
檢查 interface-name 是否位於頂層，以及 tun 下的縮進是否為兩個空格。
固定介面後，切換網路要重新檢查
手動指定介面會停止自動檢測。它適合暫時穩定手機熱點環境，但從熱點切回家庭 Wi-Fi、USB 網路或以太網後，原介面可能不再是預設出口。若忘記更新，表現仍會是 TUN 開著卻無法建立新連線。
網路變化後的處理
| 查詢結果 | 處理 |
|---|---|
| interface 與覆寫值相同 | 保留目前設定，再測試 DNS 和網頁 |
| interface 已變成另一個名稱 | 關閉 TUN，更新 interface-name 後重啟核心 |
| 以後需要頻繁切換網路 | 刪除固定介面覆寫，恢復自動檢測並觀察問題是否重現 |
| 同時執行另一款 VPN 或 TUN | 先分別關閉測試，不用一個固定值掩蓋路由衝突 |
無效時刪除覆寫，退回原設定
如果固定正確介面後仍然失敗，說明目前故障不只來自自動檢測。不要繼續新增來源不明的 DNS、路由或指令碼設定，先恢復到修改前的 Profile。
完整還原順序
關閉 TUN
等待系統普通網路恢復，再修改 Merge，避免舊核心繼續佔用故障路由。
刪除兩個覆寫鍵
移除頂層 interface-name 和本次加入的 tun.auto-detect-interface，恢復修改前內容。
重新載入原 Profile
保持原節點和規則，用系統代理完成一次存取，確認基本連線仍可用。
保留脫敏日誌
記錄 macOS、用戶端和核心版本，以及開啟 TUN 後第一條錯誤，提交到對應官方 issue。
五項檢查確認熱點下的 TUN 已恢復
最終驗證清單
- 關閉系統代理、只開 TUN 時，瀏覽器與終端都能產生新連線
- 日誌不再出現 get empty name、<invalid> 或 interface not found
- 連線頁能顯示預期網域、規則與代理或直連出口
- 斷開並重新連線同一熱點後，介面名稱和覆寫仍然一致
- 關閉 TUN 後系統直連立即恢復，不需要重啟 Mac