Windows
以 Windows 裝置為主。可比較 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 與封存用戶端;安裝前先分辨圖形用戶端與獨立核心。
前往下載首頁僅負責平台分流,不在此列出安裝包清單。點選對應系統後會進入下載頁並自動切換至該平台;用戶端型號、適用架構、維護狀態與安裝方式都會在該頁說明。先確認裝置系統,再選擇圖形用戶端,比拿到不相容的套件後重新處理更省時間。
以 Windows 裝置為主。可比較 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 與封存用戶端;安裝前先分辨圖形用戶端與獨立核心。
前往下載依 Apple Silicon 與 Intel 架構選擇安裝套件。圖形用戶端適合日常使用選單列操作,獨立核心則更適合終端機、自動化或服務化部署。
前往下載適合手機與平板。下載前查看裝置架構及系統限制;匯入訂閱後還需授予本機 VPN 連線權限,系統的電池策略也可能影響背景連線。
前往下載透過應用程式商店取得 Clash Plus。安裝後從訂閱網址匯入設定,再依用途選擇策略組;系統跳出網路設定要求時,需明確確認。
前往下載桌面環境可選 GUI 用戶端;伺服器、軟路由與容器環境通常直接使用 mihomo 核心。先確認處理器架構,再決定使用 deb 套件或壓縮檔。
前往下載Clash 的難點通常不在開關本身,而在設定檔、策略組、規則與 DNS 彼此影響。以下依實際排查順序拆解:先確認流量符合哪條規則,再查看策略組選擇,最後檢查 DNS 與訂閱更新。左側切換主題,右側保留實際 YAML 或規則片段。
規則模式會由上而下檢查請求,符合後便立即停止繼續比對。網域規則適合指定服務,GEOIP 可處理地區歸屬,最後用 MATCH 接住其餘流量。實際設定時,將範圍較具體的規則放在前面,兜底規則放在最後;否則過於寬泛的規則會提前截走流量。相較於只有全域開關的用戶端,Clash 的價值在於能把直連、代理與攔截寫進同一份易讀的規則表,排查時也能從連線紀錄反推出符合的項目。
DOMAIN-SUFFIX,github.com,PROXY
DOMAIN-SUFFIX,local,DIRECT
GEOIP,CN,DIRECT
MATCH,Fallback
規則中的 PROXY 通常不是某個固定節點,而是策略組名稱。select 適合手動選擇,url-test 會依測試結果自動選取,fallback 則依可用性逐一回退。設定時應先確認 rules 引用的組名確實存在,再檢查組內節點或其他子組是否完整。將業務分類與具體節點解耦後,更換訂閱節點時不必重寫整套規則;這也是長期維護多份設定時最省事的結構。
proxy-groups:
- name: PROXY
type: select
proxies:
- Auto
- DIRECT
- name: Auto
type: url-test
Fake-IP 模式會先回傳保留位址,再由核心在連線階段還原原始網域並執行規則。這能讓網域規則更穩定地參與分流,但也要求系統 DNS、用戶端監聽連接埠與規則設定彼此一致。若出現區域網路裝置異常、特定軟體無法連線或解析結果繞過規則,應先檢查 fake-ip-filter、nameserver 與 respect-rules,而不是直接反覆更換節點。DNS 問題與代理節點問題應分開診斷。
dns:
enable: true
enhanced-mode: fake-ip
respect-rules: true
fake-ip-filter:
- "*.lan"
REJECT 用於直接拒絕符合條件的連線,適合處理已確認的追蹤網域、遙測端點或不希望存取的目標。規則範圍必須有所節制:優先使用精確網域或經過維護的規則集,避免寬泛的後綴誤傷登入、付款或訊息服務。若頁面只有部分載入失敗,先在連線紀錄中查找 REJECT 命中,再暫時切換規則進行驗證。攔截應可定位、可撤回,而不是靠堆疊模糊規則製造黑箱。
DOMAIN,telemetry.example,REJECT
DOMAIN-SUFFIX,tracker.example,REJECT
DOMAIN-SUFFIX,service.example,PROXY
MATCH,Fallback
訂閱連結通常會回傳完整設定,內容可能同時包含節點、策略組、規則與 DNS。匯入後應先查看更新結果,再確認目前啟用的是哪個 Profile,避免把「更新成功」與「已切換至新設定」混為一談。多個訂閱並存時,應依來源與用途命名,不要只保留預設名稱;修改遠端設定前,也要先確認用戶端是否會在下次更新時覆蓋本機變更。需要長期自訂時,可將覆寫層與遠端訂閱分開管理。
profile:
store-selected: true
store-fake-ip: true
mode: rule
log-level: info
「Clash」在實際使用中同時指向規則體系、設定格式、核心分支與多個圖形用戶端。將這些層次分開,才能判斷一篇教學究竟是在講介面操作、YAML 欄位,還是核心能力。
原版 Clash 將代理節點、策略組、規則路由與 DNS 納入統一的設定模型。許多用戶端沿用了這套思路,因此今天仍會看到 proxies、proxy-groups、rules 等熟悉欄位。專案歷史解釋了設定為何如此設計,但選擇安裝方案不能只看「Clash」三個字,還要確認用戶端是否持續維護、核心來自哪個分支,以及目標系統是否相容。
圖形用戶端提供訂閱管理、系統代理開關、策略組選擇、連線紀錄與設定介面;真正解析設定、處理連線與執行規則的是核心。兩個用戶端即使介面完全不同,只要使用相近的核心與相容設定,底層分流邏輯仍可能高度一致。反過來,介面中出現同名選項,也不代表核心能力、設定相容範圍與更新節奏完全相同。
mihomo 是目前 Clash 生態中常見且持續活躍的核心,延續 Clash.Meta 路線,並持續擴充協定、規則、DNS 與透明代理能力。桌面使用者通常透過整合 mihomo 的 GUI 用戶端使用這些功能;伺服器、路由器與自動化環境則可能直接執行核心。選擇時先判斷是否需要圖形介面,再確認協定與設定功能,不要把核心壓縮檔當成桌面安裝程式。
用戶端更新會修正介面與系統整合,核心更新會影響協定、規則與 DNS 行為,訂閱更新則會變更節點與遠端設定。三者不是同一個動作。遇到故障時,先記錄最近的變動發生在哪一層:剛更換用戶端、剛升級核心,還是剛重新整理訂閱。如此才能決定要回退程式、切換核心,還是還原 Profile,避免把所有問題都歸咎於節點失效。
先按現象分層,不要一開始就重新安裝。分別檢查用戶端介面、訂閱設定、系統代理、DNS 與節點連線,通常能更快鎖定故障位置。
先查看 Profile 更新提示與回傳內容,再確認目前啟用的是剛匯入的設定。訂閱網址失效、格式不相容、遠端內容為空,以及更新後未切換 Profile,表現都可能是清單空白。不要只是不斷點擊更新,先閱讀錯誤訊息。
查看安裝設定問答 →依序檢查設定是否成功載入、系統代理或 TUN 是否啟用、策略組是否選取可用項目,以及連線紀錄是否命中 REJECT。若所有請求都失敗,再切換至 DIRECT 進行基準測試,藉此判斷問題出在代理鏈路還是本機網路。
查看故障排查 →日常使用優先選擇規則模式,由設定決定 DIRECT、PROXY 與 REJECT。全域模式適合暫時驗證代理鏈路,不適合作為長期排查結論;直連模式則可用來驗證本機網路。模式切換是診斷工具,不是越強越好的等級選擇。
查看入門操作 →用戶端的延遲測試通常只反映到測試位址的一次握手路徑,不代表持續頻寬、封包遺失、壅塞與目標網站路由。選擇節點還要綜合地區、倍率、協定與實際業務測試;單一毫秒數字只適合初步篩選。
查看延遲原理 →不堆砌「萬用參數」。文章各自針對一個具體問題,講清楚設定結構、判斷順序與容易誤解的概念。以下三篇涵蓋訂閱格式、節點選擇與延遲測試,正好對應日常使用中最常見的三類誤判。
比較 Clash YAML、base64 分享內容與通用訂閱結構,說明轉換時可能遺失的策略組、規則與擴充欄位,以及遷移用戶端前應檢查的相容項目。
繼續閱讀 →延遲只用於初步篩選,倍率決定流量成本,地區影響內容與路由,協定關係到穩定性與裝置負擔。文章提供一套比盯著最低數字更可靠的選擇順序。
繼續閱讀 →拆解用戶端延遲測試的實際測量方式,區分握手往返、持續吞吐量、封包遺失與目標網站路由。數字看起來漂亮,不代表高負載情境下的體驗穩定。
繼續閱讀 →