Clash 常見問題

Clash 是代理核心及相關生態系的名稱，ClashX 是 macOS 用戶端的名稱，mihomo 則是持續開發的相容核心。用戶端負責選單、訂閱管理與系統整合，核心負責連線、DNS 與規則處理。不同用戶端搭配的核心、維護狀態及功能入口各不相同，不能只憑名稱判斷是否支援 TUN 或特定通訊協定。選擇時請先確認專案說明與核心資訊，再依照對應用戶端的文件操作。

用戶端提供連線與分流功能，但不會自動附帶可用的代理服務。遠端訂閱通常包含節點、策略群組與規則；也可以使用自行維護的本機 YAML 設定檔。匯入前請確認來源可信、服務仍在有效期限內，且輸出格式與目前使用的核心相容。訂閱連結中的權杖通常具有存取權限，請勿公開截圖或傳送至公開的轉換網站。本站範例網址僅用來說明填寫方式，無法用於實際連線。

日常使用通常可從規則模式開始，連線會依照設定檔中的規則順序選擇出站策略。全域模式會將核心處理的連線交由全域策略處理，但不代表所有應用程式的流量都已接管；系統代理或 TUN 仍須正確啟用。直連模式則會略過代理出站，適合用來比對排查。切換模式後請建立新連線測試，既有的長連線可能仍沿用原本路徑，不宜只重新整理同一個頁面就下結論。

系統代理會向作業系統登錄本機代理位址，主要影響遵循該設定的應用程式。TUN 透過虛擬網路介面接管符合路由條件的流量，涵蓋範圍通常較廣，但須仰賴權限、路由與 DNS 設定。兩者不一定要同時啟用，也無法保證接管所有網路情境。初次設定時，可先確認系統代理正常，再依遊戲、命令列工具或其他應用程式的實際需求啟用 TUN，避免同時變更多種接管機制，增加排查難度。

延遲測試只能表示當時透過指定節點成功探測某個測試位址，無法證明所有網站、通訊協定與連接埠都能存取。實際瀏覽情況還取決於策略群組選擇、規則命中、DNS 解析及目標網站的限制。請同時查看連線記錄中的目標網域、命中規則與實際出站，再用目標應用程式發出新請求。不要只挑延遲最低的節點；能否穩定完成連續請求，比單次測試結果更有參考價值。

在用戶端的訂閱、設定檔或 Profiles 頁面新增遠端設定，貼上完整 URL，儲存後下載並選取該設定檔。不同用戶端的入口名稱可能不同；儲存成功不代表設定檔已啟用。若出現解析失敗，請確認服務提供者輸出的是相容的 Clash YAML，而非網頁、單一節點連結或只有 Base64 節點字串的內容。優先使用服務提供者提供的相容格式入口；若必須轉換，請留意權杖外洩與規則遭改寫的風險。

先確認核心正在執行，核對用戶端顯示的本機監聽位址與混合連接埠，再檢查 Windows 代理設定中的位址和連接埠是否相同。不要預設所有設定都使用 7890。接著檢查瀏覽器擴充功能、個別代理設定及代理略過清單，避免覆蓋系統設定。開啟新頁面並查看用戶端連線記錄；若完全沒有新連線，請優先排查流量接管；若已有記錄，再確認規則與策略群組實際採用的出站。

先將 App 移至「應用程式」資料夾，再依照目前用戶端的提示完成首次啟動。只有使用相關實作方式時，才可能出現網路擴充功能、輔助服務或鑰匙圈授權提示；並非所有 ClashX 用戶端都會出現相同提示。系統設定中的允許入口會隨 macOS 版本而異，可查看「隱私權與安全性」及網路相關設定。授權前請確認要求來自剛安裝的 App；若先前曾拒絕授權，請依專案文件重新觸發，不要直接關閉系統安全機制。

先關閉 TUN，確認用戶端支援目前系統的流量接管方式，再檢查服務模式、輔助服務或網路擴充功能是否已安裝並取得授權。Windows 用戶端可能需要安裝系統服務；Linux 通常涉及服務權限或網路管理能力；macOS 則依實作方式使用已授權的輔助程式或擴充功能。請只依目前專案的說明授予必要權限，不要反覆以管理員身分啟動來取代故障排查。完成授權後重新啟用 TUN，並檢查介面、路由與啟動記錄。

行動裝置通常透過系統 VPN 介面接管流量，首次連線時須確認系統授權。先檢查是否有其他 VPN、廣告過濾或防火牆 App 正在使用相同功能，然後中斷其他連線再試一次。Android 也請檢查永遠開啟的 VPN、封鎖未使用 VPN 連線的設定，以及背景電池限制；iOS 則請檢查既有 VPN 設定與隨選連線設定。先確認設定檔已啟用且策略群組有可用節點，再處理授權問題，避免把訂閱錯誤誤認為系統權限問題。

在訂閱設定中選擇合適的更新間隔，並確認用戶端是否必須保持執行才能執行排程工作。裝置進入睡眠或網路受限時，更新可能會延後。遠端設定通常會在更新時整份取代，直接編輯其中的規則可能導致修改遺失；若有長期自訂需求，建議使用用戶端支援的覆寫、合併或規則擴充功能。更新前請保留可用的設定檔副本，更新後核對策略群組名稱與目前選項，特別留意服務提供者刪除或重新命名節點的情況。

select 策略群組適合手動指定出站；url-test 會依探測結果選擇節點；fallback 則依設定順序尋找可用節點。這些群組仰賴設定檔中的測試位址、間隔與候選清單，名稱相似不代表行為相同。先確認規則實際指向哪個群組，再檢查該群組內是否還有其他巢狀策略群組。排查時可暫時固定使用已確認可用的節點，減少自動切換造成的變數；恢復日常使用後，再調整自動群組的候選範圍。

規則會依順序比對，通常採用第一條符合的結果，因此請檢查連線是否已被前面的廣泛規則或兜底規則提前接走。網域規則也取決於核心能否取得網域資訊；程序規則則會受平台與程序辨識能力影響。先在連線詳細資料中查看實際目標、命中規則與出站，再修改對應規則；不要只因設定檔中有某條規則，就認定它一定會生效。儲存並重新載入後，請用新連線驗證；遠端設定則建議透過覆寫保留修改。

Fake-IP 會回傳虛擬位址給應用程式，再由核心於後續連線中對應網域；它並非真實伺服器位址。若區域網路裝置、特定 App 或網域解析出現相容性問題，請先確認相關請求是否進入核心，以及使用哪個 DNS。對於確認不相容的網域，可依目前核心的語法加入 fake-ip-filter，再按照用戶端說明重新載入並清除相關 DNS 快取。不要將所有網域都加入過濾清單；切換 DNS 模式前，請先備份設定檔並記錄原本設定。

先記下問題發生時間、系統版本、用戶端與核心資訊，再暫時調整記錄等級至足以重現問題的程度，通常可先從 info 開始。只匯出故障時間附近所需的片段，提交前檢查訂閱 URL、權杖、認證欄位、節點位址與個人使用的網域。不要直接公開完整設定檔或整張訂閱頁面截圖。排查結束後請恢復常用記錄等級，刪除為重現問題而產生的敏感副本，避免長期記錄不必要的瀏覽細節。

先確認連結完整且沒有多餘空格，再查看更新記錄。401 或 403 通常與憑證或存取權限有關；404 可能是入口已變更；429 表示請求受到頻率限制。仍須依服務提供者的說明判斷這些狀態碼。連線逾時則應檢查目前網路、DNS，以及下載訂閱時使用的出站方式。若回傳內容是登入頁面或錯誤網頁，用戶端也可能因此顯示解析失敗。避免連續重複更新；確認服務仍在有效期限內後，再依服務提供者說明重新產生或取得連結。

先關閉其他代理工具，確認基本網路正常，再固定使用一個節點連線至明確的測試目標。查看記錄中的失敗目標：如果是節點伺服器位址，請優先檢查節點狀態、網域解析、連接埠及本機網路限制；如果是目標網站，則搭配出站策略繼續排查。可更換節點與網路交叉測試，每次只變更一個條件。單一節點逾時不代表整份訂閱失效，也不要為了消除逾時而直接關閉系統防火牆。

建議先重新開啟原本的用戶端，關閉系統代理與 TUN，再正常結束程式，確認網路是否恢復。若 App 無法啟動，可到作業系統的代理設定中清除殘留的本機代理，並檢查是否仍有手動 DNS 或 VPN 設定。不要移除公司或機構網路要求的代理或 DNS；不確定時請先記下原本設定。若曾執行多個代理工具，應逐一確認流量接管狀態。必要時重新連線並清除 DNS 快取，恢復後再單獨啟動一個用戶端進行確認。

部分受到 AppContainer 隔離的 App 無法直接存取本機迴圈代理，即使瀏覽器能上網也可能連線失敗。先確認受影響的 App 確實使用系統代理，再使用用戶端提供的 UWP 迴圈工具查看 App 清單，只為需要存取本機代理的 App 設定豁免。相關操作可能需要管理員授權，設定後請重新啟動目標 App。並非所有市集 App 都採用相同的網路架構；若問題仍未解決，請繼續檢查其個別代理、DNS 與記錄，不要一次替所有 App 開放權限。

GeoIP 更新失敗時，先查看記錄中的下載位址、網路錯誤與檔案存取權限，再確認設定使用的是 GeoIP 資料庫，還是其他地理規則資料格式；不同資料檔案不能任意替換。若記錄顯示 address already in use，代表本機連接埠繫結失敗，請檢查是否有其他用戶端或重複的核心正在執行。關閉重複程序，或修改監聽連接埠並同步更新系統代理設定。這兩類錯誤發生在不同環節，不要靠反覆匯入訂閱來處理。