Clash、mihomo 與各款用戶端的關係：開源生態系專案脈絡整理

先釐清四個層次：核心、用戶端、面板與設定

下載頁面提到的 Clash，有時指代理核心，有時指具備圖形介面的應用程式，也可能只是指相容於 Clash YAML 的設定格式。判斷兩個專案的關係，先確認各自負責哪個層次，再查看實際載入的核心名稱與版本；光看軟體名稱有沒有 Clash，無法判斷支援哪些協定、規則語法或 TUN 功能。

例如，圖形用戶端能正常開啟，只能表示介面程序已成功執行；若核心設定檢查失敗，代理仍可能沒有啟動。反過來說，關閉介面後若背景服務仍在執行，連線也可能繼續經過代理。排解問題時，應分別檢查介面、核心程序與系統代理狀態。

專案脈絡：Clash、Premium、Meta 與 mihomo

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

原版 Clash 通常指 Dreamacro/clash 專案，是以 Go 撰寫的規則代理核心。它建立了這個生態系常見的設定結構，包括 proxies、proxy-groups、rules 與 dns。原版專案已於 2023 年停止公開維護；舊版執行檔仍能運作，不代表之後還會有協定支援或系統相容性更新。

Clash Premium 是歷史上的另一條發行線，曾加入 TUN、規則提供者、指令碼等功能，不能將這些功能視為所有版本的原版開源核心都具備。Premium 的增強部分並未完整開源，因此「Clash 生態系包含開源專案」和「所有冠上 Clash 名稱的發行版本都公開完整原始碼」是兩回事。

Clash.Meta：擴充協定與規則功能的分支

Clash.Meta 是從 Clash 發展而來的分支，擴充了協定支援、DNS、流量嗅探與 TUN 等功能。舊教學中的 Meta、Clash Meta，以及檔名中的 clash-meta，通常都是指這個分支。它不是原版核心的一個開關，也不是只更換外觀的用戶端。

mihomo：Meta 專案後續採用的名稱

由 MetaCubeX 維護的 Clash.Meta 後來更名為 mihomo；目前要確認專案身分，應查核 MetaCubeX/mihomo 儲存庫、發布紀錄與執行檔版本。舊設定、舊路徑和用戶端介面仍可能保留 Meta 字樣；名稱尚未全面更新，不代表使用的是另一套核心。

Dreamacro/clash
├─ 原版開源核心
├─ Clash Premium（歷史增強版發行線）
└─ Clash.Meta（分支）
   └─ mihomo（Meta 專案後續名稱）

圖形用戶端 → 啟動、設定或內嵌核心
控制面板   → 連線至核心的控制介面

Verge Rev、ClashX 與 Nyanpasu 分別屬於哪個層次

這些名稱主要指圖形用戶端。用戶端負責系統匣、訂閱管理、權限申請等操作；協定與規則則主要由搭載的核心負責執行。應用程式更新與核心更新可能是兩條獨立的版本線，回報問題時應一併提供兩者資訊。

同名分支須查核維護者與發布紀錄

原版 Clash Verge 與 Clash Verge Rev 並非同一個持續發布的專案。Rev 是後續獨立維護的分支，不能根據原專案停止更新就推斷 Rev 的狀態，也不能把兩邊的版本號接成同一條更新序列。ClashX 的不同分支也應逐一確認，尤其要檢查最低系統版本、處理器架構與核心來源。

查看 macOS 安裝套件時，請分清 Apple Silicon 的 arm64 與 Intel 的 x86_64。即使應用程式透過相容層成功啟動，背景輔助程式的架構、安裝位置與權限仍須另外確認。iOS 則受系統網路延伸功能機制限制，桌面版安裝輔助服務的步驟不能直接套用到 iPhone。

「相容於 Clash 設定」不代表所有欄位都能正常運作

Clash YAML 是共通的基礎格式，不代表所有核心版本都具備相同功能。舊核心可能不支援較新的協定、嗅探選項或 DNS 欄位；有些欄位會導致啟動失敗，有些則可能無法如預期生效。用戶端可以匯入訂閱，也不代表每個節點都已通過連線測試。

遷移前檢查三類差異

1. 節點協定：檢查每個節點的 type 及其參數。以 Hysteria2、TUIC 等節點為例，應查核目標 mihomo 版本的支援範圍，不能依原版 Clash 的功能推斷。
2. 規則與資源：檢查 rule-providers 的格式、behavior 與更新路徑；若出現 RULE-SET，請確認對應的資源名稱確實存在。
3. 系統流量接管：檢查 tun、DNS 劫持、路由與權限需求。設定語法通過驗證，以及系統成功安裝路由，是兩個不同的檢查步驟。

同一份訂閱，最後載入的設定可能不同

用戶端可能在下載訂閱後追加規則、改寫連接埠或合併 DNS 設定。因此，設定頁面中儲存的原始 YAML，不一定是核心最後讀取的檔案。若遇到「同一份訂閱在另一個用戶端正常」的情況，應優先比對實際執行的設定，而不是反覆匯入十幾次。

# 7890 是本例的設定值，並非所有用戶端的固定連接埠
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port: 7890 表示在同一個連接埠接受 HTTP 與 SOCKS 代理連線。它不是控制介面的連接埠，也不會自動啟用 TUN。如果用戶端啟用了連接埠覆寫，系統代理應指向最後生效的連接埠；只修改訂閱中的數字，可能不會改變實際執行結果。以上只是欄位片段，不包含節點與完整的分流規則。

如何確認實際執行的核心，而不只看應用程式標題

不同用戶端的選單名稱會隨版本變動，核對時應使用可交叉驗證的資訊：介面中的核心項目、記錄中的啟動資訊，以及實際執行檔輸出的版本。用戶端「關於」頁面的版本號只代表外層應用程式，不能取代核心版本。

1. 記下應用程式版本：開啟用戶端的「關於」或版本資訊頁面，記錄完整應用程式名稱、版本與作業系統架構，避免只寫「最新版」。
2. 確認核心資訊：在設定中尋找「核心」、「Core」或核心管理入口，記下目前選用的名稱與更新來源；不要把下載清單中的其他核心誤認為正在執行的核心。
3. 查核啟動記錄：重新載入設定後查看記錄，確認核心已成功啟動、設定路徑正確，並留意是否出現不明代理類型、資源載入失敗或連接埠占用。
4. 查核執行檔：若要進一步排除問題，請對用戶端實際使用的執行檔執行版本指令；另外下載的同名檔案只能說明該檔案的版本。

# macOS / Linux：目前目錄中已有 mihomo 和 config.yaml
./mihomo -v
./mihomo -t -f ./config.yaml

# Windows PowerShell：目前目錄中已有 mihomo.exe 和 config.yaml
.\mihomo.exe -v
.\mihomo.exe -t -f .\config.yaml

-v 用於查看版本，-t 用於測試設定，-f 用於指定設定檔。語法測試通過，只表示該設定通過此版本的檢查；不代表遠端節點可連線，也不表示 TUN 權限已獲准。若設定引用本機規則、憑證或提供者檔案，還須確保路徑和執行目錄符合實際環境。

依需求挑選用戶端：先驗證設定，再確認系統流量接管

需要較新協定或 mihomo 專用欄位

選擇明確標示採用 mihomo 的用戶端，再查核核心版本與欄位支援情形。用戶端能顯示節點名稱，不代表該協定一定相容。最基本的驗證流程是：設定測試通過、選取目標策略組、實際建立一次連線，再到連線頁面檢查匹配的規則與出站名稱。

需要透過 TUN 接管不使用系統代理的應用程式

確認用戶端是否提供適用於該平台的服務或輔助程式，以及系統是否已核准所需權限。系統代理主要影響遵循代理設定的應用程式；TUN 則透過虛擬網路介面與路由處理流量，涵蓋範圍取決於路由、排除項目及平台限制。TUN 不代表所有流量都會強制送往代理，最後的出站方式仍受規則、策略組與直連設定控制。

從舊用戶端遷移至仍在維護的專案

1. 備份訂閱來源、自訂規則、DNS 設定與策略組選擇；不要只保存介面截圖。
2. 先在新用戶端匯入一份設定，確認測試通過，再逐項還原覆寫設定。
3. 關閉舊用戶端的系統代理與 TUN，確認舊的背景服務已停止接管流量，再啟用新用戶端。
4. 確認代理連接埠，分別測試網域名稱解析、規則匹配與目標網站連線；發生問題時，依這三個層次分別記錄。
5. 完成驗證後再清除舊服務與開機啟動項目，避免兩個程式爭用同一個監聽連接埠。

選用時最實用的紀錄包括「應用程式名稱與版本、核心名稱與版本、執行設定來源、系統流量接管方式」四項。應用程式外觀決定操作方式，核心決定協定與規則功能，作業系統權限則決定能否實際接管流量。分開核對這三者，才能判斷問題該透過更換用戶端、更新核心，還是修正設定來解決。

需要比較各平台的支援狀況，可查看用戶端比較評測；想了解策略組、規則與 DNS 的差異，可參閱概念速查。下載安裝後，請依目前用戶端實際提供的設定進行驗證，不要混用其他分支的選單截圖。