進階設定 預計閱讀 12 分鐘

mihomo 核心與原版 Clash 核心差異：協定支援、規則集與設定相容性

比較 mihomo（原 Clash Meta）與原版 Clash 核心，整理新增協定、rule-providers、GEOSITE 規則、TUN 實作及設定欄位相容性，協助判斷現有設定能否直接遷移。

先說結論：基礎設定相近，擴充功能不可反向套用

如果設定只有常見節點、select 策略群組和網域分流規則，遷移至 mihomo 通常只需少量調整。但「能讀取 YAML」不代表「所有欄位都會依原本方式生效」。遇到新協定、規則資料檔、DNS 劫持或 TUN 接管時，應分項驗證，而不是直接覆蓋日常使用的設定。

這裡所說的「原版 Clash」得先區分兩種核心：原版開源核心，以及曾獨立發布的 Clash Premium 核心。兩者的功能範圍不同。尤其是規則提供者、TUN 等功能，不能因為某個舊用戶端支援，就推定原版開源核心也支援。mihomo 則是承接 Clash Meta 發展的專案，不是替舊核心換個顯示名稱。

  • 舊設定遷移至 mihomo：基礎語法有不少共通之處，仍須檢查已移除、改名或由用戶端覆寫的項目。
  • mihomo 設定遷移至舊核心：VLESS、Hysteria2、GEOSITE 等擴充內容不能假設可用。
  • 更換圖形化用戶端：服務權限、設定目錄、覆寫規則和系統代理入口也會跟著改變，不能只比較核心。

協定支援：節點類型與傳輸參數都要檢查

原版開源 Clash 常見的出站類型包括 Shadowsocks、VMess、Trojan、SOCKS5 和 HTTP。mihomo 在此基礎上擴充協定與傳輸支援，例如 VLESS、Hysteria2、TUIC，以及相關的 REALITY 設定功能。實際可用的參數仍取決於安裝的 mihomo 建置版本，不能直接把新文件中的欄位套用至非常早期的 Clash Meta 二進位檔。

檢查項目 原版 Clash 開源核心 mihomo
VMess、Trojan 等常見節點 有相應支援，參數以舊核心為準 支援，但仍須核對傳輸與 TLS 參數
VLESS、Hysteria2、TUIC 無法直接使用這些節點類型 提供相應實作，設定欄位各不相同
rule-providers 不能視為通用內建功能；舊版 Premium 須另外區分 支援外部規則提供者
GEOSITE 規則 不支援 mihomo 的這種寫法 支援，須使用相應的網域分類資料
TUN 接管 不可與舊版 Premium 的 TUN 功能混為一談 支援，效果取決於系統、權限與路由

協定名稱相同，也不代表節點可以原樣複製

例如使用 WebSocket 的節點，除了 type，還要核對 network、路徑、要求標頭和 TLS 伺服器名稱。REALITY 節點則有自己的公鑰、短 ID 等參數。只複製伺服器位址和連接埠，通常無法建立連線。訂閱轉換工具若不認得這些欄位，可能會直接捨棄資訊，最後就會出現「節點看得到，卻連不上」的情況。

  • 先確認訂閱提供的是 mihomo 可讀取的設定格式，而不是其他用戶端使用的 JSON 設定。
  • 檢查節點項目的 type，再確認該類型所需的完整參數。
  • 需要 UDP 的服務，還要確認節點、策略與網路都允許 UDP；「網頁能開」不代表 UDP 可用。

支援更多協定不代表延遲一定更低。伺服器線路、網路壅塞、封包遺失，以及用戶端至伺服器間的網路狀況都會影響結果。選擇核心時看功能需求；比較節點時，則應在相同網路、相同目標和相同測試方式下進行。

規則集差異：rule-providers 不等於 GEOSITE

rule-providers 用來宣告外部規則來源，並在規則清單中透過 RULE-SET 引用。GEOSITE 則依網域分類資料庫中的類別進行比對。兩者都能減少主設定中的規則數量，但資料來源、檔案格式和更新方式並不相同。

先用本機規則檔確認引用關係

以下是 mihomo 的局部設定範例，須合併至現有設定，不能直接當成完整節點設定使用。範例會從設定目錄中的 rules/local-direct.yaml 讀取傳統規則，並將符合條件的連線交由 DIRECT 處理：

rule-providers:
  local-direct:
    type: file
    behavior: classical
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,DIRECT

對應的 rules/local-direct.yaml 內容如下。這裡以 example.com 示範網域後綴比對，實際使用時應替換為確實需要直連的服務網域：

payload:
  - DOMAIN-SUFFIX,example.com

behavior: classical 的項目會包含規則類型，例如 DOMAIN-SUFFIX。如果改用 behavior: domain，就必須採用相應的網域規則格式，不能只改宣告而不調整檔案內容。二進位規則格式也各有支援範圍，不應只改副檔名，就交給另一種解析器處理。

使用 GEOSITE 時，資料庫與類別都要確認

例如 GEOSITE,cn,DIRECT 需要網域分類資料中包含 cn 類別。這與 GEOIP,CN,DIRECT 不同：前者依網域分類比對，後者依 IP 地理位置資料比對。網站若使用境外 CDN，兩種規則可能會得到不同結果；這是比對依據不同，不一定是核心出錯。

首次載入遠端規則或地理資料時可能需要連線。如果這些資源必須透過尚未建立的代理下載，就會形成啟動依賴。初次遷移時可先保留最精簡的規則，準備好所需的本機資料後，再逐步恢復遠端更新機制。

TUN 差異：核心支援只是接管流量的第一步

系統代理通常仰賴應用程式主動使用代理設定；TUN 則透過虛擬網路介面與路由接收流量。mihomo 支援 TUN，不代表勾選選項後所有應用程式就一定會走代理。系統權限、虛擬網卡建立、路由安裝，以及與其他 VPN 的衝突，都可能導致流量無法接管。

舊版 Clash Premium 也支援 TUN，但不能因此將它的整段 TUN 設定視為 mihomo 的標準寫法。遷移時應核對 stack、auto-route、auto-detect-interface 和 dns-hijack 等欄位，並依目前系統的支援狀況調整。

從三個層面確認 TUN 是否正常

  1. 介面層：確認啟動記錄顯示虛擬介面已成功建立，且沒有權限不足或裝置遭占用的錯誤。
  2. 路由層：確認目標流量已進入虛擬介面。多張網卡、其他 VPN 和手動靜態路由都可能改變流量出口。
  3. 連線層：使用目標應用程式建立新連線，並在連線面板查看目標位址、符合的規則和最終策略。

例如 dns-hijack 中常見的 any:53 是 DNS 接管設定，不是「攔截所有加密 DNS」的開關。應用程式自行發出的 HTTPS DNS 要求使用 HTTPS 連線，不能直接當成一般 53 連接埠查詢處理。IPv6 流量也應另外檢查，不能只看 IPv4 查詢結果就認定接管完整。

Linux 上可能需要 root 或適當的網路管理權限；Windows 與 macOS 的圖形化用戶端則可能透過背景服務處理權限操作。服務安裝方式會因用戶端而異，請依用戶端說明操作；排除問題時不要反覆疊加多張虛擬網卡和路由工具。

DNS 與設定相容性：先保留解析路徑，再切換進階模式

mihomo 沿用 Clash 設定中常見的 dns、nameserver、fallback 等概念，也支援更細緻的解析策略。但欄位的組合會決定查詢實際送往何處。把所有 DNS 位址都改成同一個服務，不保證相容性更好，反而可能掩蓋節點網域解析與服務網域解析之間的差異。

切換核心時不宜同時變更 fake-ip 與 redir-host

fake-ip 會為網域提供對應用的虛擬位址，常見位址範圍為 198.18.0.0/16。它用來關聯網域與後續連線，並非遠端伺服器的真實位址。redir-host 通常會回傳真實解析結果。兩種模式都可能影響區域網路裝置、仰賴真實 IP 的應用程式及既有 DNS 快取。

如果舊環境使用 redir-host，第一次遷移時先保留此模式。確認節點和規則都能正常運作後，再單獨測試 fake-ip。若特定應用程式異常，應依狀況設定適當的排除項目；不要因為一個應用程式出錯，就同時關閉 TUN、變更 DNS、切換節點。

  • 無法解析節點網域：檢查建立節點連線前使用的解析路徑，必要時核對 proxy-server-nameserver 等相關設定。
  • 網域規則似乎沒生效：確認連線是否保留網域資訊，以及 DNS 是否確實經過預期的解析路徑。
  • 修改後看起來仍沿用舊設定：確認用戶端是否透過合併、覆寫或訂閱更新重新寫入 DNS 區段。

不要把 fallback 理解成單純「主要 DNS 完全失效後才啟用備用 DNS」。它會與篩選條件一起決定採用哪個結果。遷移排解問題時，先查看目前設定與記錄，再判斷是否需要調整這個部分。

遷移步驟：從語法檢查到實際連線驗證

建議保留舊核心、舊設定和用戶端覆寫內容，另外建立測試目錄。以下以獨立二進位檔示範，目錄名稱 mihomo-test 僅為本次測試使用。命令中的檔案和工作目錄都以目前終端機所在位置為基準：

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

-t 用來測試設定，-d 指定工作目錄，-f 指定設定檔。語法檢查通過只代表設定測試階段未發現阻斷性錯誤，不代表伺服器可連線、系統代理已設定，或 TUN 路由已生效。

第一輪只驗證本機代理連接埠

測試設定可使用以下基本入口。7890 是此處明確設定的混合代理連接埠，並非所有用戶端都固定使用此連接埠。將這些欄位合併至包含有效節點和策略群組的設定後，再啟動測試：

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

如果舊用戶端也占用 7890，請先停止舊核心，或為測試設定選擇未被使用的連接埠。不要只關閉舊用戶端視窗，因為背景服務可能仍在執行。此階段先不啟用 TUN，也不設定區域網路共享。

  1. 解析設定：修正未知節點類型、無效規則、缺少策略群組和規則檔路徑錯誤。
  2. 啟動核心：確認連接埠監聽成功，且沒有「位址已被占用」等啟動錯誤。
  3. 指定代理進行測試：在終端機執行下方命令，確認要求是否成功，以及連線面板是否有記錄。
  4. 恢復分流：分批加入規則提供者與地理規則，確認實際符合的規則。
  5. 最後再接管系統流量：先測試系統代理，再單獨啟用 TUN，避免同時引入多個變因。
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

這個命令會透過本機代理入口發出要求。若目標網域符合 DIRECT，仍可能以直連方式成功，因此還要查看連線面板中的策略鏈。測試通過不代表所有應用程式都經過遠端節點，也不代表下載速度已達線路上限。

常見遷移問題與選擇建議

現象 優先檢查 下一步操作
unknown proxy type 實際執行的核心、節點類型拼寫 確認用戶端沒有繼續呼叫舊二進位檔
找不到規則提供者 RULE-SET 引用名稱、檔案路徑、下載記錄 先用本機的小型規則檔確認解析
設定測試成功但無法連線 監聽連接埠、節點可連線性、策略選擇 先使用明確指定的代理要求，排除系統設定影響
啟用 TUN 後部分應用程式異常 路由、DNS、IPv6、其他 VPN 先恢復以系統代理為基準的設定，再逐項恢復流量接管
訂閱更新後設定遺失 設定來源、用戶端合併與覆寫順序 將自訂內容放在用戶端支援的持久化覆寫位置

需要 VLESS、Hysteria2、TUIC、GEOSITE 或更完整的現代分流設定時，mihomo 是較合適的比較對象。若只有基礎代理需求，則應繼續比較圖形化用戶端的維護狀態、平台整合與設定管理方式，而不是只看核心功能表做決定。

Clash評測網提供用戶端選擇與設定資料，並非用戶端開發者。實際遷移應以已安裝核心的文件、啟動記錄和連線記錄為準。將「設定能載入」、「要求能成功」、「規則符合正確」和「系統流量接管完整」分成四項驗收，會比一次替換所有設定更容易排除問題。

若要補足基礎概念，可查看名詞速查；規則和代理模式的檢查方式，請參閱使用手冊中的規則說明。

Clash 最新版下載