Windows
適合桌面日常使用,可選擇 Clash Plus、Clash Verge Rev、FlClash 或 Clash Nyanpasu。 安裝後需要確認系統代理權限;使用 UWP 應用程式時,也應檢查迴圈限制是否影響本機代理存取。
集中整理 Clash 用戶端安裝包、mihomo 核心設定與 YAML 規則分流資料。先依作業系統選擇圖形用戶端,再按照欄位說明匯入訂閱、檢查 DNS 行為並確認規則命中結果。
Clash 的請求處理不是單一開關,而是一條由監聽入口、DNS、規則比對、策略群組與出站連線組成的處理鏈。 下列索引依實際設定關係拆開說明,方便判斷某個欄位位於哪一層,以及修改後會影響哪些請求。
rules 是由上而下執行的有序清單。網域、IP、程序名稱與規則集都能作為比對條件;
一旦某條規則命中,核心便將請求交給該項目指定的策略群組、DIRECT 或
REJECT,後續項目不再參與判斷。因此,具體網域規則通常放在前面,範圍較大的
GEOIP、GEOSITE 與最終兜底規則則放在後面。
排查分流結果時,應先查看請求實際命中的規則,再檢查規則指向的策略群組,而不是直接更換節點。
常見偏差來自規則順序、網域後綴範圍、規則集未更新,或 DNS 回傳結果與 IP 類規則的預期不同。
設定欄位頁進一步列出 DOMAIN、DOMAIN-SUFFIX、
IP-CIDR、MATCH 等語法及其適用範圍。
策略群組位於規則與代理節點之間。手動選擇群組適合需要固定出口的情境;自動測試群組會依照設定中的探測網址、 間隔與容錯值選擇可用項目;故障轉移群組則依成員順序尋找能夠連線的出站。策略群組也能包含另一個策略群組, 藉此將地區、用途與切換方式拆成清楚層級,減少在規則檔中重複列出節點名稱。
設定時需要同時核對 type、成員來源、健康檢查與引用名稱。規則中的策略名稱必須與
proxy-groups 中的名稱逐字對應;節點經訂閱更新後,若群組成員依賴固定名稱,也可能出現舊名稱失效。
對多數圖形用戶端而言,日常切換只會改變策略群組目前選項,不會重寫原始訂閱內容。
DNS 模組負責接收應用程式查詢、選擇上游伺服器,並將網域結果交給後續規則判斷。啟用
fake-ip 時,核心會先從保留位址池回傳映射位址,應用程式建立連線後再依映射關係還原原始網域,
以保留網域規則所需的資訊。部分區域網路裝置、連線檢測與依賴真實位址的程式,可透過
fake-ip-filter 設定例外。
DNS 故障通常需要區分「網域無法解析」與「解析成功但連線失敗」。檢查順序包括監聽位址、預設解析器、 代理伺服器網域的解析路徑、加密 DNS 的可達性,以及系統是否仍將查詢送往其他介面。只修改上游位址未必能解決問題, 因為啟動階段解析、規則判斷與代理鏈路可能使用不同的伺服器集合。
閱讀 DNS 與 Fake-IP 術語 →圖形用戶端通常會保存遠端訂閱、本機設定副本與目前的執行設定。訂閱更新負責取得服務提供者發布的節點與基礎策略; 本機覆寫用於追加 DNS、規則或介面相關設定;執行設定則是用戶端完成合併後交給核心的最終結果。 三者不是同一個檔案,直接編輯快取副本可能在下次更新時被取代。
維護設定時,應先確認用戶端支援的覆寫方式,再決定使用前置、後置或欄位級合併。YAML 縮排必須保持一致, 同名鍵的覆寫規則由用戶端實作決定,陣列欄位也可能採用取代而非追加。匯入失敗時先用最小設定驗證語法, 再逐段恢復代理、策略群組、DNS 與規則,可以更快定位不相容欄位。
查閱覆寫與合併方法 →首頁只提供平台入口。安裝包格式、用戶端差異、系統需求與停止維護狀態集中列於下載頁, 避免將不同架構的檔案混在同一處。進入對應標籤後,再依裝置架構與使用方式選擇用戶端。
適合桌面日常使用,可選擇 Clash Plus、Clash Verge Rev、FlClash 或 Clash Nyanpasu。 安裝後需要確認系統代理權限;使用 UWP 應用程式時,也應檢查迴圈限制是否影響本機代理存取。
Apple Silicon 與 Intel 裝置應下載相應架構版本。首次啟動可能需要在系統設定中確認網路延伸功能或代理權限; 如果選單列已顯示連線狀態但請求未經過核心,應進一步核對系統代理與增強模式設定。
可選擇 Clash Plus、Clash Meta for Android、FlClash 或 Surfboard。匯入訂閱後,系統會要求建立 VPN 連線;省電策略、背景限制與廠商網路管理功能可能中斷常駐連線,需要依裝置系統個別確認。
iPhone 與 iPad 可從 App Store 取得 Clash Plus。首次連線需要授權加入 VPN 設定; 匯入訂閱後先選擇策略,再啟動連線。系統狀態列出現 VPN 標記只代表通道已建立,實際存取結果仍取決於規則與出站。
桌面環境可使用 Clash Verge Rev 或 FlClash;伺服器、路由器與容器環境通常直接部署 mihomo 核心。 選擇檔案時應區分軟體包格式與 CPU 架構,並自行設定服務管理、工作目錄與設定檔讀取權限。
判斷用戶端是否適合目前裝置,需要分清圖形介面、代理核心與設定格式三個層次。 它們可以由不同專案維護,但透過相近的設定結構與控制介面協同運作。
Clash 生態形成了一套廣泛使用的設定模型:代理節點由 proxies 描述,策略選擇由
proxy-groups 組織,請求依據 rules 依序比對,DNS 模組則負責解析與網域映射。
原始 Clash 專案停止持續開發後,社群分支繼續擴充相容欄位,其中 mihomo 是目前常見的維護中核心之一。
因此,許多新用戶端介面雖然名稱不同,底層仍圍繞相近的設定結構、控制介面與規則語義運作。
Clash Plus、Clash Verge Rev、FlClash 與其他圖形用戶端主要負責訂閱管理、設定切換、系統代理控制、 日誌查看與核心生命週期管理。真正執行 DNS 處理、規則比對與出站連線的是用戶端內建或呼叫的核心。 遇到問題時先判斷故障位於介面層還是核心層:介面無法儲存設定屬於用戶端行為,設定解析失敗通常與欄位或核心相容性有關, 連線建立後特定網站仍走錯出口,則應檢查規則與策略群組。
開源儲存庫中的提交歷史、版本發布、問題討論與設定文件可以交叉核對。比起只看用戶端名稱, 更有效的判斷方式是確認近期提交是否持續、安裝包是否涵蓋目前架構、核心版本是否支援設定中使用的欄位, 以及重大變更是否附帶遷移說明。Clash中文站在用戶端比較頁區分維護中專案與封存專案, 下載頁也將停止維護狀態直接標示在對應卡片上,方便在安裝前完成選擇。
用戶端升級、核心升級與訂閱更新是三種不同操作。用戶端升級可能改變介面或覆寫機制,核心升級可能新增或調整欄位, 訂閱更新則主要替換節點與服務方提供的規則。執行變更前應匯出目前可用設定,記錄正在使用的策略模式, 再一次只更新一個層次。若出現解析錯誤,可回到舊設定並根據日誌中的欄位位置逐項修正,而不是同時替換用戶端、核心與訂閱。
下列問題用於完成首次判斷。涉及完整欄位、用戶端差異或逐步排障時,應繼續進入對應的說明頁面, 以免在沒有日誌與設定脈絡的情況下直接修改多個設定。
Clash 通常指設定模型及其相關生態;mihomo 是持續維護的相容核心之一;Clash Plus、Clash Verge Rev、 FlClash 等則屬於圖形用戶端。圖形用戶端負責設定與系統整合,核心負責解析、比對與連線。 可在術語手冊中查看更完整的層次說明。
先確認基礎網路可用,再依序檢查用戶端是否啟動核心、系統代理或 VPN 權限是否生效、策略群組是否選取可用出站、 DNS 是否能夠解析,以及請求最終命中了哪條規則。不要一開始同時修改 DNS、模式與訂閱, 逐層檢查更容易保留有效線索。完整順序請見說明中心故障排查。
規則模式依設定檔中的規則決定每個請求的去向,適合一般使用;全域模式會將大部分請求交給指定策略, 適合暫時驗證代理鏈路;直連模式主要用於確認問題是否由代理路徑造成。排查結束後通常回到規則模式, 並透過日誌確認關鍵網域命中預期策略。
遠端訂閱更新通常會取代本機快取副本。需要長期保留的 DNS、規則或策略調整,應寫入用戶端支援的覆寫檔或合併設定, 而不是直接編輯訂閱快取。不同用戶端對陣列追加、同名鍵覆寫與腳本覆寫的支援並不完全相同, 應先查閱覆寫與合併章節。
需要繼續定位安裝、訂閱、開機自動啟動、Fake-IP 或 UWP 迴圈問題時,前往 說明中心查看分類問答 →
文章依具體任務展開,重點記錄可重現的檢查順序、欄位範圍與平台差異。 閱讀時可先完成基礎檢查,再根據日誌與設定現象進入對應章節。