Clash Verge Rev macOS 開啟 TUN 後 DNS 失效怎麼辦？

Clash Verge Rev issue #8122 記錄一台 macOS 裝置在 v2.5.6、服務模式及 Mihomo v1.19.31 下的故障：一啟用 TUN，連原本能直接連線的網站也無法透過網域名稱開啟；回報者發現執行設定只剩 dns.enhanced-mode: redir-host。

該 issue 目前仍未關閉，只有一份詳細重現紀錄和少數類似回報，不能據此斷定所有 Mac 或所有訂閱都會受影響。

回報者最初推測，關閉「DNS 覆寫」後，應用程式移除了訂閱中的 dns。

專案成員在 issue 留言指出更具體的可能原因：基礎 config.yaml 留有不完整的 dns 區塊，產生執行設定時蓋過訂閱 DNS；殘留區塊缺少 enable: true，導致核心 DNS 無法使用。

官方擴充設定文件也指出，關閉 DNS 覆寫時，應用程式本身不會修改訂閱 dns。本文依照可檢查的殘留設定路徑排除故障，不把回報者最初的推測寫成專案結論。

適用前提是關閉 TUN 後，一般網路或同一節點的系統代理可用；開啟 TUN 後網域名稱解析失敗，而且基礎設定與執行設定確實有相應差異。

如果日誌首先出現 operation not permitted、get empty name、interface not found，或同一節點在系統代理模式也無法使用，應先排查權限、出口介面或節點，不要修改 DNS。

先關閉 TUN，確認 macOS 的一般網路是否立即恢復。若系統代理原本可用，可以暫時只使用系統代理；若退出用戶端後仍無法上網，再檢查系統網路設定是否殘留舊代理或 DNS，不要為了測試反覆開啟故障中的 TUN。

修改前，分別保存原始訂閱或 Profile、基礎 config.yaml、應用程式產生的執行設定，並記錄目前的用戶端與核心版本。

基礎設定通常位於 ~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/config.yaml。請透過本機應用程式目錄或檔案管理工具確認實際路徑。

不要把基礎設定與訂閱檔、dns_config.yaml 或產生的執行設定當成同一份檔案。

訂閱和設定可能含有節點憑證；備份應留在本機安全位置，公開回報時只使用已遮蔽敏感資訊的副本。

記錄同一網路下的三個狀態：關閉 TUN 時能否解析網域、開啟 TUN 後第一條 DNS 或 TUN 日誌，以及再次關閉後能否恢復。這樣才能判斷故障是否由 DNS 接管路徑觸發，而不是瀏覽器快取、節點失效或系統權限所致。

先檢查原始訂閱的 dns 是否完整，尤其是 enable: true、nameserver 及原有的其他解析設定。再檢查基礎 config.yaml 是否只留下 dns.enhanced-mode: redir-host 或類似的不完整欄位。

最後檢查應用程式產生的執行設定，是否與這個殘留區塊相似，而沒有保留原始訂閱的 DNS。尚未比對三份檔案前，不要只因「DNS 覆寫」開關關閉就刪除設定。

Mihomo 官方文件將 dns.enable 定義為是否啟用核心 DNS，並列出 nameserver 等解析欄位；TUN 的 dns-hijack 會將 DNS 查詢交由核心處理。

如果執行設定沒有可用的 DNS 路徑，但 TUN 仍接管查詢，網域名稱請求就可能失敗。這能解釋為何先前系統代理或一般直連可用，TUN 接管後卻無法開啟網站；是否屬於 #8122，仍須以本機設定差異判斷。

Clash Verge Rev 官方文件說明，自 v2.5.5 起，擴充設定寫入的 dns 欄位會依規則覆蓋對應值；設定、全域擴充、訂閱擴充與應用程式回寫都有先後順序。即使訂閱原文正確，後續來源仍可能改動最終結果。若基礎 config.yaml 沒有殘留區塊，應檢查自己的擴充設定與腳本，不能硬套這次 issue 的處理步驟。

只有三份檔案的比對支持上述原因時，才依照專案成員在 #8122 的建議處理。先完全結束 Clash Verge Rev，包括選單列處理程序；並確認已備份基礎 config.yaml。

再用文字編輯器，從該檔案移除確認殘留的頂層 dns 區塊，保留其他鍵值與訂閱原文。不要刪除整份 config.yaml、dns_config.yaml、Profile 或應用程式資料目錄，也不要直接修改會重新產生的執行設定。

儲存後重新啟動 Clash Verge Rev，先保持 TUN 關閉。檢查執行設定是否恢復訂閱原本預期的 DNS 欄位，並先通過設定檢查，再以系統代理進行一次真實 HTTPS 請求。這一層正常後，才短暫重新開啟 TUN 測試。

回報者曾把完整 DNS 放進全域 Merge 作為暫時繞行方式，但官方文件說明擴充設定會依優先順序覆蓋訂閱；直接複製他人的 DNS 或整組規則，可能覆蓋自己的區域網路、公司 DNS 與節點解析策略。本文不把全域 Merge 注入當成通用修復。若裝置受組織管理、設定由他人統一下發，先聯絡管理員，不要自行修改受管理設定。

先核對重新產生的執行設定：dns.enable、nameserver 應與預期的原始訂閱或擴充設定一致；不能只看介面上的 DNS 覆寫開關。接著固定同一個 Profile 與節點，分別在系統代理和 TUN 模式下請求同一個真實 HTTPS 網站，並從連線紀錄及日誌確認解析是否成功。

再完全退出並重新啟動一次應用程式，重複 TUN 測試；若只在這次工作階段有效，表示仍有設定來源在重新啟動時寫回。關閉 TUN 後也要確認一般網路恢復，不必重啟整台 Mac 才能上網。

不要只憑 DNS 檢測頁顯示某個位址、TUN 開關維持亮起，或延遲測試出現數字判定成功。目標網域能解析、網頁完整載入、連線紀錄符合預期，而且重啟後仍有效，才算完成驗證。

若移除殘留區塊後設定檢查失敗、原有分流被改動或 TUN 仍然斷網，先關閉 TUN，從修改前的備份還原基礎 config.yaml，再重新啟動應用程式。舊設定可能仍會觸發這次 DNS 故障，因此還原的目的是保存原設定與證據；暫時上網則使用已驗證可用的系統代理或不接管 DNS 的一般網路。

若執行設定已有完整 DNS，網域卻仍解析失敗，應另查 nameserver 本身是否可達、目前網路是否使用企業 DNS、是否有其他 VPN/TUN，以及第一條核心錯誤。不要為了消除錯誤訊息而關閉系統安全保護、清空全部 Profile、刪除整個應用程式資料目錄或隨機更換公共 DNS。

向 #8122 回報時，提供 macOS、Clash Verge Rev、Mihomo 版本，TUN／系統代理對照，三份設定中與 dns 相關的去識別化片段，以及重啟前後結果。回報者的解釋與專案成員的殘留設定判斷應分開記錄；目前沒有正式版公告能保證所有類似斷網都已修復。