Clash 開源生態整理：mihomo 核心與 FlClash、Clash Verge Rev 等用戶端的分工

先釐清四個層次：核心、用戶端、設定檔與服務

搜尋 Clash 下載時，常會同時看到 mihomo、FlClash、Clash Verge Rev 和 Clash for Windows。這些名稱代表的層次並不相同。選擇前先確認需要的是負責代理連線的核心，還是具備訂閱管理與系統設定介面的用戶端，能減少下載錯誤，也避免遷移時誤判。

成功安裝 FlClash，不代表已經有可用的遠端連線。用戶端通常還需要匯入有效設定檔，並選擇策略群組中的出口。反過來說，訂閱仍有效，也不代表長期未更新的舊核心能辨識其中所有協定與欄位。

原版 Clash、Clash Meta 與 mihomo 的關係

原版 Clash 是生態系的起點，不是所有用戶端的統稱

原版 Clash 是以 Go 開發的規則代理專案，建立了廣泛採用的 YAML 設定檔與規則語法。歷史上也有 Clash Premium，其功能範圍與開源版本並不完全相同。舊教學提到的 TUN、規則集或指令碼，應依當時使用的核心判斷，不能直接視為所有 Clash 專案都具備的功能。

2023 年 11 月前後，原版 Clash 與部分相關用戶端的公開專案陸續停止維護或移除儲存庫。現在仍可能找得到舊安裝檔與鏡像，但「還能啟動」不等於「持續支援新協定與新系統」。處理新設定檔時，應先確認具體專案及其維護狀態。

Clash Meta 後來改名為 mihomo

Clash Meta 是從 Clash 生態系發展而來的分支，後來更名為 mihomo。舊文件、設定檔說明與部分介面仍可能使用 Meta 一詞，因此看到「Meta 核心」時，通常還要確認它指的是不是 mihomo 的對應版本。

mihomo 持續擴充協定支援、DNS、規則與 TUN 等功能，但它並非原版專案只改了檔名的同一個程式。欄位是否受支援，應以實際執行的 mihomo 版本及其文件為準。用戶端支援 YAML，也不代表它能辨識所有 mihomo 擴充語法。

• 舊教學寫著 Clash：先確認是泛指設定檔生態系，還是特指原版核心。
• 訂閱標示 Meta：重點是確認設定檔實際使用的協定、規則與 DNS 欄位。
• 安裝檔標示 FlClash：這是圖形用戶端的名稱，核心版本需要另外確認。

FlClash 與 Clash Verge Rev：平台支援與使用差異

FlClash 和 Clash Verge Rev 都是圖形用戶端，不是訂閱服務。選擇時先依作業系統縮小範圍，再比較設定檔管理與系統整合需求。下表說明各專案的平台定位；實際可下載的架構與安裝格式，請以各自的發行版本為準。

Android 與 iOS 不能只看名稱就互換

FlClash 提供 Android 版本，但不能因此推斷它有對應的 iOS 官方安裝檔。Clash Verge Rev 也不是 Android 用戶端。iOS 使用者應選擇適用於該系統的其他用戶端，並確認訂閱格式、規則語法與網路延伸功能是否相容；Android APK 或桌面安裝檔都不能用於 iOS。

平台相同，也要確認處理器架構

macOS 的 Apple 晶片與 Intel 裝置應分別確認 arm64、x64 安裝檔；Android 通常需要區分 arm64-v8a 與 armeabi-v7a。Linux 則要檢查適用於該發行版的套件格式。下載前可在系統的裝置資訊中確認架構，再前往下載頁面選擇對應的用戶端。

介面技術並不能直接決定連線速度或穩定性。遠端服務品質、網路路徑、使用的協定、DNS 與規則比對結果，通常更直接影響連線表現。比較用戶端時，應使用相同設定檔並維持相同網路條件，而不是根據不同訂閱的結果下結論。

同樣使用 mihomo 核心，為什麼匯入後結果不同？

訂閱網址不一定只會傳回代理節點清單。它可能傳回完整 YAML，也可能傳回需要由用戶端解析的節點內容，還可能依請求參數傳回不同格式。先區分「能下載訂閱」、「能解析設定檔」與「能建立連線」這三個階段，再找出差異所在。

1. 核心版本不同：兩個用戶端內附的 mihomo 版本可能不同；新版欄位在舊核心上可能出錯，或無法如預期運作。
2. 設定檔處理方式不同：用戶端可能透過覆寫、合併或訂閱處理功能修改 DNS、連接埠、規則與策略群組。即使原始訂閱相同，最終設定檔也不一定完全相同。
3. 策略群組選擇不同：規則可能指向相同名稱的策略群組，但用戶端記錄的實際選項可能不同。請展開策略群組確認目前使用的出口。
4. 執行環境不同：系統代理、TUN 權限、防火牆、其他 VPN 與 DNS 快取都可能改變流量路徑。

用最精簡的規則片段了解設定依賴

以下僅為規則片段，不是可獨立執行的完整訂閱。使用前必須先有名為 PROXY 的策略群組，且該群組已設定可用的出口。規則會依序由上往下比對，符合後就不會繼續檢查後續規則。

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

這裡的 example.org 僅用來示範網域後綴規則。no-resolve 表示這條 IP 規則不會主動觸發網域解析，不代表關閉整個用戶端的 DNS。匯入後若顯示找不到 PROXY，應檢查策略群組定義，而不是一再重新安裝用戶端。

系統代理、混合連接埠與 TUN 各由誰處理？

用戶端負責協調系統設定，核心則負責處理實際進入的連線。以混合連接埠 7890 為例，mihomo 可在同一個連接埠接收 HTTP 與 SOCKS5 代理請求；用戶端啟用系統代理後，會將作業系統的代理設定指向相應入口。這裡的連接埠僅供示範，實際值以目前設定為準。

mixed-port: 7890
allow-lan: false
mode: rule

在這段範例中，allow-lan: false 表示不允許其他區域網路裝置透過此入口使用代理。如果只在本機使用，排查連線問題時不必直接開放區域網路存取。系統代理也不代表所有應用程式都會被接管：未讀取系統代理設定的程式，仍可能直接連上網路。

TUN 是接管網路流量的方式，不是新的遠端節點

TUN 會透過虛擬網路介面將流量交由核心處理，適用於部分不遵循系統代理設定的程式。桌面版通常需要管理員權限、服務元件或相應的系統授權；Android 版通常透過系統 VPN 介面接管流量。兩者的權限流程與系統限制並不相同。

TUN 不會自動修復失效的訂閱，也不能取代正確的 DNS 與路由設定。同一裝置上的其他 VPN、虛擬網卡或安全軟體可能與 TUN 衝突。啟用後若無法使用本機印表機、區域網路服務或網域，應檢查路由排除與 DNS 處理方式，而不是立刻更換所有節點。

• 瀏覽器正常，某個應用程式連線失敗：先確認該應用程式是否讀取系統代理，再考慮啟用 TUN。
• 輪流測試兩個用戶端：先完全結束前一個用戶端，避免同時占用 7890 或反覆改寫系統代理設定。
• 啟用 TUN 後才出現問題：對照關閉時的狀態，檢查權限、路由與其他 VPN；不要同時變更訂閱與規則。

從舊用戶端遷移：用四個步驟保留可驗證的結果

遷移的重點不是複製整個舊程式資料夾，而是將可重複使用的設定與用戶端自身狀態分開。新用戶端不一定能辨識舊用戶端的資料庫、快取與設定檔，直接覆蓋反而可能引發其他問題。

1. 備份必要資訊。備份訂閱網址、自建設定檔與自訂規則，記下原本的連接埠、策略群組選擇與 DNS 設定。訂閱網址可能包含存取權杖，請勿放進公開截圖。
2. 先使用基本設定。結束舊用戶端，在 FlClash 中匯入訂閱並選取目前的設定檔。先檢查解析錯誤，再透過系統代理測試常用網站；暫時不要啟用 TUN 或自訂覆寫。
3. 逐項還原設定。依序還原規則、DNS、區域網路存取與 TUN，每次只變更一項。若某個步驟失敗，就檢查該項設定與記錄。
4. 記錄執行資訊。保留用戶端版本、mihomo 版本、作業系統、錯誤訊息與重現步驟。用戶端版本和核心版本是兩套不同的編號，不能互相取代。

如果原本使用完整 YAML，遷移時可以先保留其結構，再處理用戶端覆寫項；如果原本只匯入節點清單，則要確認新用戶端如何產生策略群組與規則。不要以為換了介面，舊用戶端的本機規則就會隨訂閱自動出現。

依需求選擇，不要只看名稱新舊

• 需要在 Windows 與 Android 上使用：可以先評估 FlClash，並確認兩端所需的協定、設定檔處理方式與權限條件。
• 主要在桌面管理多份設定檔：可比較 FlClash 與 Clash Verge Rev 的設定檔切換、覆寫及系統整合方式，選擇更符合操作習慣的用戶端。
• 路由器、伺服器或自動化環境：可評估直接執行 mihomo，但必須自行管理設定檔、程序、記錄與存取權限，不一定需要圖形用戶端。
• 繼續使用已停止維護的舊用戶端：應先確認新訂閱能否解析，以及目前的作業系統是否相容，再規劃遷移。

最實用的評估順序是：作業系統支援、核心功能、訂閱相容性、系統流量接管方式，最後才是介面偏好。需要並列比較平台支援時，可查看用戶端比較；已匯入設定檔卻無法連線時，可依問題診斷區分設定錯誤、系統代理與 DNS 問題。這樣就能分開處理「選錯用戶端」和「目前設定有問題」。