PCIE / WIN
前往下載
Windows
適合桌面端日常使用。下載頁提供 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu，以及用於舊版設定遷移的 Clash for Windows 封存入口。安裝前應先在系統設定中確認 Windows 版本與處理器架構；一般使用者優先選擇具備圖形介面、仍在維護且支援 Mihomo 的客戶端。
OPEN SOURCE · CLIENT AND CONFIGURATION
Clash官方網站 客戶端下載 與設定文件
依裝置選擇易於維護的 Clash 客戶端，使用規則分流、策略組與繁體中文設定文件完成訂閱匯入、系統代理設定與連線排查。
- 永久免費
- 程式碼開源
- 五大平台入口
- 中文設定文件
- Mihomo 核心生態
PLATFORM CONNECTORS
依作業系統進入下載頁面
先確認裝置作業系統，再於下載頁核對處理器架構、客戶端維護狀態與安裝套件類型。首頁入口僅用於定位平台，不會直接提供安裝檔。
PCIE / MAC
前往下載
macOS
下載時需要區分 Intel 與 Apple Silicon。圖形客戶端可管理系統代理、規則模式與訂閱更新；首次開啟時也應依系統提示完成應用程式授權。舊版 ClashX Meta 僅用於既有工作流程遷移，新安裝應優先查看目前仍在維護的客戶端。
PCIE / ANDROID
前往下載
Android
適合手機與平板。安裝套件通常依 ARM64、ARM 或通用架構區分，近年的主流裝置多採用 ARM64。匯入訂閱後，需要允許客戶端建立本機 VPN 介面；省電策略可能中止背景連線，持續使用時應檢查系統的電池最佳化設定。
PCIE / IOS
前往下載
iOS
透過 App Store 安裝 Clash Plus，並使用系統提供的 VPN 設定功能接管需要代理的連線。匯入設定前應確認訂閱內容可信；若同一份設定需要在多台裝置上使用，可分別匯入並獨立檢查策略組選擇，避免沿用不適合目前網路的節點。
PCIE / LINUX
前往下載
Linux
桌面環境可選擇 Clash Verge Rev 或 FlClash；伺服器、軟路由與容器環境通常直接執行 Mihomo 核心。使用核心時需自行管理設定路徑、服務常駐、檔案權限與控制連接埠，因此初次接觸 Clash 的使用者更適合從圖形客戶端開始。
CONFIGURATION BUS
Clash 設定結構剖析
設定不是彼此無關的開關集合。連線會先進入網路介面，再經過網域解析、規則比對與策略組選擇，最後由選定的出口處理。以下依職責拆解說明五個結構區塊。
01 / RULE ENGINE
依序比對連線目標
規則引擎根據網域、IP、程序或規則集判斷連線應進入哪個策略。設定中的規則會由上而下比對，命中後通常不再繼續檢查，因此具體網域規則應放在寬泛規則之前，MATCH 則用於處理此前未命中的連線。排查分流錯誤時，先確認目前模式為規則模式，再檢查規則順序、規則集載入狀態與最終指向的策略組名稱。
相較於只提供全域開關的代理工具，Clash 的規則鏈可以把直連、代理與攔截行為寫入同一份設定。規則本身不決定具體節點，只會將流量交給策略組；這種分層設計讓規則集能長期重複使用，而出口節點則可依網路狀況獨立切換。
rules:
- DOMAIN-SUFFIX,example.cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY02 / PROXY GROUPS
將規則目標對應至可切換的出口
策略組位於規則與節點之間。select 適合手動指定出口，url-test 可依測試結果自動選擇，fallback 會依序檢查可用性，load-balance 則用於分配多個出口。實際設定應依穩定性需求選擇組別類型，不能只因名稱相似就互換；自動測試網址、測試間隔與逾時設定也會影響切換結果。
建議讓業務規則引用穩定的策略組名稱，而不是直接寫入某個節點名稱。訂閱更新造成節點增刪時，只需調整組內成員，不必重寫整套規則。合併多份訂閱時也要避免節點重名，並確認策略組引用的提供器已完成載入。
proxy-groups:
- name: PROXY
type: select
proxies:
- AUTO
- DIRECT03 / DNS PIPELINE
統一網域解析與規則判斷
DNS 設定負責網域如何解析、查詢送往哪台伺服器，以及解析結果如何與規則引擎配合。啟用 Fake-IP 後，客戶端會先回傳保留位址並保存網域對應，後續連線仍可依網域規則判斷；Redir-Host 則更接近傳統解析流程。遇到網站解析異常時，應依序檢查系統 DNS 是否遭接管、上游位址是否可連線、增強模式是否符合目前網路，以及過濾清單是否涵蓋區域網路網域。
DNS 洩漏、污染與循環查詢往往源自多層軟體同時接管解析。設定時應明確由系統、客戶端或路由器負責入口解析，並避免將需要透過代理存取的 DNS 上游錯誤交給直連鏈路。
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 1.1.1.104 / TUN INTERFACE
接管不遵循系統代理的流量
TUN 模式會建立虛擬網路介面，讓不讀取系統代理設定的應用程式也能進入 Clash 處理鏈。它適用於命令列工具、部分遊戲啟動器與採用獨立網路堆疊的軟體，但也會增加路由、DNS 與權限設定的複雜度。桌面端啟用前應確認客戶端具備所需權限，並檢查其他 VPN、安全軟體或虛擬網卡是否佔用相同路由。
若開啟 TUN 後完全斷網，不應立即反覆切換節點。更有效的順序是先關閉 TUN、恢復基準狀態，再檢查堆疊類型、自動路由、DNS 劫持與防火牆規則。只有在系統代理正常而特定應用程式未經代理時，才需要進一步判斷是否必須啟用 TUN。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true05 / EXTERNAL CONTROL
透過本機介面讀取狀態與切換策略
外部控制介面供桌面客戶端或控制面板讀取代理組、連線與日誌，並執行策略切換。介面通常只需監聽本機位址；若要延伸至區域網路，必須同步設定存取金鑰與防火牆範圍。控制面板只是管理入口，實際流量仍由 Clash 或 Mihomo 核心處理，因此面板無法開啟與代理鏈路失效是兩類問題，應分別檢查靜態頁面、控制連接埠與核心程序。
進行遠端管理時不應直接暴露控制連接埠。較穩妥的方式是透過受控網路與反向代理存取控制面板，並限制可連線介面的來源。修改控制位址後，還要同步更新客戶端面板中的連線參數。
external-controller: 127.0.0.1:9090
secret: "your-password"OPEN SOURCE TRACE
開源生態與維護界線
Clash 相關客戶端、核心與設定格式由多個專案共同組成。理解各層職責，比只記住某個客戶端名稱更有助於後續遷移與故障排查。
專案歷史：從 Clash 規則模型到持續維護的衍生生態
Clash 以規則驅動的代理模型建立了設定基礎：監聽連接埠、代理節點、策略組、規則與 DNS 共同構成處理鏈。原始專案的維護狀態改變後，社群中的客戶端與相容核心仍持續演進。目前選擇客戶端時，不能只根據名稱是否包含 Clash 判斷可用性，而應同時查看維護狀態、核心類型、作業系統支援與設定相容範圍。
Clash for Windows 等歷史客戶端仍可能出現在舊教學與既有裝置中，但停止維護的軟體不適合作為新安裝的預設選擇。遷移時應先匯出或保存原有設定，再核對新客戶端支援的訂閱格式、腳本能力與覆寫方式，避免將客戶端專屬欄位直接當作通用核心欄位使用。
開源生態：客戶端、核心與設定不是同一個元件
圖形客戶端負責安裝體驗、訂閱管理、系統代理開關、日誌顯示與策略組操作；Mihomo 等相容核心負責解析設定、建立監聽連接埠並執行規則；訂閱服務則提供節點與策略內容。三個層次可以組合，但故障位置各不相同。客戶端介面能開啟，不代表核心已啟動；核心正常運作，也不代表訂閱中的節點目前可用。
定位問題時應分層檢查：先確認本機網路與系統時間，再確認訂閱回應與設定解析，接著檢查核心日誌、代理模式、策略選擇、DNS 與系統防火牆。分層排查可避免在節點不可用時反覆重裝客戶端，也能避免將設定語法錯誤誤判為系統網路故障。
核心關係：Mihomo 提供持續擴充的相容實作
Mihomo 延續 Clash 的設定思路，並擴充規則提供器、代理提供器、DNS、TUN、流量嗅探與控制介面等功能。多數現代圖形客戶端會封裝核心下載與啟動流程，一般使用者通常不需手動執行二進位檔；伺服器、路由器與容器使用者則需要自行處理設定目錄、執行權限、服務常駐與日誌輪替。
設定遷移不能只看 YAML 是否能夠解析。某些欄位依賴特定核心版本或客戶端覆寫邏輯，同一份訂閱在不同客戶端中的預設 DNS、TUN 堆疊與系統代理行為也可能不同。遷移後應分別驗證直連網站、代理網站、網域解析，以及應用程式退出後系統代理的恢復狀態。
更新機制：先確認變更層級，再決定是否升級
客戶端更新、核心更新與訂閱更新所解決的問題不同。客戶端升級通常會改變介面、系統整合與核心管理方式；核心升級可能增加設定欄位或修正網路行為；訂閱更新則會改變節點、策略組與規則內容。出現異常時，應記錄最近變更的是哪一層，再決定回復設定、切換節點或重新安裝客戶端。
更新前保留目前可用的設定，並記錄系統代理、TUN、DNS 與覆寫設定。更新後不要只靠延遲測試判斷結果，還應檢查策略組是否完整、規則提供器是否載入、日誌是否出現解析錯誤，以及瀏覽器與不讀取系統代理的應用程式是否各自按照預期運作。
QUICK DIAGNOSTICS
常見問題精選
以下結論用於建立排查順序。需要完整步驟時，請進入疑難解答或使用文件。
Clash for Windows 停止維護後，應該選擇哪個客戶端？
新安裝應優先選擇仍在維護、支援目前作業系統並採用相容核心的客戶端。Windows 使用者可先比較 Clash Plus、Clash Verge Rev、FlClash 與 Clash Nyanpasu；遷移舊設定時，先保存訂閱網址與本機覆寫，再逐項驗證系統代理、策略組、DNS 與 TUN 設定。詳細差異請見客戶端比較。
匯入訂閱後看不到節點，應先檢查什麼？
先查看訂閱請求是否成功，再確認回傳內容能由目前客戶端解析。如果日誌提示 YAML 語法、欄位類型或策略組引用錯誤，應先修正設定；若訂閱內容正常但清單未更新，可重新擷取並檢查客戶端是否使用舊快取。尚未確認解析結果前，不要反覆切換代理模式。
開啟系統代理後仍然無法上網，如何縮小範圍？
先關閉系統代理，確認本機網路本身可用，再檢查核心是否啟動、節點是否可連線、目前模式與策略組是否正確。瀏覽器無法存取時還要檢查 DNS；只有特定應用程式未經代理時，再判斷該應用程式是否忽略系統代理並需要 TUN。完整流程請見疑難解答。
規則模式、全域模式與直連模式有什麼差別？
規則模式會依設定逐條決定直連、代理或攔截；全域模式通常將連線交給統一策略組，適合暫時驗證節點鏈路；直連模式會跳過代理出口，可用於確認問題是否來自代理鏈。日常使用一般採用規則模式，全域模式更適合作為短時間診斷手段，而不是長期取代規則設定。
TECHNICAL NOTES
近期設定與故障排查文章
圍繞節點連線、訂閱解析與客戶端選擇整理可重複使用的檢查順序。文章結論以設定層級與操作路徑為主，不採用無法重現的效能數據。
Clash 節點逾時無法連線：從網路入口到代理鏈路的排查順序
依本機網路、訂閱狀態、節點可用性、代理模式、DNS 與系統防火牆的順序定位連線逾時，避免在尚未確認問題層級時重複安裝客戶端。
閱讀全文 →Clash 訂閱失效與設定解析失敗：常見原因與復原步驟
區分訂閱網址過期、回應內容異常、設定格式錯誤與客戶端快取問題，並說明如何透過請求結果與核心日誌判斷故障發生在哪一層。
閱讀全文 →Clash 客戶端怎麼選：Windows、macOS、Android 與 iOS 橫向比較
從平台涵蓋範圍、核心支援、設定能力與維護狀態比較主流客戶端，並說明桌面端、行動端與伺服器環境應採用的不同選擇標準。
閱讀全文 →