Clash 原版、Meta 與 mihomo 核心差異：版本演進與設定相容性比較

下載用戶端與匯入訂閱

如果才剛準備開始使用，可以先前往Clash 用戶端下載頁，依作業系統和處理器架構選擇用戶端。安裝後，在用戶端的「設定檔」或「Profiles」頁面匯入服務商提供的訂閱網址，選取剛匯入的設定，再到代理群組選擇節點。訂閱網址通常包含存取憑證，請勿將完整網址貼到公開留言或問題截圖中。

要辨別核心時，先釐清三個層次：用戶端提供視窗、系統匣、訂閱管理和系統設定入口；核心負責解析設定、建立代理連線及執行規則；訂閱則提供節點，也可能附帶代理群組、規則和 DNS 設定。用戶端能成功下載訂閱，不代表核心支援其中所有協定。

匯入後的初步檢查

1. 確認訂閱已成功下載，而且目前啟用的是該設定，而非安裝時附帶的範例設定。
2. 查看啟動記錄，確認沒有設定解析錯誤、不支援的節點類型或監聽連接埠衝突。
3. 桌面版先透過系統代理測試瀏覽器；Android 通常需要授予 VPN 連線權限。
4. 若要接管不遵循系統代理設定的應用程式，再另外設定 TUN，避免一次變更多項設定。

Clash 原版、Meta 與 mihomo 的演進

Clash 原版與 Premium 分支

Clash 原版通常指 Dreamacro 專案及其核心。該專案建立了廣泛使用的 YAML 設定結構，例如 proxies、proxy-groups 和 rules。原版生態系也有 Premium 核心，不應將開源原版與 Premium 的功能混為一談：Premium 曾提供 TUN、規則集和指令碼等擴充功能，實際支援範圍則取決於使用的版本。

原版專案於 2023 年 11 月停止維護。舊用戶端和舊核心可能仍可運作，但遇到新節點協定、作業系統變更或新增欄位時，不會因為重新下載同一個舊程式就自動獲得支援。現有舊設定可作為遷移參考；新部署則建議優先選用仍在維護、符合訂閱需求的核心。

從 Clash Meta 到 mihomo

Clash Meta 是以 Clash 生態系為基礎發展的分支，擴充了代理協定、DNS、規則比對及透明代理等功能。該專案後來更名為 mihomo。因此，服務商所說的「Meta 格式」、教學中的「Clash.Meta」，以及用戶端標示的「mihomo 核心」，通常都指向同一條專案演進脈絡。

名稱沿用不代表不同時期的版本完全相同。較早期的 Meta 版本可能缺少後來新增的協定或設定選項，較新的 mihomo 也可能調整欄位行為。判斷能否遷移時，應確認實際版本和啟動結果，而不是只看名稱中有沒有 Meta。

節點協定與訂閱格式相容性

判斷訂閱是否需要 mihomo，最直接的方式是查看節點的 type。請勿公開整份設定，只在本機檢視必要欄位。Shadowsocks、VMess、Trojan 等常見類型在 Clash 生態系中已存在多年，但同一協定仍可能採用不同的加密方式、傳輸方式和擴充參數。

訂閱網址與節點分享連結

完整的 Clash YAML 通常包含代理群組和規則；代理提供者檔案通常只包含節點清單；Base64 節點集合或單一 ss://、vmess:// 分享連結則是另一種輸入格式。用戶端能否自動辨識或轉換這些格式，屬於用戶端功能，不能假設每個核心都能直接將任意連結當成完整設定讀取。

在服務商後台選擇訂閱格式時，如果有「Clash Meta」或「mihomo」選項，而訂閱包含 VLESS、Reality、Hysteria 2 等特徵，建議優先選用對應選項。選擇舊版 Clash 格式，有時會讓轉換服務刪除不相容的節點。匯入後若節點數量明顯減少，請先比對輸出格式，不要馬上認定帳號流量已用完。

規則、DNS 與 TUN 欄位差異

規則順序與策略名稱

DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP 和 MATCH 都是常見規則類型。規則會由上而下比對，第一條符合的規則會決定流量去向；在最後加入 MATCH 可明確設定預設策略。遷移時也要確認規則引用的代理群組存在，群組名稱中的空格與大小寫也必須一致。

mihomo 提供更豐富的比對功能，例如 GEOSITE、邏輯規則，以及依平台、執行權限和功能設定而生效的程序比對。將包含這些規則的訂閱交給舊核心，可能會發生解析錯誤。即使核心能辨識規則名稱，所需的地理資料或遠端規則檔案載入失敗，也會影響最終結果。

規則提供者與舊版指令碼

rule-providers 用來載入規則集，RULE-SET 則用來引用規則集。檢查時應留意提供者的 behavior、檔案格式和路徑，而不只是確認是否有這個頂層欄位。Premium 舊版的 script 設定不能直接視為 mihomo 的等效功能；遷移這類設定時，需重新改寫為受支援的規則與策略群組。

DNS 不只是伺服器位址

DNS 設定包含監聽位址、上游伺服器、enhanced-mode 和 fake-ip-filter 等內容。mihomo 也提供 DNS 策略與流量嗅探等相關功能。舊設定中的某個欄位即使能被接受，也不代表預設行為與舊核心完全相同；遷移後應分別驗證網域解析、規則比對和實際連線。

例如，啟用 fake-ip 後，應用程式可能會收到 198.18.0.0/16 範圍內的虛擬位址，而非伺服器的真實 IP。應用程式流量必須交由同一個核心處理，才能完成後續映射。只複製 DNS 設定，卻沒有設定好流量接管路徑，可能導致「網域解析正常，網頁卻打不開」。

TUN 與系統代理

系統代理主要供遵循作業系統代理設定的應用程式使用；TUN 則透過虛擬網路介面接管流量，通常需要管理員權限、服務模式或相應的系統功能。Windows、macOS、Linux 的路由設定方式各不相同；Android 用戶端一般會透過 VpnService 建立 VPN 介面。用戶端介面上有 TUN 開關，不代表各平台採用完全相同的實作方式。

tun.stack、auto-route 和 dns-hijack 等欄位，需依目標版本與平台檢查。第一次遷移時，建議先關閉 TUN，使用系統代理確認節點可連線，再逐步啟用路由和 DNS 接管。如此一來，較容易區分協定不相容、權限不足與路由衝突。

確認核心版本並測試設定

可先在圖形化用戶端的「關於」頁面查看核心資訊，並檢查啟動記錄中的版本行；實際入口名稱會因用戶端而異。回報核心問題時，不要誤填用戶端本身的版本號。命令列部署可使用以下兩個指令：第一個顯示版本，第二個檢查指定設定；兩者都應呼叫預計實際執行的那個二進位檔。

mihomo -v
mihomo -t -f ./config.yaml

如果系統沒有將 mihomo 加入搜尋路徑，在 Linux 或 macOS 的目前目錄執行時可改用 ./mihomo；Windows 則可在 PowerShell 中使用 .\mihomo.exe。如果電腦上有多個副本，也要核對用戶端的啟動路徑，避免終端機測試的是新核心，圖形化用戶端卻仍在使用舊核心。

最小設定與連接埠驗證

以下 YAML 僅用於確認設定結構與本機監聽，不包含訂閱節點，也不會提供遠端代理出口。混合連接埠設為 7890，同時接受 HTTP 與 SOCKS5 代理請求；allow-lan: false 會將存取範圍限制在本機。請另存為獨立測試檔案，不要覆寫目前使用的訂閱。

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

proxy-groups:
  - name: 測試出口
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.com,測試出口
  - MATCH,DIRECT

設定檢查通過後再啟動核心，並使用以下指令確認 HTTP 代理監聽路徑。範例預設選擇 DIRECT，因此成功只代表本機代理入口與直連路徑可用，不能證明訂閱節點可用。如果記錄顯示連接埠已被占用，請先關閉另一個正在執行的用戶端，或統一變更測試連接埠與請求連接埠。

curl --proxy http://127.0.0.1:7890 --head https://example.com

設定檢查通過也不保證網路連線成功：它無法替你確認節點密碼、遠端憑證、訂閱剩餘流量或電信業者的 UDP 限制。後續仍需使用實際訂閱逐一測試，並查看連線記錄。控制介面常見位址為 127.0.0.1:9090，這不是代理連接埠；如需啟用，應設定存取金鑰，並避免直接監聽公網。

舊設定遷移與常見錯誤

遷移步驟

1. 保留原始設定。 分別備份本機覆寫設定、規則檔案與代理群組選擇，不要直接修改唯一副本。
2. 重新取得相容的訂閱。 優先使用服務商提供的 Meta 或 mihomo 格式，並確認新舊設定的節點數量與協定類型。
3. 測試基本連線。 先使用系統代理並維持規則模式，確認至少有一個實際節點能連上目標網站。
4. 合併自訂內容。 逐項加入規則提供者、DNS 和嗅探設定，每次變更後都檢查啟動記錄。
5. 恢復 TUN 與自動啟動。 基本連線穩定後，再啟用虛擬網卡與背景服務，並重新啟動裝置確認設定能持續生效。

錯誤分類

核心選擇建議與常見問題

新安裝時，優先選用支援現有訂閱且持續維護的用戶端與核心。需要 VLESS、Reality、Hysteria 2 或較新的分流功能時，通常應選擇合適版本的 mihomo。舊環境若暫時無法遷移，先確認目前的功能需求與系統限制，再安排替換即可，不必因名稱變更而反覆匯入同一份設定。

選擇核心時也要考量硬體架構。Apple Silicon 與 Intel Mac 需要不同的安裝檔；Linux 的 x86_64 與 arm64 二進位檔也不能混用。圖形化用戶端另外負責桌面整合與更新管理；無圖形介面的伺服器則可使用命令列核心。如需進一步比較各平台的選擇方式，請參閱選型指南；安裝與匯入步驟請見快速上手。