先分清三個層次：核心、用戶端與設定
搜尋 Clash 時，結果中常會同時出現核心儲存庫、桌面安裝檔、手機 App 和訂閱教學。它們並不是同一類東西。要了解這套生態，先看各專案負責哪個層次，比只看名稱裡有沒有 Clash 更有幫助。
| 層次 | 負責功能 | 常見內容 |
|---|---|---|
| 代理核心 | 接收連線、解析 DNS、比對規則並建立對外連線 | Clash、mihomo |
| 圖形化用戶端 | 匯入訂閱、選擇策略、管理核心與系統連線 | Clash Verge Rev、FlClash |
| 設定與訂閱 | 描述節點、策略群組、規則與執行參數 | YAML 設定檔、遠端設定網址、代理集合 |
核心是處理網路請求的執行層；用戶端提供按鈕、清單和設定頁；設定檔則告訴核心如何處理連線。安裝用戶端時，通常也會取得它搭配的核心，但這不代表用戶端和核心同名。
Clash、Clash Meta 與 mihomo 的沿革
Clash：原始專案與通用稱呼
狹義的 Clash 指由 Dreamacro 發起的規則式代理核心。它透過 YAML 設定檔管理代理節點、策略群組、DNS 與分流規則，圖形介面則可透過控制介面查看連線及切換策略。日常對話中，「Clash」也常泛指這類用戶端和設定格式，因此教學裡的「安裝 Clash」不一定是要直接執行原始核心。
原版開源 Clash 也要和歷史上的 Clash Premium 區分。Premium 是不同的歷史發行分支，功能並不等同於原版開源核心。舊教學提到 TUN、指令碼或規則提供者時，務必一併確認教學所用的分支與版本，不能把其中某項功能套用到所有名稱中帶有 Clash 的程式。
Clash Meta：從 Clash 衍生的核心專案
Clash Meta 是從 Clash 發展而來的社群分支。它保留了許多既有的設定結構，並持續擴充協定支援、DNS、路由和 TUN 等功能。Meta 是核心專案的名稱，不是需要另外購買的用戶端版本，也不代表所有名稱帶有 Meta 的 App 都由同一個團隊開發。
mihomo：Clash Meta 後續採用的名稱
Clash Meta 後來更名為 mihomo，相關開發也在 mihomo 專案中延續。舊文件、設定註解和部分用戶端介面仍可能使用「Meta 核心」這個稱呼。看到「支援 Clash Meta」或「使用 mihomo」時，應先確認實際核心版本；兩者通常指向同一條專案發展脈絡，而不是需要同時安裝的兩項服務。
- 專案沿革：原版 Clash → 社群分支 Clash Meta → 後續名稱 mihomo。
- 用戶端關係：不同介面專案可以整合相同核心，各自維護安裝檔與操作體驗。
- 相容性判斷：名稱只能用來辨識專案，實際支援哪些欄位仍取決於執行中的核心版本。
2023 年原始專案及部分用戶端的公開維護狀況改變後，新的社群分支仍持續發展。這不代表「所有 Clash 用戶端都停止更新」，也不能因此認定新用戶端就是原專案自動更名後的官方續作。要確認維護歸屬，請查看專案儲存庫、發布紀錄與維護者說明。
Verge、Verge Rev 與 FlClash 分別屬於哪個層次
Clash Verge、Clash Verge Rev 和 FlClash 都屬於圖形化用戶端。它們讓使用者透過介面匯入設定、切換策略並查看記錄；實際的代理處理則由它們啟動的核心負責。
| 專案或名稱 | 生態定位 | 選擇時確認 |
|---|---|---|
| Clash Verge | 歷史桌面用戶端專案 | 不要與 Rev 的發布紀錄混為一談 |
| Clash Verge Rev | 延續 Verge 路線的社群桌面用戶端，採用 mihomo | 系統需求、核心版本與服務模式說明 |
| FlClash | 以 Flutter 建置、採用 mihomo 的多平台用戶端 | 目標平台的安裝檔與平台權限 |
| Clash for Windows | 歷史桌面用戶端，已停止維護 | 舊教學與目前系統的相容差異 |
| Clash for Android | 歷史 Android 用戶端，原始專案已停止維護 | 不要與後續社群專案混為一談 |
用戶端名稱中的平台字樣也不能取代發行資訊。例如 Clash for Windows 的歷史發行版本不只支援 Windows，而桌面用戶端也不一定提供 Android 安裝檔。下載時應以該專案當次發布的作業系統與架構清單為準。
同樣採用 mihomo，為什麼設定頁面不一樣？
因為訂閱儲存、系統匣選單、開機啟動、服務安裝和設定覆寫都是由用戶端實作。即使兩款用戶端採用相同核心版本，也可能使用不同的設定目錄和訂閱更新機制。某個介面中的「設定」→「更新訂閱」路徑不能直接套用到另一款 App；找不到同名選單時，可改找「設定」、「Profiles」或用戶端文件中對應的入口。
設定檔能否通用：先看欄位，再看載入方式
mihomo 延續 Clash 生態中常見的 YAML 結構，但「可以匯入」不代表「所有欄位都會生效」。基本代理群組和網域規則通常較容易移植；新協定、DNS 擴充和 TUN 參數則更依賴版本。舊核心可能拒絕載入新設定，也可能忽略不認得的內容，需搭配記錄判斷。
從基本欄位辨識設定檔結構
以下只示範通用設定與規則片段，不包含可連線的節點。範例明確將本機混合代理連接埠設為 7890，並限制為僅供本機使用；這不是所有用戶端的預設值。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,DIRECTmixed-port 提供 HTTP 與 SOCKS 混合代理入口；mode: rule 表示依規則選擇策略。範例最後一條規則是直連備援，因此不會憑空建立代理連線。正式設定若要引用名為 Proxy 的策略群組，也必須在設定檔中實際定義，名稱與大小寫都要一致。
完整訂閱與代理集合不是同一種輸入
- 完整設定訂閱：可能同時包含
proxies、proxy-groups、rules和 DNS 設定，通常匯入用戶端的設定清單。 - 代理集合：通常透過
proxy-providers引用，供既有策略群組使用，本身未必是完整的執行設定。 - 單一節點連結：需要用戶端支援解析或轉換，不能將任意分享連結直接貼到 YAML 頂層。
遇到「同一份訂閱在 A 能用、在 B 不能用」時，先確認 B 是否接受相同的輸入格式，再比較核心版本。不要只因為連結能在瀏覽器下載，就認定它一定是用戶端可直接載入的完整設定。
系統代理與 TUN：接入流量，不是另一種核心
系統代理和 TUN 處理的是「應用程式流量如何進入核心」，規則模式處理的則是「流量進入後交由誰處理」。兩者不是同一組開關。啟用 TUN 後仍可使用規則模式，也仍需要有效的節點、DNS 和路由設定。
系統代理：讓遵循系統設定的應用程式連上本機連接埠
以 Windows 11 為例，可前往「設定」→「網路和網際網路」→「Proxy」檢查代理狀態。如果用戶端目前使用的混合連接埠是 7890，系統代理就應指向相對應的本機位址與連接埠，而不是沿用另一款舊用戶端的 7897 或其他數值。這些數字只是不同設定中可能使用的連接埠，不能只看教學截圖就推定目前設定值。
並非每個程式都會遵循系統代理。若瀏覽器能用、某個終端機工具卻無法連線，先檢查該工具本身的代理參數或環境變數，不要立刻認定核心故障。
TUN：透過虛擬網路介面與路由接入流量
TUN 可以接入更多不遵循系統代理的流量，但能否正常運作取決於系統權限、路由設定、DNS 處理和目前的網路環境。桌面用戶端可能要求先安裝服務或提升權限；Android 通常透過系統 VPN 介面接入，並需要使用者確認授權。不同平台的權限設定步驟不能照搬。
- 切換到 TUN 前，先確認一般代理入口與節點連線正常，以免同時排查兩類問題。
- 記錄其他 VPN、虛擬網卡和安全軟體的狀態，方便找出路由衝突。
- UDP 是否可用還取決於節點協定、伺服器與對外連線，不是開啟 TUN 就會自動支援。
實際選擇與遷移：依照這五個步驟確認
- 確認平台與架構。先確認是 Windows、macOS、Linux 或 Android，再核對 x64、ARM64 等安裝檔標示。在 macOS 可從蘋果選單→「關於這台 Mac」查看晶片資訊。
- 確認專案身分。比對完整專案名稱、儲存庫歸屬與發布紀錄，尤其要區分 Clash Verge 和 Clash Verge Rev，以及原始行動端專案與社群分支。
- 分別記錄用戶端與核心版本。可在「關於」、核心管理頁或啟動記錄中查找；介面位置依實際版本而異。升級用戶端不一定會同步升級核心。
- 先匯入設定，再測試單一節點。確認設定載入成功，查看記錄中是否出現未知欄位、找不到策略群組或連接埠被占用等提示，再測試實際網頁連線。
- 最後再遷移自動化設定。基本連線穩定後，再設定自動更新、開機啟動、覆寫和 TUN，避免一次改動太多變數。
若要獨立執行核心，可在終端機執行以下指令查看版本。執行前，請確認目前目錄中已有相應的二進位檔；圖形化用戶端使用者不必為了查版本另外安裝一份核心。
# Linux / macOS：在核心檔案所在目錄執行
./mihomo -v
# Windows PowerShell：在核心檔案所在目錄執行
.\mihomo.exe -v排除問題時，請記錄實際輸出，不要只寫「最新版」。也應一併記下系統版本、設定來源類型、接入方式和具體錯誤。對外分享記錄前，請移除訂閱網址中的權杖、節點密碼及控制介面金鑰。
常見問題：名稱相近時如何判斷
安裝了 mihomo，還需要用戶端嗎？
不一定。熟悉命令列和設定檔的使用者可以直接執行核心，並自行管理啟動與系統連線。若希望透過介面匯入訂閱、切換策略和查看連線，使用圖形化用戶端會更方便。兩者是不同的使用方式，不是一定要依序安裝的兩個步驟。
將核心換成 mihomo，舊設定就一定能用嗎？
不能只憑沿革就保證相容。除了欄位支援情況，還要確認相對檔案路徑、規則檔案格式、用戶端覆寫機制和權限。遷移後應檢查實際載入記錄與規則比對情況，不要只因設定清單中出現名稱就認定成功。
看到舊稱「Meta」，需要重新找一份訂閱嗎？
名稱改變本身不代表必須更換訂閱。只有現有訂閱的輸出格式、協定或欄位與目前核心不相容時，才需要調整訂閱輸出或設定。應先確認具體錯誤，避免在不必要的轉換過程中洩露訂閱憑證。
如何避免混淆用戶端與核心？
保留一份簡短紀錄：用戶端完整名稱與版本、核心名稱與版本、設定類型、本機代理連接埠、系統代理或 TUN 狀態。下次更換軟體或查閱記錄時，這五項資訊能協助區分「介面問題」、「設定問題」和「網路接入問題」。
繼續閱讀時，可透過術語表確認代理群組、Fake-IP 等概念，或在設定欄位說明中查找特定參數。選用戶端時查看平台與維護狀態，排查相容性問題時則檢查核心與實際設定；把這兩件事分開，就不容易混淆生態中的各種名稱。