Clash中文官方網站
用戶端與設定參考

專案歷史：從原版 Clash 到維護分支

原版 Clash 建立了 YAML 設定、策略組與規則分流等常用模型，許多桌面與行動用戶端都圍繞這套模型提供圖形介面。隨著原專案進入封存狀態，社群維護工作逐步轉向延續分支。Clash.Meta 擴充了協定、DNS、規則與執行能力，後續以 mihomo 之名持續維護。如今看到的「Clash 用戶端」往往不是同一個儲存庫的不同安裝套件，而是多個介面專案對相容核心與設定格式的組合。

這種關係會直接影響選型：歷史用戶端可能仍能執行，但不會持續適配新的系統變化與設定欄位；活躍用戶端通常會更新內建核心、安裝方式與系統整合功能。遷移時不必一次重寫所有設定，可以先複製訂閱網址與必要的本機覆寫，再逐項檢查策略組、規則提供者、DNS 與 TUN 設定是否被新用戶端正確識別。

生態分層：介面、核心、規則與訂閱各自負責什麼

圖形用戶端負責設定檔案、系統匣選單、開機啟動、核心控制與系統代理切換；mihomo 核心負責協定連線、流量嗅探、DNS 處理、規則比對與策略執行；規則集合負責描述網域或 IP 應進入哪個策略；訂閱則負責分發節點或完整設定。某一層出現問題時，表面症狀可能相似，但處理方式完全不同。

例如「訂閱更新後無法連線」可能源於訂閱內容無效、用戶端沒有正確寫入設定、核心不支援某個欄位、策略組引用了不存在的成員，或系統流量根本沒有進入用戶端。按層檢查比頻繁重裝更有效：先看設定能否解析，再看核心是否啟動，接著檢查代理組與日誌，最後確認系統代理或 TUN 的接管狀態。

核心關係：設定相容不代表所有欄位完全一致

mihomo 延續了 Clash 常見的設定結構，並加入更多協定、DNS 選項、規則能力與執行參數。基礎欄位通常容易遷移，但涉及 tun、sniffer、geodata、rule-providers、profile 或實驗性功能的設定，仍需依目前文件核對。用戶端可能還會在原始 YAML 之外維護自己的覆寫檔案、腳本或介面設定，因此匯出單一設定檔不一定包含全部本機狀態。

判斷相容性時，應以「用戶端版本支援哪些核心、核心支援哪些欄位、目前訂閱實際使用哪些內容」三項為準。不要只根據名稱推測能力，也不要把某個用戶端介面中的選項當成所有平台都具備的通用設定。協定手冊會進一步比較 SS、VMess、Trojan、VLESS、Hysteria2 與 TUIC 的設計重點，以及它們在不同核心與訂閱格式中的表達方式。

更新機制：區分用戶端更新、核心更新與訂閱更新

用戶端更新通常修正介面、安裝、權限或系統相容性問題；核心更新會影響協定實作、規則引擎、DNS 與設定欄位；訂閱更新則會變更節點、策略組或規則內容。三者的時間並不一致。遇到問題時記錄最近發生的是哪一類變更，可以大幅縮小排查範圍。若剛更新訂閱，應先檢查設定差異；若剛升級用戶端，應核對核心與權限；若只更換了網路，則優先檢查 DNS、路由與連線可達性。

穩妥的更新流程是保留目前可用的設定，閱讀新版本說明，更新後先驗證設定載入與基本連線，再逐步恢復 TUN、覆寫與自動策略。對長期執行的伺服器，應將設定納入版本管理並使用服務管理器控制重新啟動；桌面使用者則可利用用戶端的設定備份與日誌介面保留遷移依據。