mihomo 核心與原版 Clash 有何不同？Mac 用戶端功能比較

先分清核心、圖形介面用戶端與訂閱

在 Mac 上選擇 Clash 用戶端，首先要確認實際執行的核心。圖形介面用戶端負責選單列入口、訂閱管理、系統代理開關與權限操作；核心則負責解析設定、建立代理連線、比對規則及處理 DNS。介面名稱相似，不代表支援的通訊協定也相同；用戶端更新，也不一定會同步更新核心。

mihomo 是由 Clash Meta 專案發展而來的代理核心。舊教學中的 Meta 設定，以及訂閱服務的 Clash Meta 輸出選項，通常都指向這個技術分支；不過，實際欄位仍應以所用 mihomo 版本支援的設定為準。原版 Clash 的公開儲存庫已於 2023 年停止維護，舊版安裝檔不會自動取得後續新增的通訊協定支援。

Mac 用戶需要確認的三個項目

• 用戶端版本：在應用程式選單的「關於」視窗查看，用來確認介面與管理功能。
• 核心版本：在用戶端的核心資訊頁面或啟動記錄中查看，特別留意 mihomo 名稱與完整版本號；不同用戶端的入口名稱可能不同。
• 訂閱輸出格式：確認訂閱服務產生的是 Clash 通用設定，還是專為 Clash Meta／mihomo 提供的設定。副檔名同為 YAML，不代表欄位完全相同。

功能比較：哪些差異會影響實際使用

是否值得升級，應視需求而定。如果目前訂閱只有傳統節點，瀏覽器透過系統代理也運作正常，換核心不一定會明顯提升速度。若訂閱包含 VLESS、Hysteria2，或需要更細緻的分流條件，核心能力差異就會直接影響設定能否載入、連線能否建立。

通訊協定擴充：為什麼新節點無法交給舊核心處理

VLESS、Reality 與傳輸層是不同參數

VLESS 是代理通訊協定，Reality 是相關的 TLS 安全機制選項，WebSocket、gRPC 等則是傳輸方式。訂閱中的 type: vless、reality-opts、network 各自有不同用途。支援 VLESS 不代表任意 Reality 設定都能連線；公鑰、短 ID、伺服器名稱與流量控制參數仍須符合服務端設定。

原版核心若回報不支援某種代理類型，修改節點顯示名稱、切換策略組或開啟系統代理都無法解決。必須改用支援該類型的核心，或請訂閱服務提供伺服器實際支援的其他節點。把 type: vless 強行改成 vmess 並非格式轉換，只會造成通訊協定不相容。

Hysteria2 與 TUIC 也取決於網路環境

這類通訊協定以 QUIC 為基礎，依賴 UDP 傳輸。mihomo 能解析設定，只代表核心具備相應的協定實作；如果目前的 Wi-Fi、公司網路或上游防火牆限制 UDP，連線仍可能逾時。遇到「其他節點正常，只有這類節點失敗」時，先用另一種通訊協定交叉測試，再檢查連接埠、驗證資訊與網路限制。

• 載入時立即報錯：優先檢查核心版本、節點類型與設定欄位，不必先修改 DNS。
• 載入成功但交握失敗：檢查服務端參數、Mac 系統時間與節點連線狀態。
• 已建立連線但部分服務無法使用：繼續檢查 UDP、規則比對結果、DNS 與路徑 MTU，避免直接歸咎於核心效能。

規則擴充：舊規則可以保留，新規則則要確認語意

傳統的 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 與 MATCH，仍是 mihomo 設定的重要組成。規則通常由上而下比對；前面的規則一旦符合，後面同類規則就不會再決定該連線的出口。遷移時，維持規則順序往往比單純保留文字更重要。

邏輯規則與程序比對

mihomo 支援以邏輯組合表達更複雜的條件，也提供程序相關的比對能力。這些功能適合結合網域、網路類型、程序等條件；不過，程序識別會受作業系統、流量入口與執行權限影響。在 Mac 上，不能只因規則寫了 PROCESS-NAME，就認定所有連線都能取得可靠的程序資訊；應查看連線詳細資料中的實際識別結果。

策略組名稱也是設定中的引用項目。規則末尾指定的策略名稱，必須能在設定中找到；如果訂閱更新後組名改了，本機規則卻仍保留舊名稱，就可能造成設定驗證失敗。遷移時應一併檢查 rules、proxy-groups 與 proxies，而非只複製規則區段。

規則集並非 mihomo 獨有

rule-providers 可將規則拆分為獨立資源，再透過 RULE-SET 引用。Clash Premium 也支援這類功能；mihomo 則進一步擴充格式與規則表達能力。檢查規則集時，需同時確認行為類型、內容格式、下載網址與實際檔案內容。

設定欄位：TUN、DNS 與嗅探應分別遷移

TUN 不等於規則模式，也不等於全域代理

TUN 透過虛擬網卡接收符合路由條件的流量；規則模式則決定流量進入後要選擇哪個出口。開啟 TUN 後，流量仍可依規則直連。「全域接管」描述的是流量入口的涵蓋範圍，不代表所有網站都會經過同一個代理節點。

在 macOS 上，tun.enable、tun.auto-route、tun.dns-hijack 等欄位也須配合用戶端的服務管理。部分用戶端會在產生執行設定時改寫這些欄位。遷移時先確認一般系統代理運作正常，再另外啟用 TUN，就能區分節點故障與權限、路由問題。

DNS：沿用 fake-ip 時也要檢查排除項目

dns.enhanced-mode 中的 fake-ip 會為網域配置合成位址，並由核心維護對應關係；它不是一般的公用 DNS 位址。舊版 Clash 也有這套機制。mihomo 的擴充主要在策略與處理選項，不能將整個 DNS 模組視為全新功能。

如果舊設定包含 fake-ip-filter，遷移時應保留必要的本機網域排除規則，並確認目前版本如何解讀過濾模式。若發生區域網路裝置名稱無法解析、系統入口網站驗證失敗或特定應用程式異常，應搭配 DNS 記錄檢查，而非將所有網域都加入排除清單。

嗅探：協助辨識網域，不會解密 HTTPS 內容

sniffer 可根據可觀察到的通訊協定交握資訊，協助辨識目標網域。它無法憑空取得所有連線的網域，也不能取代安裝根憑證後解密流量的做法。加密交握機制、應用程式行為與通訊協定差異都會影響辨識結果。遷移舊設定時，不建議為了「功能齊全」一次開啟所有嗅探選項。

舊設定能否直接沿用：分三個層面檢查

多數使用常見節點、基本策略組與傳統規則的舊 Clash 設定，都能作為遷移起點。但「YAML 可解析」、「核心接受欄位」與「應用程式實際能正常連網」是三個不同層面；不能只看到用戶端顯示匯入成功就結束驗證。

1. 結構層：檢查縮排、重複鍵與清單格式。YAML 使用空格縮排；含特殊字元的密碼與名稱應加上正確引號。
2. 核心層：確認節點通訊協定、規則類型、欄位組合與目前版本相容。有些未知欄位可能會被忽略；通過驗證也不代表每項功能都已生效。
3. 執行層：查看實際使用的設定、監聽連接埠、DNS 結果與連線命中的策略，並排除圖形介面用戶端覆寫設定的影響。

本機驗證範例

如果已取得可執行的 mihomo 檔案與本機設定，可以在終端機切換到相應目錄後執行以下兩條指令。範例使用 mihomo 與 config.yaml 作為檔名，請依本機實際檔案調整；使用圖形介面用戶端時，優先使用用戶端提供的設定檢查功能，不必修改應用程式套件中的檔案。

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

第一條指令用來確認實際執行的核心版本，第二條則檢查該核心能否載入設定。這並不能代替你驗證所有遠端節點、規則集下載與網站連線。遠端資源也可能受到網路連線與本機快取影響，啟動後仍需檢查記錄。

分開保存訂閱更新與本機修改

直接編輯訂閱下載產生的檔案，下一次更新時可能會被覆蓋。較穩妥的做法是保留訂閱原始檔，再透過用戶端支援的覆寫或合併機制加入本機規則。不同用戶端的合併順序不盡相同，應查看最終執行設定，確認規則是附加在末尾還是插入前方。

Mac 遷移步驟：先確認系統代理，再測試 TUN

1. 保留可還原的設定。匯出目前的訂閱與本機覆寫內容，記下系統代理連接埠、策略組選擇及舊核心版本。遷移前先結束舊用戶端，避免兩個程序爭用連接埠或同時修改系統代理。
2. 確認晶片與安裝檔。從蘋果選單 →「關於這台 Mac」查看「晶片」或「處理器」。Apple 晶片通常使用 arm64 安裝檔，Intel Mac 則使用 x64；架構會影響程式執行方式，不會改變 YAML 的基本語法。
3. 匯入設定並檢查記錄。先處理不支援的代理類型、找不到的策略組及規則集載入錯誤。此時先不要同時啟用 TUN、嗅探與複雜的 DNS 覆寫。
4. 確認系統代理。在 macOS Ventura 13 及更新版本中，前往「系統設定」→「網路」→ 目前的網路服務 →「詳細資訊」→「代理伺服器」。確認位址與連接埠符合用戶端實際的監聽設定。
5. 確認規則比對結果。造訪一個預期直連的網站與一個預期經代理連線的網站，並在用戶端的連線頁面確認比對到的規則及出口。網頁能開啟，不代表分流設定正確。
6. 視需要啟用 TUN。完成用戶端要求的授權或服務安裝後，再測試終端機、其他應用程式與區域網路存取。若遇到問題，先關閉 TUN，並與系統代理的結果比較。

指定明確連接埠測試，避免誤判終端機行為是核心故障

以下假設目前設定的混合代理連接埠確實為 7890。如果用戶端顯示其他連接埠，請改用實際數值。這條指令會明確指定 HTTP 代理，因此不受終端機是否讀取 macOS 系統代理設定影響：

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

收到 HTTP 回應，表示這次明確指定代理的請求已抵達目標；但這不能證明所有應用程式都已被接管，也無法單獨證明請求使用了遠端節點，實際出口仍由規則決定。如果顯示無法連線至 127.0.0.1:7890，請先檢查本機監聽狀態與連接埠，不要立刻更換訂閱。

測試 TUN 時，請使用未明確指定代理參數的請求，並留意終端機是否還設定了 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY。否則請求可能仍透過環境變數指定的代理送出，導致測試結果失準。

如何判斷是否需要升級 mihomo

• 訂閱已使用新通訊協定：優先確認核心支援 VLESS、Reality、Hysteria2 或 TUIC，並確認相關欄位適用於目前版本。
• 需要接管更多應用程式：也要評估用戶端的 macOS TUN 服務管理、權限提示與故障復原能力，不能只看核心功能列表。
• 需要複雜分流：檢查邏輯規則、程序識別與規則集格式，並針對重要規則安排實際連線測試。
• 目前使用狀況穩定：先備份再遷移，並保留原有的驗證清單；更新核心無法取代節點品質、網路環境與設定正確性。

對 Mac 用戶來說，可靠的升級流程是：確認圖形介面用戶端實際使用的核心，選擇相容的訂閱格式，驗證設定，再逐一測試系統代理、DNS 與 TUN。mihomo 擴充了通訊協定與分流能力；這些能力能否轉化為可用連線，取決於服務端參數、用戶端整合方式與本機網路設定是否一致。

若要進一步確認欄位含義，請參閱本站的通訊協定手冊；若遇到連接埠衝突或系統代理未還原，可先依照說明中心的排查步驟逐一確認。