Clash 常見問題與故障排除

Clash 是一套以規則分流與策略組為核心的代理設定架構。核心負責讀取設定、建立連線，以及執行 DNS 與路由規則；圖形化用戶端則負責匯入訂閱、切換模式、檢視日誌與控制系統代理。選擇用戶端時，應一併確認使用的核心、支援的作業系統範圍，以及設定欄位的相容性。

原版 Clash 奠定了設定結構與規則模型，Clash Meta 在此基礎上擴充協定、DNS、規則與透明代理功能，後續專案名稱則調整為 mihomo。許多新用戶端採用 mihomo 核心，但介面名稱仍保留 Clash。常用的基礎欄位通常可以繼續使用，擴充欄位則需要相應核心支援。

日常使用建議優先選擇規則模式，由網域、IP 與規則集決定直連或代理。全域模式會將大多數連線交由目前選定的策略處理，適合暫時確認某個節點是否可用，但不宜長期用作排障依據。直連模式會繞過代理，適合確認問題是否由代理鏈路或設定規則造成。

用戶端本身主要提供設定解析、規則分流與連線管理功能，不等同於訂閱服務。訂閱網址、節點可用性、流量額度與到期日由相應服務提供者管理。匯入來源不明的公開設定前，應了解其維護狀態、資料處理方式與使用條件，並避免在不可信的連線中傳送敏感資訊。

訂閱通常是可更新的遠端網址，會回傳完整設定或節點集合；設定檔是用戶端實際載入的 YAML 內容，其中也可能包含 DNS、規則與策略組；節點則只是設定中的連線項目。訂閱更新時會重新產生或覆寫相關內容，因此若要長期自訂規則，應使用覆寫功能或保留獨立副本。

先確認匯入結果是否顯示成功，再查看設定清單中是否確實產生新設定。若設定存在但策略組為空，常見原因包括訂閱回傳空內容、連結已失效、回傳的是網頁而非設定、用戶端不支援該訂閱格式，或設定解析在某個欄位中斷。應搭配更新紀錄與核心日誌，找出具體的錯誤行。

先在瀏覽器或服務提供者的控制台確認訂閱網址仍有效且未過期，再檢查系統時間、網路連線與網址是否完整複製。接著查看用戶端更新日誌，區分連線逾時、憑證錯誤、權限拒絕與 YAML 解析失敗。若舊設定仍可使用，應先保留舊副本，不要在問題尚未定位前連續刪除所有設定。

TUN 模式需要建立虛擬網路介面並修改系統路由，因此通常需要系統管理員權限或已安裝相應服務。Windows 可檢查服務模式是否正確安裝；macOS 需確認系統延伸功能或網路權限；Linux 則要檢查執行使用者權限、TUN 裝置與相關能力設定。修復權限後，應完全退出用戶端再重新啟動。

先確認瀏覽器是否使用獨立的代理設定、擴充功能或安全軟體接管網路。接著檢查系統代理位址與連接埠是否和用戶端監聽連接埠一致，並確認核心正在執行。部分應用程式不會讀取系統代理，需要使用應用程式內代理、TUN 模式或其他系統層級的接管方式；僅開啟介面開關，不代表所有程式都會經過代理。

部分 UWP 應用程式受到本機回環隔離限制，無法直接連線至執行於本機位址上的代理連接埠。可在支援此功能的用戶端中開啟 UWP 回環工具，勾選需要連網的應用程式後儲存。設定完成後重新啟動目標應用程式；若應用程式更新後識別資訊有所變更，可能需要再次確認勾選狀態。不要一次選取所有無關的系統元件。

全域模式通常使用名為 GLOBAL 的策略組，但實際名稱可能因設定而異。進入代理或策略頁面，確認該組目前指向具體節點，而不是仍指向無法使用的自動選擇組。選擇時不要只看單次延遲結果，也應測試目標網站、連線穩定性與持續傳輸表現；完成驗證後即可切回規則模式。

延遲測試通常只會驗證至指定測試位址的短連線，不能代表 DNS、TLS 與目標網站的鏈路都正常。應依序檢查策略組是否選取該節點、DNS 是否回傳可用位址、規則是否將目標網域分配至預期策略，以及節點是否限制特定協定。日誌中的規則命中、連線錯誤與 DNS 紀錄，比單次延遲數值更具參考價值。

開啟用戶端的連線紀錄或即時日誌，再造訪目標網站，查看網域、目標位址、命中規則與最終策略。現代網頁通常會同時請求主網域、靜態資源網域與第三方介面，因此需要檢查多條連線。若結果不符合預期，應調整規則順序或覆寫內容，而不是只修改策略組名稱。

遠端訂閱更新通常會重新寫入訂閱設定，直接編輯其中的規則、DNS 或策略組可能會被覆寫。優先使用用戶端提供的覆寫、擴充腳本、合併設定或本機規則集功能；若用戶端不具備這些功能，應複製出獨立的本機設定並記錄來源。修改前保留可正常執行的版本，方便在解析失敗時回復。

行動裝置持續執行 VPN 或 TUN 介面會消耗一定電量。可避免將健康檢查間隔設得過短，減少同時啟用大量頻繁更新的規則與日誌，並依實際需求選擇協定與模式。Android 另需檢查電池最佳化、背景執行與常駐通知權限；iOS 的背景行為由系統統一管理，網路切換後可重新確認連線狀態。

先切換至直連模式，確認基礎網路正常，再回到規則模式檢查目前設定是否成功載入。接著確認策略組沒有選到失效節點，且系統代理或 TUN 狀態符合預期，並觀察存取時是否產生連線日誌。如果日誌完全沒有新紀錄，問題多半是流量未進入用戶端；若有錯誤紀錄，則繼續從 DNS、規則與節點鏈路定位。

先使用同一份設定中的多個節點進行測試。若全部逾時，應優先檢查本機網路、DNS、系統時間、防火牆與用戶端監聽狀態；若只有個別節點逾時，則較可能是節點位址、連接埠或線路異常。也可以切換網路環境後重新測試。連續快速點擊延遲測試會造成額外並行連線，建議等待一輪結束後再比較結果。

先找到用戶端日誌目錄，確認是介面程序崩潰，還是核心啟動失敗。常見原因包括最後匯入的設定語法錯誤、設定目錄權限異常、核心檔案遺失、舊版本殘留程序佔用連接埠，以及系統元件不符合要求。可暫時移開最近使用的設定後重新啟動，但不要直接清空所有資料，日誌與舊設定有助於復原。

記下日誌提供的行號與欄位名稱，先排查縮排、冒號、引號、重複鍵與清單格式。若語法本身正確，但日誌提示未知欄位，通常表示目前核心版本不支援該擴充設定。可更新至相容核心、請訂閱提供者調整格式，或移除不相容欄位。不要為了繞過單一錯誤，就盲目刪除整個 DNS 或規則區塊。

先確認本機網段是否被規則設為直連，並檢查 TUN 路由是否涵蓋區域網路位址。常見私有網段與 localhost 通常應維持直連，但實際網路也可能使用自訂位址範圍。若需要讓其他裝置存取本機代理或開發服務，還要檢查是否允許區域網路連線、監聽位址與系統防火牆；開放連接埠前應先明確限定存取範圍。