Clash 原版、Clash Meta 與 mihomo 差在哪？核心功能、協定支援與設定檔語法比較
整理三代核心的發展脈絡，比較協定支援、規則類型與 TUN 功能，並說明舊設定檔遷移至 mihomo 時需要調整的欄位。
先釐清：用戶端、核心與訂閱設定
「Clash 支不支援某種協定」，不能只看軟體視窗上的名稱。圖形化用戶端負責管理訂閱、切換設定檔、開關系統代理及顯示記錄；核心則負責解析 YAML、建立代理連線、執行分流規則與處理 DNS。用戶端介面相似，不代表背後使用相同的核心。
訂閱則是設定檔的來源。它可能提供包含 proxies、proxy-groups、rules 的完整設定檔，也可能只提供可供 proxy-providers 載入的代理項目。連結成功下載，只能證明資料已取回，不代表目前的核心能解析其中所有節點和規則。
- 挑選用戶端：確認作業系統、安裝方式、權限管理及設定覆寫入口。
- 挑選核心：確認所需的節點協定、規則語法、DNS 與 TUN 功能。
- 確認訂閱格式：確認服務提供者回傳的是完整 Clash 設定檔，還是針對特定核心的擴充設定。
發展脈絡：原版、Premium、Meta 與 mihomo
Clash 原版與 Clash Premium
一般所說的 Clash 原版，指的是 Dreamacro/clash 開源專案。Clash Premium 則是同一歷史生態中的閉源強化版核心，曾提供 TUN、規則提供者和指令碼等進階功能。Premium 的功能不能直接算在開源原版名下，也不能因為名稱中有 Premium，就認定它是某個圖形化用戶端的付費版。
2023 年 11 月，原版 Clash 專案與 Premium 停止例行公開維護。舊版執行檔可能仍能啟動，但後續協定演進、系統相容性與問題修正，不能再以持續維護中的專案來期待。保留舊環境進行對照測試，和繼續把它當作日常上網入口，是兩種不同的決定。
Clash Meta 與 mihomo
Clash Meta 源自 Clash 的開源分支，在原有設定模型上增加協定與規則功能。專案於 2023 年底更名為 mihomo。舊教學中的 Meta、Clash.Meta，以及現在的 mihomo，通常都指向這條專案發展脈絡，而非三個毫無關聯的核心。
更名不代表所有歷史版本的功能都完全相同。訂閱說明標示「適用於 Meta」，只能大致表示它屬於這套設定生態；某個較新的協定欄位能否使用，仍須確認實際執行的版本。用戶端下載頁顯示的版本號，也不一定是核心版本號。
- 在用戶端的「關於」、核心管理頁面或啟動記錄中，查看核心名稱與版本。
- 使用獨立執行檔時，執行
mihomo -v並記下輸出內容。 - 將查到的資訊與訂閱要求及功能文件比對，而不只是記錄用戶端安裝檔的名稱。
功能比較：協定、規則與 TUN
下表用於判斷遷移方向，並非逐一列出所有版本的完整功能。尤其是協定傳輸方式、加密方法與驗證欄位，仍須確認具體版本；即使使用相同協定，參數不符也可能導致連線失敗。
| 功能 | Clash 開源原版 | Clash Premium | mihomo／Meta 系列 |
|---|---|---|---|
| 常見代理類型 | 支援 SS、VMess、Trojan、SOCKS5、HTTP 等 | 支援 Clash 傳統常見的代理類型 | 保留常見類型，並擴充 VLESS、Hysteria2、TUIC 等 |
| VLESS 與 REALITY | 不支援 | 不支援 | 支援相應設定；REALITY 是相關的 TLS 握手設定，不是獨立的節點類型 |
| 基本規則 | DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP、MATCH 等 | 支援基本規則，並提供進階功能 | 支援基本規則，並擴充 GEOSITE、邏輯規則等 |
| rule-providers 與 RULE-SET | 不應視為具備 Premium 的相關功能 | 支援，須符合規則集格式 | 支援，並提供更多格式與行為選項 |
| TUN | 不具備 Premium 式的內建 TUN 功能 | 支援，但受平台與歷史版本建置限制 | 支援，但仍受平台權限與網路環境影響 |
| Premium script | 不支援 | 曾提供指令碼分流功能 | 不能直接載入 Premium 指令碼並視為相容設定 |
支援協定，不代表所有節點都能匯入
例如，VLESS 節點可能還需要 uuid、network、TLS 參數，以及 REALITY 的公鑰等資訊。只把節點的 type 改成 vless，並不會自動補上這些參數。Hysteria2 和舊版 Hysteria 也不能只因名稱相似，就互換設定檔。
遇到不明的代理類型時，先確認訂閱是否由 mihomo 產生，再檢查核心版本。不要刪除驗證欄位或關閉憑證驗證來迴避錯誤。設定檔能否解析、遠端交握是否成功，以及實際服務請求是否成功，是三個需要分別確認的階段。
舊版 YAML 遷移：哪些保留、哪些檢查
大多數基本設定的架構都能沿用：本機監聽埠、代理項目、代理群組和順序規則仍然適用。遷移的重點不是把整份檔案重新命名，而是移除核心專屬欄位，並確認用戶端最後交給核心的執行設定。
常見欄位處理對照表
| 舊設定項目 | 遷移處理方式 | 檢查項目 |
|---|---|---|
mixed-port、mode |
通常可以保留；確認是否遭用戶端覆寫 | 實際監聽位址與連接埠，以及目前模式是否為 rule |
proxies、proxy-groups |
確認協定欄位及群組中的引用名稱 | 大小寫、空格及提供者名稱是否完全一致 |
rule-providers |
確認 behavior、format 與載入資料結構 | 文字規則集與 YAML payload 不可使用相同的解析方式 |
Premium 的 script 與 script 模式 |
改寫為目標核心支援的規則、規則集或邏輯規則 | 不能只刪除指令碼，就認定分流行為維持不變 |
tun、dns |
依目標核心與作業系統重新確認 | 確認路由、DNS 劫持及區域網路名稱解析是否符合預期 |
規則順序比欄位名稱更容易被忽略
規則通常依序由上往下比對，符合條件後便套用對應策略。若把 MATCH 放在前面，後續的一般規則就不會有機會命中。RULE-SET 引用的名稱必須存在於 rule-providers；規則指定的策略名稱，也必須是有效的代理、代理群組或內建策略。
proxy-providers 提供代理節點，rule-providers 提供比對規則，兩者不能互換。遷移後若出現「找不到提供者」，應先確認引用關係，而非任意交換這兩種訂閱網址。
最小設定檔與遷移驗證指令
先用一份方便還原的設定檔測試核心，再加入實際訂閱。以下是 mihomo 的基本結構範例：監聽本機 7890 混合連接埠，使用規則模式，並關閉 TUN。代理群組只包含 DIRECT，因此這份設定僅用來確認結構與規則載入，不會建立遠端代理連線。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies: []
proxy-groups:
- name: PROXY
type: select
proxies:
- DIRECT
rules:
- DOMAIN-SUFFIX,example.com,PROXY
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,PROXY
tun:
enable: false將檔案儲存為 config.yaml 後，可在獨立終端機中進行檢查。以下指令適用於已將 mihomo 加入 PATH 的環境；在 Windows 本機使用執行檔時，通常需要將指令名稱改為 .\mihomo.exe。
mihomo -v
mkdir clash-test
mihomo -t -d ./clash-test -f ./config.yaml-t 用來檢查目前核心能否載入設定檔，無法證明遠端節點可以連線。測試目錄應與日常使用的用戶端資料目錄分開，避免快取與資源檔互相影響。若設定檔引用外部規則或地理資料，也要確認相關檔案或下載來源可正常使用。
- 備份原始設定檔，並記下舊核心版本、連接埠與已啟用的覆寫項目。
- 將實際訂閱匯入目標用戶端，先關閉 TUN，只測試一般代理連線。
- 檢查啟動記錄中的未知類型、檔案缺漏、無效引用與連接埠占用錯誤。
- 查看目標用戶端的連線記錄，確認命中的規則與實際出口，再逐項恢復 DNS、規則集與 TUN。
若要測試本機 HTTP 代理入口，可執行 curl -x http://127.0.0.1:7890 https://example.com/。這個指令明確指定代理連接埠，不能證明系統代理開關已生效；若仍使用前述範例設定，最後會採直連方式。
TUN 與 DNS：不可直接沿用舊開關
系統代理通常只會影響會讀取系統代理設定的應用程式。TUN 透過虛擬網路介面與路由接管流量，適合需要處理更多應用程式流量的情境，但不代表啟用後所有流量都一定會進入代理。核心仍會依規則決定直連、代理或拒絕，路由排除項目及其他 VPN 也會影響結果。
先排除權限與路由問題
- Windows：確認用戶端要求的服務模式或系統管理員權限；實際設定入口依用戶端版本而異。
- Linux：確認 TUN 裝置、處理程序權限或 root 權限，以及現有路由表。
- macOS：確認用戶端輔助服務與系統授權，避免同時啟用多個會爭用路由的 VPN。
mihomo 的 TUN 設定常會用到 auto-route、auto-detect-interface、stack 與 dns-hijack。這些欄位需要配合平台設定，不能把某個平台可用的設定視為所有系統的預設解法。修改前先記錄原值，每次只調整一組功能，才能分辨問題出在權限還是 DNS。
DNS 能正常解析，不代表分流設定正確
fake-ip 模式會透過位址映射協助還原網域名稱；redir-host 則著重回傳實際解析結果。兩者對網域識別與應用程式相容性的影響不同。遷移時應一併確認 enhanced-mode、fake-ip-filter、上游解析器及區域網路網域的處理方式。
常見的 DNS 劫持目標是一般 DNS 使用的 53 連接埠。應用程式內建的 DoH 通常透過 HTTPS 的 443 連接埠傳送，不能假設針對 53 連接埠的規則會自動涵蓋 DoH。若瀏覽器與其他應用程式的結果不同，應檢查瀏覽器的安全 DNS、快取與核心連線記錄，而非一再更換節點。
選型結論與驗收清單
建立新設定檔時，若需要 VLESS、REALITY、Hysteria2、TUIC 或擴充規則功能，應選擇明確支援所需功能的 mihomo 版本，並確認用戶端確實使用該核心。若只是遷移舊有的 SS、VMess 或 Trojan 設定，基本架構通常可以保留，但仍須分別驗證 DNS、指令碼分流與 TUN。
原版與 Premium 較適合用來理解歷史設定檔及重現舊有行為。遷移至 mihomo 的實際好處，是取得相應的協定與規則功能，以及持續演進的核心實作；但它不會自動修復失效的訂閱、錯誤的憑證或無法連線的伺服器。
- 版本：已記錄實際核心名稱與版本，而不只是用戶端版本。
- 設定檔：語法檢查通過，節點、代理群組與規則提供者的引用完整。
- 連接埠：本機入口與應用程式設定一致，且未與舊用戶端同時占用 7890 等連接埠。
- 分流：至少檢查一項直連請求和一項代理請求，確認記錄中的策略符合預期。
- TUN：確認權限、路由與 DNS 後再長期啟用；退出用戶端後，網路應能恢復正常。
- 更新：手動更新一次訂閱，確認自訂覆寫仍保留，再啟用自動更新。
需要確認欄位含義時，可參閱協定參考；若匯入失敗、連接埠衝突或系統代理異常，可依照說明中心中的現象逐步排查。完成選型後，先驗證一般代理連線，再加入 TUN 與複雜規則，問題範圍會更容易釐清。