Clash 常見問題與故障排查

mihomo 是負責解析設定、建立代理連線、執行規則比對及處理 DNS 的核心。Clash Verge Rev、Clash Plus 等圖形化用戶端提供訂閱管理、策略選擇、日誌檢視與系統代理開關，並在背景呼叫核心。用戶端介面相近，不代表使用的核心完全相同；判斷功能相容性時，應同時查看用戶端說明、核心類型與設定語法。

規則模式會依設定中的順序由上而下比對規則，並將不同請求交給指定的策略群組、DIRECT 或 REJECT，適合日常使用。全域模式通常會將流量統一交給 GLOBAL 策略群組，方便暫時測試節點。直連模式會略過代理轉送，常用於確認問題是否來自用戶端。切換模式不會自動改寫訂閱中的規則內容。

設定檔是用戶端實際載入的 YAML 內容，通常包含代理、策略群組、規則、DNS 與連接埠設定。訂閱連結是取得遠端設定的網址，用戶端會依需求下載並儲存為本機設定。遠端訂閱更新可能會覆蓋本機修改，因此若要長期自訂規則，應使用覆寫功能、合併設定或另行維護本機檔案。

系統代理適合瀏覽器及會主動讀取作業系統代理設定的應用程式，開啟與關閉都較直接。TUN 模式透過虛擬網路介面接管更廣泛的流量，適合不遵循系統代理的應用程式、命令列工具或部分遊戲。首次使用時，建議先確認系統代理正常，再視需要啟用 TUN；兩者同時開啟時，也要留意路由、DNS 與其他網路工具之間的衝突。

先依作業系統選擇仍在維護且支援目前架構的用戶端。Windows 需區分常見的 x64 環境，macOS 需區分 Apple Silicon 與 Intel，Android 安裝包則可能依 ARM 架構拆分。一般使用者優先選擇具備圖形介面、訂閱管理與系統代理控制功能的用戶端；伺服器與路由器情境才較適合直接執行 mihomo 核心。

先在服務提供者的頁面確認連結仍有效，且複製時沒有帶入多餘空格，再用瀏覽器檢查該網址是否能回傳內容。若回傳登入頁、錯誤頁或空白內容，問題通常出在訂閱網址或帳戶狀態；若能回傳內容但用戶端解析失敗，應檢查格式是否為 Clash 或 mihomo 可識別的 YAML。也可以先關閉代理後重新取得，避免舊規則讓訂閱請求繞到無法使用的出口。

TUN 模式需要建立虛擬網路介面並修改系統路由，因此通常需要管理員權限。Windows 可依用戶端說明安裝服務模式，或以管理員身分完成首次設定；macOS 需要核准網路擴充功能或輸入系統憑證；Linux 則需檢查 CAP_NET_ADMIN、裝置權限與服務設定。授予權限後，應完全退出用戶端並重新啟動，再確認虛擬介面是否成功建立。

部分 UWP 應用程式預設受到回圈存取限制，即使系統代理已開啟，也可能無法連線至本機監聽連接埠。可使用用戶端提供的 UWP 回圈工具，勾選目標應用程式的回圈豁免後儲存。若用戶端沒有此入口，可透過 Windows 的 CheckNetIsolation 工具處理。修改後重新啟動目標應用程式，並確認 Clash 的混合連接埠與系統代理連接埠一致。

在設定或訂閱頁面選擇對應項目執行更新，等待下載完成後，再切換或重新載入該設定。節點、策略群組與遠端規則通常會隨訂閱一併更新，而用戶端層級的設定一般會獨立儲存。直接編輯訂閱產生的 YAML，容易在下次更新時被覆蓋；需要長期保留的 DNS、規則與策略調整，應放入用戶端支援的覆寫、腳本或合併設定中。

不一定。延遲測試取決於指定的測試網址、逾時時間與目前的網路環境；測試網址遭到封鎖、DNS 解析失敗或節點禁止探測時，也會顯示逾時。可以先切換至該節點，再存取穩定的 HTTPS 頁面並查看連線日誌。若實際請求成功但測試仍逾時，應更換測試網址；若實際連線也失敗，再檢查節點資訊、裝置時間與網路限制。

規則會依設定中的順序由上而下比對，命中第一條後通常不會繼續比對。較寬泛的 DOMAIN-SUFFIX、GEOIP 或 GEOSITE 規則若放得太前面，可能會覆蓋後方的精確規則。排查時，先在連線詳細資訊中查看目標網域、解析後的位址、命中的規則與最終策略，再調整規則順序。新增自訂規則後，也要確認已載入修改後的設定，而不是仍在使用舊設定。

應讓網域解析路徑與分流策略保持一致。啟用用戶端 DNS 後，確認 nameserver、proxy-server-nameserver、fallback 或 nameserver-policy 的用途清楚，並避免系統中的其他 DNS 工具重複接管請求。TUN 情境還要檢查 DNS 劫持與虛擬網卡設定。出現解析異常時，先比較系統解析結果與用戶端日誌中的結果，再清除系統 DNS 快取並重新載入設定。

先確認用戶端正在執行、設定已載入，且系統代理指向用戶端目前監聽的位址與連接埠。接著檢查瀏覽器是否使用獨立的代理設定，或有擴充功能、安全軟體覆寫系統設定。可以存取本機連接埠確認監聽狀態，再查看 Clash 日誌中是否出現瀏覽器請求。若日誌完全沒有請求，應優先排查瀏覽器與系統代理；若有請求但失敗，再檢查規則、節點與 DNS。

先切換同一訂閱中的其他節點，判斷是單一節點問題，還是所有節點都失敗。接著更新訂閱，檢查節點伺服器位址是否能解析、裝置日期與時區是否正確，並暫時關閉其他代理或 VPN 工具。若所有節點都逾時，可改用另一個基礎網路進行測試；若只有特定協定失敗，應檢查用戶端核心是否支援該協定及其參數。最後結合日誌中的 DNS、connect timeout 或 handshake 訊息定位問題發生的階段。

先關閉 TUN，確認基礎網路與系統代理模式是否正常，再重新啟用以縮小問題範圍。重點檢查虛擬網卡是否建立、預設路由是否被其他 VPN 或安全軟體改寫、DNS 是否指向可用的解析器，以及區域網路網段是否被錯誤接管。Windows 也可檢查服務模式狀態，macOS 則可重新核准網路擴充功能。修改設定後，應退出相關網路工具並重新啟動用戶端。

啟動階段出現 address already in use，通常表示混合連接埠或控制連接埠已被其他程序佔用，需要關閉佔用程式或更換連接埠。請求階段出現 DNS timeout、no such host 或解析伺服器錯誤時，應檢查 DNS 設定與目前網路。若連線記錄中能看到規則名稱與策略群組，便可判斷流量是否走錯分支；若出現 connect timeout 或 handshake failed，則繼續檢查節點連通性、協定參數與裝置時間。