mihomo 核心特性解析：與原版 Clash 的設定差異與遷移重點

在 Clash 客戶端中，圖形介面負責匯入設定、切換策略與顯示執行狀態，真正處理連線、DNS、規則比對與代理協定的是核心。mihomo 是由 Clash.Meta 延續發展而來的相容核心。許多客戶端已將其設為預設核心，但介面仍可能沿用 Clash、Meta 或 Premium 等名稱。因此，判斷目前功能時不能只看客戶端名稱，還要查看實際載入的核心類型、核心版本與啟動記錄。

舊版 Clash 設定通常可以作為遷移起點，但「能夠讀取」不代表執行結果完全一致。mihomo 擴充了代理協定、規則類型、DNS 控制、流量嗅探、TUN 路由與規則集格式，也對部分欄位採用更明確的處理方式。遷移重點不是一次啟用所有新功能，而是先維持原有分流結果，再逐項開啟增強功能。

核心定位與相容性界線

原版 Clash、Clash.Meta 與 mihomo 的關係

原版 Clash 建立了 YAML 設定、代理組、規則分流與外部控制介面等基礎結構。Clash.Meta 在此結構上擴充了協定、DNS、TUN、規則運算式與流量識別能力。專案後續以 mihomo 的名稱持續維護，因此設定文件、記錄或客戶端設定中仍可能看到 Meta 字樣。對遷移而言，可以將 mihomo 理解為延續 Clash 設定模型、同時加入更多網路處理能力的核心，而不是一套完全獨立的設定體系。

相容性界線主要受三個層面影響。第一層是核心本身：目前 mihomo 版本是否支援某個欄位。第二層是客戶端：介面能否將欄位寫入實際設定，以及啟動前是否會合併或覆寫。第三層是訂閱來源：遠端設定是否包含目標核心不認識的協定或規則。排查時需要將三個層面分開，不能只根據介面上的開關判斷最終設定。

為什麼同一份 YAML 會出現不同結果

一份設定在舊核心中啟動成功，換到 mihomo 後仍可能出現 DNS 結果、規則命中或路由範圍變化。常見原因包括客戶端自動注入 DNS 設定、不同核心對網路介面的選擇不同、GeoData 資料庫版本不同，以及 TUN 堆疊和系統路由實作發生變化。相反地，mihomo 專用欄位放回舊版 Clash 時，可能被拒絕、忽略或導致設定載入失敗。

遷移前應先確認客戶端是否提供「查看執行設定」或「匯出最終設定」功能。訂閱原文、經客戶端覆寫後的設定，以及核心實際載入的設定可能不是同一個檔案。只有最終設定才能解釋連接埠、DNS 與路由為何按照目前方式運作。

檢查層級	重點項目	常見現象
客戶端	核心選擇、覆寫指令碼、執行權限	介面已儲存，但核心參數沒有變化
核心	版本、支援欄位、啟動記錄	欄位未知、規則集解析失敗
設定	YAML 縮排、策略引用、連接埠	設定無法載入或策略組為空
系統網路	路由、DNS、網路介面、防火牆	TUN 已啟動，但部分程式無法連線

mihomo 的主要功能差異

代理協定與出站能力

原版 Clash 的設定核心，是將多個代理節點組織到策略組中，再由規則選擇策略。mihomo 保留這套邏輯，並擴充可用協定與傳輸選項。實際可用範圍仍取決於具體版本與客戶端的打包方式。遷移訂閱時，如果節點使用較新的協定，應先確認目前客戶端附帶的 mihomo 版本能解析對應欄位，再檢查伺服器端參數是否完整。

支援某種協定並不代表節點一定能連線。憑證名稱、傳輸層參數、使用者識別碼、加密方式、UDP 支援與系統時間都會影響握手。遇到單一節點失敗時，應先查看核心記錄中的連線階段，而不是反覆切換全域模式。若所有節點都失敗，再檢查訂閱是否被客戶端轉換、網路是否限制目標連接埠，以及 DNS 是否能解析伺服器位址。

規則系統與規則集

mihomo 延續由上到下比對規則的方式。連線命中第一條符合條件的規則後，就會交由指定策略處理。常見規則包括網域、網域後綴、IP 網段、程序、GeoIP、GeoSite 與遠端規則集。最後通常使用 MATCH 接收尚未命中的流量。

rules:
  - DOMAIN-SUFFIX,example.net,Proxy
  - GEOSITE,cn,DIRECT
  - GEOIP,cn,DIRECT,no-resolve
  - MATCH,Proxy

遷移時要檢查規則引用的策略名稱是否確實存在。策略名稱會區分具體字元，訂閱更新後如果將 Proxy 改成其他名稱，即使規則語法正確，也無法按照預期運作。GeoSite 與 GeoIP 還依賴本機資料檔案；資料庫遺失、下載失敗或版本不一致時，同一個網域可能得到不同判斷。

規則集適合將大量網域或網段從主設定中拆出。mihomo 支援多種規則集行為與格式，但舊版客戶端未必能識別較新的格式。遷移初期可以保留已驗證過的 YAML 或文字規則集，確認穩定後再考慮更精簡的格式。不要在同一次遷移中同時更換核心、規則資料來源與全部策略名稱，否則出現偏差時很難定位變數。

DNS、Fake IP 與網域對應

mihomo 的 DNS 模組可以獨立指定上游伺服器、代理節點網域解析伺服器、回退策略與按網域選擇的解析器。在 fake-ip 模式下，核心會向應用程式回傳保留位址，並保存此位址與原網域的對應關係。後續連線進入核心後，仍可依網域規則進行分流。這項機制對只提供目標 IP 的應用程式尤其重要，但也要求 DNS 請求確實進入核心。

如果系統仍將 DNS 請求傳送至其他本機服務，或瀏覽器啟用了獨立的加密 DNS，核心可能看不到原始網域。此時會出現網域規則未命中、偵測結果混雜或部分應用程式繞過分流的現象。TUN 情境下可搭配 DNS 劫持，但連接埠衝突、區域網路 DNS 與企業網路策略仍需個別評估。

TUN、嗅探與應用程式流量接管

系統代理通常只會影響遵循作業系統代理設定的程式。命令列工具、遊戲、部分商店應用程式與直接建立 UDP 連線的程式可能繞過系統代理。TUN 模式透過虛擬網路介面與系統路由接收更廣泛的流量，再交由核心判斷。mihomo 提供多種 TUN 堆疊與自動路由相關選項，但各作業系統的權限與路由實作不同。

流量嗅探用於從已建立的連線中識別網域資訊，以改善只有目標 IP 時的規則比對。它並非對所有協定都有效，也不應取代正確的 DNS 設定。遷移時建議先驗證一般 DNS 與規則，再依應用程式範圍啟用嗅探，避免將規則偏差與嗅探改寫目標混在一起。

設定欄位與語法遷移重點

先保留基本連接埠與控制介面

基本欄位在兩類核心之間相當接近。遷移時可以先保留混合連接埠、區域網路存取、執行模式、記錄等級與外部控制介面。連接埠號碼需要與客戶端介面及系統代理設定一致，控制介面則應搭配存取金鑰與合理的監聽範圍。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: "local-control-key"

mixed-port 同時接收 HTTP 與 SOCKS 代理請求，適合大多數桌面客戶端。如果舊設定分別使用 port 與 socks-port，可以暫時保留原有結構，確認使用這些連接埠的程式已完成遷移後再合併。不要讓多個客戶端同時監聽相同連接埠，否則後啟動的核心會直接回報位址已被使用。

規則提供器的行為類型

rule-providers 的關鍵不只是下載位址，還包括 behavior、format、本機路徑與更新週期。domain 適合網域集合，ipcidr 適合 IP 網段，classical 可容納帶有類型與策略前置條件的傳統規則。行為類型與檔案內容不相符時，規則集可能下載成功卻無法解析。

rule-providers:
  private-domains:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/private-domains.yaml
    url: https://example.invalid/rules/private-domains.yaml
    interval: 86400

rules:
  - RULE-SET,private-domains,DIRECT
  - MATCH,Proxy

規則提供器的 URL 只是資料來源，最終仍要透過 RULE-SET 放入有序規則清單。定義提供器但沒有引用，不會參與分流。遷移後應從連線記錄或客戶端連線頁面查看規則命中項，確認流量確實進入預期規則集。

DNS 設定的最小可驗證結構

DNS 設定適合分階段增加。第一階段只啟用核心 DNS、指定監聽位址與穩定的上游；第二階段啟用增強模式；第三階段再加入按網域設定的策略、代理節點專用解析器與過濾清單。以下結構展示欄位關係，具體上游應依所在網路與使用需求選擇。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

proxy-server-nameserver 主要用於解析代理伺服器本身的網域，避免建立代理連線前產生解析依賴。如果節點伺服器直接填寫 IP，這個欄位的影響較小。啟用 IPv6 前，應確認本機網路、代理節點與規則都能正確處理 IPv6；僅開啟 DNS 的 IPv6 回應，並不能保證後續連線具備可用路徑。

TUN 欄位不能脫離系統環境直接複製

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53

這組欄位表達的是常見方向，不代表所有系統都應使用完全相同的值。虛擬機器、容器、VPN、企業安全軟體與多網卡環境都會改變預設路由。Windows 通常需要客戶端具備建立虛擬介面與修改路由的權限；macOS 可能觸發網路延伸功能或系統授權；Linux 則需要相應的網路管理能力。若啟用後區域網路裝置無法連線，應檢查路由表與排除網段，而不是直接修改代理規則。

從舊版 Clash 遷移至 mihomo 的操作順序

記錄目前基準。
保存原始 YAML、客戶端覆寫規則與訂閱位址，記錄目前系統代理連接埠、控制連接埠、DNS 模式、TUN 狀態及正常運作的策略組。截圖只能作為輔助比對，仍應保留可還原的設定檔。
確認客戶端實際使用的核心。
在客戶端的核心設定、關於頁面或啟動記錄中查看核心名稱與版本。部分客戶端切換核心後需要完全重新啟動，只重新載入設定可能仍由舊程序處理流量。
執行語法檢查。
先處理 YAML 縮排、重複鍵、空策略組與不存在的策略引用。字串中包含冒號、井號或特殊字元時應使用引號。設定解析錯誤應從記錄指出的行附近開始檢查，但真正問題可能位於上一段縮排。
以系統代理驗證基本連線。
暫時關閉 TUN、嗅探與複雜 DNS 覆寫，只啟用一個已確認可用的代理節點與簡單規則。測試直連、代理與拒絕三種策略是否分別命中。如果基本連線失敗，優先處理節點與連接埠，不要繼續疊加進階功能。
恢復策略組與規則集。
逐一確認 select、url-test、fallback 等組內成員有效，規則目標與策略名稱一致。自動測試組的測試 URL、間隔與容差會影響選取結果，不能將一次延遲最低直接視為長期最佳。
遷移 DNS。
先確保核心監聽連接埠沒有被占用，再確認系統或 TUN 將查詢交給該監聽位址。分別測試一般網域、規則集網域與代理伺服器網域，觀察記錄中的解析器與最終規則。
最後啟用 TUN 與嗅探。
啟用後檢查預設路由、區域網路存取、休眠恢復與網路切換。對出現異常的程式記錄目標位址、協定與命中規則，再決定增加排除項目或調整嗅探範圍。

訂閱遷移還要區分「遠端設定」與「本機覆寫」。遠端更新可能覆蓋節點與策略組，本機覆寫則用於保留連接埠、DNS 或自訂規則。如果客戶端支援設定合併，應明確合併順序；否則每次訂閱更新後都要確認自訂欄位是否仍然存在。不要直接編輯客戶端管理的快取檔案，因為下次更新可能會重新產生該檔案。

遷移後的常見問題與定位方法

設定可以載入，但沒有流量經過核心

先確認系統代理是否指向目前的 mixed-port，再檢查客戶端程序是否確實在監聽該連接埠。瀏覽器可能保留舊代理設定，命令列程式也可能讀取環境變數中的舊連接埠。使用 TUN 時，則應查看虛擬介面是否建立、預設路由是否變更，以及目前網路介面是否被正確識別。

網域規則未命中，只顯示 IP 規則

這通常表示核心沒有取得目標網域。檢查應用程式是否使用獨立 DNS、系統查詢是否進入核心，以及 Fake IP 對應是否有效。如果只有少數協定無法提供網域，可以再評估嗅探；若所有程式都只剩 IP，應優先修復 DNS 路徑。還要確認規則順序，位於前面的 IP 或規則集可能已提前接收流量。

規則提供器更新失敗

檢查下載 URL、網路路徑、檔案格式與本機目錄權限。首次啟動時，遠端規則可能尚未快取；如果下載本身依賴尚未建立的代理策略，就會形成啟動階段的依賴問題。可以先讓規則來源具備明確的存取路徑，待檔案成功寫入後再恢復完整分流。記錄中的 HTTP 狀態、解析錯誤與檔案路徑，比介面統一顯示的「更新失敗」提示更有定位價值。

啟用 TUN 後區域網路或部分應用程式中斷

先關閉 TUN，驗證問題是否與虛擬路由有關，再檢查私有網段、閘道、區域網路 DNS 與其他 VPN。多網卡裝置還應確認自動偵測選取了目前正在連線的介面。如果只有特定 UDP 應用程式異常，應查看節點是否支援 UDP、策略組是否選取正確的出站，以及系統防火牆是否允許虛擬介面流量。

訂閱更新後策略名稱變更

規則、規則集與客戶端快速選擇功能都可能引用策略名稱。更新後若策略被重新命名，舊規則會指向不存在的目標。處理方式是統一命名並檢查所有引用，而不是只在介面中重新選取一次。對於需要長期保留的自訂規則，可使用穩定的本機策略組作為中介層，再將訂閱節點加入該組。

mihomo 遷移檢查清單

客戶端顯示的實際執行核心為預期的 mihomo 版本。
原始設定、訂閱資訊與客戶端覆寫均已分別備份。
HTTP、SOCKS 或混合連接埠未與其他程序衝突。
所有規則引用的策略組均存在，組內至少有一個可用成員。
規則按照具體條件到兜底條件排列，最後的 MATCH 指向明確策略。
GeoIP、GeoSite 與遠端規則集都能正常載入與更新。
DNS 查詢進入預期的監聽位址，代理伺服器網域能夠完成解析。
系統代理模式下的直連與代理流量都按照規則命中。
啟用 TUN 後，預設路由、區域網路存取與網路切換維持正常。
訂閱更新後，本機覆寫、策略名稱與自訂規則仍然有效。

mihomo 的價值主要在於持續維護的核心能力、更完整的規則與 DNS 控制，以及對現代網路接管情境的適配。遷移是否成功，應以連線記錄、規則命中、DNS 路徑與系統路由的實際結果為準。只要依照基本代理、規則、DNS、TUN 的順序逐層驗證，舊版 Clash 設定通常可以平穩過渡，同時保留清楚的故障回復節點。