先分清三個層次：核心、圖形化用戶端、設定檔

搜尋「Clash 下載」時，搜尋結果常混雜核心程式、桌面安裝程式和手機 App。這些並不是同一類東西。先釐清三者的關係，後續遇到版本選擇、設定檔錯誤或遷移問題時，就更容易找出原因。

  • 核心：負責接收連線、查詢 DNS、比對規則及建立對外連線。mihomo 屬於這一層，即使沒有圖形介面也能獨立執行。
  • 圖形化用戶端：負責匯入訂閱、選擇節點、顯示記錄，以及呼叫系統代理、背景服務等平台功能。Clash Verge Rev、FlClash 都屬於這一層，安裝套件通常會附上可用的核心。
  • 設定檔：告訴核心要監聽哪個連接埠、使用哪些節點，以及依據哪些規則分流。用戶端也可能在啟動前合併、覆寫或產生設定檔。

例如，介面上的「系統代理」按鈕通常會修改作業系統的代理設定；mixed-port: 7890 則會讓核心提供 HTTP/SOCKS 混合代理入口。即使按鈕已開啟，若應用程式不遵循系統代理設定，流量仍可能不經過這個連接埠。兩者不是同一個開關。

演進脈絡：Clash → Clash Meta → mihomo

原版 Clash：規則代理核心的起點

原版 Clash 是以 Go 編寫的規則代理程式，建立了這個生態系常見的 YAML 設定格式，例如 proxies、proxy-groups 和 rules。許多後續用戶端沿用了這些概念，但沿用設定格式不代表出自同一個開發團隊。

過去也有 Clash Premium。它是原版生態系中提供額外功能的閉源核心分支，不能與原版開源核心混為一談。舊教學提到「需要 Premium」，通常有其特定時空背景，不能因此認定現在仍應尋找舊版 Premium 程式。

Clash Meta：擴充功能的分支，不是介面主題

Clash Meta 是從 Clash 發展而來的核心分支，擴充了協定支援、DNS 與規則處理等功能。舊設定檔、訂閱服務和用戶端設定中常見的「Meta 核心」，通常指這條發展脈絡，而不是名為 Meta 的圖形主題。

mihomo：延續 Meta 發展脈絡的專案名稱

約在 2023 年底，Clash 生態系經歷原專案儲存庫下線、用戶端停止更新，以及社群接手延續等變化。Clash Meta 後來更名為 mihomo，目前專案由 MetaCubeX 組織維護。因此，簡單來說，「Clash Meta 和 mihomo 有什麼差別？」前者是這條核心發展脈絡的舊名稱，後者則是後續的專案名稱。

名稱延續不代表二進位檔永遠相同。幾年前的 Meta 核心和新版 mihomo，在欄位、協定與預設行為上都可能不同。排除問題時，應記下實際版本號，而不只是寫「使用 Meta」。同樣地，也不能把 mihomo 說成是原 Clash 團隊推出的新版本。

用戶端與核心的關係：Clash Verge 和 Verge Rev 必須分開看

以下依據專案關係整理，不對任何特定安裝套件的核心版本作出保證。發行方可能更新核心、增加建置選項或調整平台支援，請以已安裝版本的發行說明和執行資訊為準。

專案 角色與核心關係 選擇時確認
mihomo 代理核心本身，延續 Clash Meta 的發展脈絡 作業系統、處理器架構、核心版本與設定檔支援情況
Clash Verge 原始桌面圖形化用戶端，歷史版本曾提供 Clash 與 Clash Meta 核心選項；原專案已封存 不要把舊版功能清單當成 Verge Rev 的現行說明
Clash Verge Rev 由社群接續維護的桌面用戶端，採用 mihomo 核心 背景服務、TUN 權限、訂閱覆寫與核心更新方式
FlClash 以 Flutter 開發的跨平台圖形化用戶端，採用 mihomo 核心 平台支援、行動裝置 VPN 權限與不同建置版本的功能差異
Clash for Windows 已停止維護的舊款圖形化用戶端，常見的後期發行版本採用 Clash Premium 名稱含有 Clash，不代表一定支援目前 mihomo 的欄位

名稱相近，也要確認專案儲存庫與發行方

Clash Verge 和 Clash Verge Rev 並非可以任意省略後綴的同一個發行專案。安裝套件檔名、軟體內顯示的名稱與專案儲存庫應彼此一致。網站或發行套件若出現 FlClash 的衍生名稱，也應確認它是上游原版、重新打包版本，還是修改過的分支；不要只憑相似的圖示判斷。

若要讓桌面與手機共用設定，先確認兩者支援的核心功能是否重疊，再比較介面操作習慣。平台選擇可參考用戶端比較；要下載安裝，請前往下載頁面，不必為了沿用舊教學而繼續使用已停止維護的用戶端。

設定檔相容性：YAML 格式相同，不代表執行結果相同

協定與欄位的解讀方式，取決於實際執行的核心

YAML 只是資料格式。檔案能順利解析，不代表其中的節點協定和參數都受到支援。例如，包含 type: hysteria2 的節點，需要搭配支援該協定的核心；不能因為用戶端能匯入 YAML，就認定舊版 Clash 或 Premium 一定能連線。

基本欄位也要留意其語意與組合方式。mode: rule 代表規則模式；規則會依序比對，MATCH 通常用於最後的預設比對。如果用戶端覆寫將模式改為全域模式，即使原訂閱的規則仍保留，也不會依預期分流。

用戶端可能會產生另一份執行設定

訂閱原始內容、用戶端編輯器中的內容，以及實際交給核心的設定，可能是三份不同的檔案。覆寫指令碼、合併設定與介面開關都可能改變最後的結果。若發現「修改 YAML 後沒有生效」，先查看用戶端是否提供「執行設定」、「目前設定」或設定目錄入口。這些名稱會隨用戶端版本而異，別直接套用其他軟體的選單路徑。

以下是用來核對概念的 mihomo 設定片段，並非完整訂閱。若現有設定已有同名的頂層欄位，請修改原欄位，不要直接把這段重複貼到檔案末尾。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

tun:
  enable: false
  • 7890 是範例連接埠，並非所有用戶端都固定使用此連接埠。瀏覽器、終端機和系統設定應使用實際監聽的連接埠。
  • allow-lan: false 表示不主動開放區域網路代理存取，不能取代作業系統的防火牆設定。
  • tun.enable: false 會關閉此設定中的 TUN；若用戶端介面有覆寫設定，仍須檢查最終的執行設定。
  • 這段設定沒有節點、策略群組或規則，無法據此判斷訂閱是否可用。

授權條款：核心與介面要分別確認

原版 Clash 的開源程式碼、mihomo、Clash Verge Rev 和 FlClash 都涉及 GPL-3.0 授權。採用相同授權，不代表它們是同一個專案，也不代表所有第三方建置都已履行散布義務。具體適用條款請查看對應版本的 LICENSE 檔案，包括是否允許採用後續版本授權等細節。

個人使用與再次散布，注意事項不同

  • 個人安裝使用：一般不需要為了執行用戶端而公開個人訂閱、規則或節點密碼。軟體原始碼授權與個人設定內容是兩回事。
  • 修改後散布給他人：須依適用授權提供相應的原始碼、授權文字與必要聲明，不能只保留專案名稱就認為已完成義務。
  • 打包第三方元件：介面、核心、相依程式庫與平台元件都應分別確認。歷史上的閉源 Clash Premium，不會因為由開源介面呼叫，就自動成為 GPL 開源程式碼。

確認發行套件時，建議依序檢查：從軟體的「關於」或專案說明找到原始碼網址，確認發行標籤，再閱讀該標籤下的授權檔案。品牌授權、商標使用與原始碼授權也不是同一種授權。若涉及商業再散布，應依實際打包方式進行合規審查。

遷移檢查清單：先維持原有行為，再啟用新功能

從舊版 Clash 用戶端遷移至 mihomo 用戶端時，不建議一次更換訂閱、啟用 TUN、切換 DNS 模式並新增覆寫。變數太多，出問題後很難找出原因。依照以下順序操作，通常也更容易還原。

  1. 記錄原有環境。記下用戶端名稱與版本、核心名稱與版本、系統版本，以及系統代理和 TUN 的開關狀態。匯出設定前，先確認檔案是否包含訂閱權杖。
  2. 備份可用的設定。保留原訂閱網址和本機修改內容，並另外記下覆寫規則。不要只複製用戶端程式目錄，使用者設定可能存放在其他位置。
  3. 關閉舊用戶端。確認舊程序與背景服務已停止，不再占用代理連接埠。兩個程序同時監聽 127.0.0.1:7890 會造成衝突，可能出現啟動失敗或代理無法使用的情況。
  4. 先匯入，再確認。在新用戶端啟用目標設定，檢查記錄中是否有未知欄位、不支援的節點類型或引用不存在策略群組等錯誤。
  5. 先測試明確指定的代理入口。暫時不要啟用 TUN，依新用戶端實際使用的連接埠設定應用程式代理，分別檢查網頁連線、網域名稱解析與規則比對結果。
  6. 最後才啟用系統接管。依需求開啟系統代理或 TUN、補足所需權限，再測試本機網路、休眠後恢復及應用程式分流。每次只變更一個項目。

記錄中出現 address already in use，優先檢查連接埠是否被占用；若出現設定解析錯誤，優先檢查欄位與縮排；若只有特定應用程式無法使用，則確認該程式是否採用系統代理、獨立 DNS 或自有網路堆疊。連線失敗時，不要第一時間就更換節點。

常見問題：核心更新、訂閱識別與選擇順序

更新用戶端時，mihomo 也會自動更新嗎？

不一定。用戶端可能將核心直接包在安裝程式中，也可能支援另外下載核心。介面顯示的軟體版本不等於核心版本。更新後應重新查看核心執行資訊，必要時檢查啟動記錄；不能只憑「檢查更新」顯示已是最新版，就認定核心也已更新。

訂閱標示支援 Clash，可以直接用 mihomo 嗎？

多數常見的 Clash YAML 設定都有遷移的基礎，但仍須檢查協定、擴充欄位與用戶端覆寫。訂閱服務也可能依據用戶端識別資訊回傳不同內容。如果原連結提供的是節點 URI 清單，而非完整 YAML，也要確認新用戶端是否支援這種匯入方式；不能把所有「訂閱連結」都當成相同格式的檔案。

使用同一個 mihomo 核心，為什麼桌面版能用、手機版卻不行？

先比較實際執行的設定，而不只是訂閱網址。手機端還會受到 VPN 授權、應用程式分流清單、背景執行限制和其他 VPN 占用等因素影響；桌面端則可能受系統代理、防火牆與服務權限影響。協定支援相同，只排除了一種差異，並未排除整條網路路徑上的其他差異。

最後，應該先選核心，還是先選用戶端？

先列出所需的協定、作業系統平台和流量接管方式，再尋找支援這些條件且仍在維護的用戶端。需要圖形介面就選擇適合平台的軟體；若要部署伺服器或進行自動化管理，可以直接研究 mihomo。接著確認實際核心版本，最後再匯入設定。完整操作流程請參閱使用指南；排除故障可查閱疑難排解文件。