Clash Verge Rev
先找出失敗的層次，再修改設定。網頁無法開啟，可能是名稱解析、連線、TLS 憑證或應用層回應的問題。第一步是判斷失敗位置，以及該次請求是否真正經過 Clash Verge Rev。瀏覽器正常，不代表另一個應用程式採用相同解析器或路徑。
本文適用於 Windows、macOS 和 Linux 桌面環境，是依公開文件整理的診斷方法，並非所有環境均經實測的保證。介面名稱可能隨版本改變；受公司或學校管理的 DNS、VPN 和安全策略應由管理員處理。
一、修改前建立可比較的記錄
選擇一個獲准存取、能穩定重現問題的目標。記錄客戶端與核心版本、作業系統、目前設定名稱、系統代理及 TUN 狀態、出錯應用程式、時間和完整錯誤文字。不要同時更新訂閱、切換節點和修改 DNS，否則恢復後也無法知道原因。
對同一目標記錄瀏覽器、原應用程式及客戶端連線記錄的結果。必要時可在另一個獲准使用的網絡比較，但其餘條件應保持不變。不要將敏感內網網域交給公共 DNS 或公開檢測網站查詢。
二、把錯誤分成四層
- 解析逾時或找不到主機：先確認解析器、可達性、hosts 與快取；一次逾時不等於 DNS 污染。
- 有位址但連線逾時：檢查目標服務、路由、節點和防火牆。能解析不代表能連線。
- TLS 或憑證錯誤：核對系統時間、網域、信任鏈及中間設備，不要關閉憑證驗證來掩蓋問題。
- 收到 HTTP 403、404 或 429：請求已到達某個 HTTP 回應端，但可能是目標、代理或閘道，仍須辨識來源。
這是工作上的分類，不是所有錯誤碼的唯一解釋。只有一個網站失敗時，應保留該目標的證據，不要立刻重設整台電腦的網絡。
三、確認誰在解析，以及流量走哪裏
用連線記錄和日誌確認流量是否進入核心。應用程式不一定遵循系統代理；TUN 路由與 DNS 接管也要分開驗證，不能只看到開關已啟用便認定所有查詢已被接管。
nslookup example.com 只反映該工具發出的查詢，不等於瀏覽器快取或每個應用程式的解析行為。Firefox 的 DoH 設定是另一項變數。核心處理流程與接管限制，可對照文末的 Mihomo 資料。
四、Fake-IP 的特殊位址未必有問題
Fake-IP 可以回傳映射位址，而不是目標的公開位址。看到 198.18.x.x 時，先與目前 fake-ip-range 比較，不要只因位址陌生就判定污染或寫入系統 hosts。
應問的是：後續連線是否仍進入負責這個映射的核心？應用程式走另一條路、舊快取未失效，或切換設定後重用舊連線，都可能造成「有解析結果但連不上」。這些是假設，必須用日誌核實。
如果只有特定應用程式出錯，先保留設定副本，再檢查相容性。只有證據顯示需要例外時，才為必要網域設定例外；不要整段覆蓋 DNS 或排除所有網域。
五、DoH 與 IPv6 要比較，不要一鍵關閉
使用獨立 DoH 的瀏覽器，可能與命令列得到不同結果。一般 53 連接埠的 DNS 接管，不等於解密 HTTPS 裏的 DNS。先記錄安全 DNS 與管理策略；若獲准暫時對照測試，完成後恢復原設定，不應預設永久停用加密 DNS。
IPv6 要區分「得到 AAAA 記錄」及「有可用的 IPv6 路徑」。Mihomo 的 dns.ipv6 控制 AAAA 回應，並非作業系統全域 IPv6 開關。確實觀察到兩種位址路徑結果不同後，再檢查路由、節點支援及應用程式選路。
六、用明確指定代理的測試縮小範圍
以下例子需要已啟用的本機 SOCKS 或混合監聽。將 PORT 換成實際顯示的連接埠，並使用獲准且不含權杖的測試網址。不要為了套用例子而開放區域網絡。
curl --proxy socks5h://127.0.0.1:PORT --noproxy "" --connect-timeout 10 --max-time 20 -I https://example.comWindows PowerShell 可用 curl.exe 執行程式。socks5h 由 SOCKS 代理解析目標主機名稱；這只比較指定路徑，不會完全模擬原應用程式。伺服器不接受 HEAD 時，方法錯誤也不等於網絡失效。
指定代理成功、原應用程式失敗，優先檢查接管路徑與快取；兩者失敗則由核心日誌區分解析、節點連線與規則選擇；兩者偶爾正常則記錄休眠、網絡切換和連線重用的時間關係。
七、每個變更都要能還原
- 備份設定，只提出一個待驗證假設。
- 只修改相關設定，透過客戶端支援的方式套用並檢查錯誤。
- 重新開啟測試應用程式；如需處理快取，按對應文件操作，不要清空整個設定目錄。
- 重測原目標、正常對照目標與原應用程式。
- 無改善就還原；有改善則再測試重新啟動客戶端及重新連線。
如果解析器端點或代理節點網域本身無法解析，應檢查引導解析的相依關係。不要以關閉防火牆、略過 TLS 驗證或公開控制介面作為解法。
八、案例與求助資料
假設案例：瀏覽器正常、桌面應用程式逾時，而且核心沒有對應連線。下一步應確認應用程式是否遵循系統代理，以及 TUN 是否覆蓋它。指定代理測試成功會加強接入路徑的假設，但不代表應用程式本身必定沒有其他問題。
求助資料應包括版本、系統、模式、脫敏錯誤、重現時間和一組修改前後結果。移除訂閱完整網址、查詢參數權杖、節點憑證與控制密鑰。成功標準是原應用程式與對照目標均恢復，重新連線後仍正常，而不是只得到一次延遲數字。
延伸閱讀
參考資料
參考資料核對：2026-10-14。以下連結為專案及平台文件；本文為本站獨立編輯指南。