選擇建議：先確認核心，再看用戶端名稱

新設定需要 VLESS、Hysteria2、TUIC 或較新的規則功能時，建議先確認用戶端採用的 mihomo 版本是否符合需求。既有 Clash Premium 設定可作為遷移起點，但不建議將已停止維護的舊核心作為新部署的預設選擇。Clash Meta 與 mihomo 是同一專案演進過程中的不同名稱，並非兩套互不相關的協定體系。

對 Clash 蘋果版使用者來說，下載頁上的 App 名稱只能說明圖形介面是哪一款，無法直接證明內部核心支援哪些協定。有些用戶端可切換核心，有些則固定搭載特定版本；App 更新與核心更新也可能分開進行。排查問題時，至少記錄用戶端版本、核心名稱與版本，以及 macOS 或 iOS 版本。

Clash、Premium、Meta 與 mihomo 的關係

Clash 原版：開源核心與基本設定架構

Clash 原版建立了常見的 YAML 設定架構，包含代理節點、策略群組、規則與本機代理連接埠。許多用戶端沿用這套架構，因此不同 App 都可能出現 proxies、proxy-groups 和 rules。原專案於 2023 年停止原有的公開維護後，舊版仍可能正常運作，但不應期待它持續支援新協定或因應系統變動。

Clash Premium：已停止更新的閉源分支，不是付費訂閱

Clash Premium 是原專案曾推出的閉源核心分支，包含 TUN、規則集等延伸功能。此處的 Premium 指核心分支，並非節點服務商的付費方案，也不代表購買某種訂閱就能讓原版核心支援新協定。它同樣屬於舊有維護體系，不能因用戶端介面仍可啟動，就認定底層核心仍持續維護。

從 Clash Meta 到 mihomo：延續與擴充

Clash Meta 是以 Clash 為基礎發展的分支，後來更名為 mihomo。舊教學、訂閱轉換選項與用戶端設定中，仍可能看到 Meta 這個名稱。看到「Meta 核心」時，應進一步確認實際版本，不要只憑名稱判斷相容性。較新的 mihomo 設定也不一定能在早期 Meta 版本上運作。

  • 專案名稱：確認維護來源，以及應參考哪一套文件。
  • 核心版本：確認是否包含特定欄位、協定選項與修正。
  • 用戶端版本：確認介面、輔助服務與設定合併邏輯。
  • 系統版本：確認網路權限、沙盒與擴充機制的限制。

協定支援差異：節點名稱不能取代協定類型

節點名稱可以自行命名，真正決定解析方式的是 YAML 中的 type 與相關欄位。例如，名稱為「高速線路」的節點可能使用 Trojan，也可能使用 Hysteria2。判斷相容性時，應查看訂閱的實際內容；提供設定片段給他人前，請先移除密碼、UUID、伺服器位址與訂閱權杖。

檢查項目 Clash 原版 Clash Premium mihomo
SS、VMess、Trojan 等基本協定 支援常見設定 支援常見設定 支援，具體選項請依版本確認
VLESS 與 REALITY 相關設定 不建議作為相容目標 不建議作為相容目標 支援相應設定，需確認欄位
Hysteria2、TUIC 不支援這些新協定 不應視為完整支援 支援，協定版本與參數需相符
內建 TUN 原始開源版未提供 提供舊版實作 有提供，但受平台與權限限制
維護狀態 舊版相容與既有設定遷移 舊版相容與既有設定遷移 請持續查閱專案的發布紀錄

同一協定也可能有不同參數

支援某種協定，不代表支援它的所有傳輸方式、加密方式與延伸選項。VLESS 節點還可能涉及 flow、TLS、REALITY 與傳輸層設定；TUIC 的不同協定版本也不能混用。若記錄中出現 unsupported proxy type，請先確認核心類型；若設定載入成功但握手失敗，再檢查驗證資料、時間、TLS 參數與網路連線狀況。

訂閱轉換只能將輸入內容轉成目標格式，無法替核心補上協定實作。將 Hysteria2 節點轉換成一份名為「Clash」的 YAML，不會讓 Clash 原版因此支援 Hysteria2。選擇轉換目標時，應確認要使用傳統 Clash 相容格式，還是 mihomo 延伸格式。

規則與 DNS：語法相近，執行結果未必相同

常見的 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 與末尾的 MATCH，通常是遷移時較容易保留的部分。規則會依序比對，前面符合的規則通常會決定流量出口；若將涵蓋範圍較廣的規則放在前面，後續更精細的規則可能就不會生效。策略群組名稱也必須與規則中的引用完全一致，不能只遷移節點而漏掉群組。

規則集與延伸規則須逐項確認

  • 外部規則集：檢查 rule-providers 的格式、來源與更新方式，以及 RULE-SET 引用是否有效。不要假設任意 Clash 原版都支援 Premium 或 mihomo 的完整規則集功能。
  • 地理資料：GEOSITE 等規則須仰賴核心支援及相應資料檔。只複製規則文字，無法取代資料資源的下載與載入。
  • 程序規則：功能是否可用取決於系統能否提供程序資訊；macOS 上的行為不能直接套用到 iOS 網路延伸功能。
  • 指令碼策略：Premium 舊版指令碼寫法不代表 mihomo 通用相容介面；遷移時建議改寫為明確的規則與策略群組。

DNS 設定會影響規則可取得的資訊

fake-ip 與 redir-host 是不同的 DNS 運作模式。fake-ip 會透過位址映射協助核心關聯網域與連線；redir-host 則回傳解析取得的位址，兩者並非在所有網路環境中都能互換。遷移後若出現「節點延遲測試正常，網頁卻無法開啟」，請一併檢查 DNS 上游是否可連線、網域分流設定，以及系統是否實際使用核心 DNS。

macOS 與 iOS 的 TUN 實作差異

系統代理與 TUN 接收流量的方式不同。系統代理主要供遵循代理設定的 App 使用；TUN 則透過虛擬網路介面與路由處理流量，可涵蓋更多不讀取系統代理設定的 App，但不代表所有流量都一定會經過代理節點。最終出口仍由路由、排除項目、規則與直連策略共同決定。

macOS：輔助服務不等同網路延伸功能

macOS 用戶端可能透過具備權限的輔助服務建立 TUN，也可能使用 Apple 的網路延伸機制。不同實作的授權步驟不一，不能一概將「啟用 TUN」解讀為「必須核准系統延伸功能」。macOS 13 及更新版本可先前往「系統設定」→「網路」，查看 VPN 與網路服務狀態；若用戶端明確提示系統軟體遭到封鎖，再依照指示前往「系統設定」→「隱私權與安全性」確認授權。

mihomo 的 TUN 設定常見 auto-route、auto-detect-interface 與 dns-hijack。自動偵測出口適用於常見的單一出口環境；若有多張網卡、其他 VPN 或特殊路由，仍須確認實際結果。macOS 出現 utun 介面，並不能單獨證明目前用戶端已成功接管網路，因為系統與其他 VPN 也可能建立相同類型的介面。

iOS：網路延伸功能與 App 權限共同決定

iPhone 與 iPad 通常透過 App 的 Network Extension 隧道延伸功能處理網路流量，不能將 macOS 可執行檔複製過去使用。首次建立隧道時，通常需要確認新增 VPN 設定；之後可前往「設定」→「一般」→「VPN 與裝置管理」查看相關項目。即使用戶端能匯入 Clash 格式的設定，實際支援的協定與欄位仍須以該 App 的核心及文件為準。

因此，「同一份 YAML 能在 Mac 匯入」只代表 Mac 端解析成功，不代表 iOS 端的程序規則、檔案路徑與背景更新方式完全相同。多台裝置共用訂閱時，可統一節點與主要分流規則，並由各裝置分別管理平台權限、檔案位置與網路接管設定。

遷移至 mihomo：從最小設定逐步還原

以下是用來檢查解析、連接埠繫結與基本規則的最小設定。設定中只有直連策略，沒有代理節點，因此無法用來確認遠端節點是否可用。範例將 HTTP 與 SOCKS 混合連接埠設為 7890，並僅繫結本機迴圈位址；這只是範例，不是所有用戶端的固定預設值。

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

proxy-groups:
  - name: DIRECT-TEST
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,DIRECT-TEST

先檢查語法，再檢查網路

單獨執行核心時，可使用以下指令記錄版本並測試設定。檔案路徑以目前目錄為準；若使用圖形介面用戶端，請透過它的設定檢查功能驗證最終合併結果，避免同時啟動第二個核心而占用相同連接埠。

./mihomo -v
./mihomo -t -f ./config.yaml
lsof -nP -iTCP:7890 -sTCP:LISTEN

-t 檢查通過，只代表設定格式正確，不表示節點、DNS 與規則都已驗證。有些檢查也會讀取本機資源或取得外部資料；若失敗，須區分是語法錯誤、資源缺漏，還是網路請求失敗。若記錄出現 address already in use，請先確認是否已有用戶端占用 7890，不要為了排除錯誤就貿然開放區域網路存取。

  1. 備份：保存舊設定、核心版本、用戶端覆寫設定與目前的策略群組選擇，並保留可直接還原的副本。
  2. 確認基本功能：先關閉 TUN，以最小設定確認解析與本機連接埠正常，再匯入已知可用的節點。
  3. 還原分流設定：依序加入策略群組、規則、規則集與 DNS，每次只變更一類內容，並查看連線實際符合哪條規則。
  4. 最後再啟用 TUN：檢查權限、預設出口與 DNS 接管，再測試瀏覽器以外的 App。
  5. 確認可回復：結束新用戶端後，確認系統代理與隧道已關閉，再還原舊版本；避免兩個工具同時修改路由。

常見問題：從錯誤訊息找出相容性問題

設定可以匯入，為什麼啟用後馬上失敗？

部分用戶端只會在匯入時檢查 YAML 結構，啟用後才交由核心解析。請先查看啟動記錄，釐清是未知協定、欄位無效、找不到策略群組，還是監聽連接埠衝突。若服務商提供多種訂閱格式，請選擇符合目前核心的格式，不要反覆修改訂閱網址中的名稱。

舊版 Clash Meta 設定能直接用於 mihomo 嗎？

常用節點與基本規則通常具有良好的延續性，但無法保證所有延伸欄位、實驗功能與預設行為完全相同。請先執行設定檢查，再核對發布說明中與 DNS、TUN 及協定參數相關的變更。即使檢查沒有報錯，也要透過連線記錄確認規則命中情況與實際出口。

Apple 晶片 Mac 的節點延遲偏高，是架構選錯了嗎？

不應只根據延遲判斷架構。可前往「應用程式」→「工具程式」→「活動監視器」查看相關程序的種類，確認用戶端與核心的執行情況。網路延遲應優先檢查節點線路、DNS、測試目標，以及是否啟用其他 VPN；介面中的單次延遲測試也不等於網頁完整載入所需時間。

升級核心後，需要立刻啟用 TUN 嗎？

不需要。先透過系統代理測試節點與規則，可減少權限、路由與 DNS 接管造成的變因。只有目標 App 不讀取系統代理，或確實需要接管更多流量時，再另外啟用 TUN。若遇到特定問題，可參考疑難排解指南，依照記錄與網路層級逐步檢查。

最後可從三個問題確認是否適合：訂閱中的協定能否解析、所需規則能否正確執行，以及目前 Apple 裝置上的網路接管是否可靠。核心名稱可用來確認技術路線，實際相容性則須以準確版本與可重現的測試結果為準。