mihomo 內核與原版 Clash 差異對照:規則語法、DNS 與 TUN 新特性
對照 mihomo(Clash Meta)內核與原版內核的關鍵差異:新增協議支援、規則集與 GeoSite 用法、DNS 分流策略、TUN 模式實作,並說明舊設定檔遷移時的相容要點。
對照 mihomo(Clash Meta)內核與原版內核的關鍵差異:新增協議支援、規則集與 GeoSite 用法、DNS 分流策略、TUN 模式實作,並說明舊設定檔遷移時的相容要點。
Clash 專案最初的內核倉庫由原作者維護,協議支援和規則語法相對保守,長期停留在一個穩定但功能有限的版本。社群在此基礎上發起了 Clash Meta 分支,持續加入新協議、新規則類型和更完整的 DNS/TUN 實作,後來獨立更名為 mihomo,成為事實上的社群主線。目前各家客戶端(包括本站收錄的多數 Windows、macOS、Android 版本)都已經把 mihomo 作為預設或可選內核,原版內核的更新頻率明顯放緩。
理解兩者差異,對判斷「為什麼某條規則不生效」「為什麼某個協議連不上」「設定檔搬到新客戶端後報錯」這類問題很有幫助——大多數根源都出在內核差異上,而不是設定檔本身寫錯了。
原版內核支援的協議集合基本固定在 Shadowsocks、ShadowsocksR、VMess、Trojan、Snell 等早期主流協議。mihomo 在此基礎上補齊了以下能力:
如果訂閱節點裡出現 vless、hysteria2、tuic 這類欄位,而客戶端提示節點類型不支援,通常就是仍在用原版內核,換成 mihomo 內核版本即可解決,不需要更換訂閱或重新產生節點。
原版內核的規則類型集中在 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR 和內建的 GEOIP,規則集需要以完整清單形式寫進設定檔或單獨維護規則檔案,更新和維護成本較高。mihomo 引入了更細的規則類型和更高效的規則集機制:
rule-providers:
reject:
type: http
behavior: domain
url: "https://example-ruleset/reject.txt"
path: ./ruleset/reject.yaml
interval: 86400
rules:
- RULE-SET,reject,REJECT
- GEOSITE,category-ads-all,REJECT
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY其中 rule-providers 支援定期從遠端拉取並本機快取,GEOSITE 規則直接引用預先編譯的域名分類庫(如 category-ads-all、cn),不需要手工列出域名。這類語法在原版內核裡不被識別,若設定檔中出現 rule-providers 或 GEOSITE 卻運行在原版內核上,會直接報語法錯誤或規則不生效,是排查規則失效問題時最先該確認的一點。
原版內核的 DNS 模組功能簡單,通常只能設定一組上游伺服器,難以按目標域名做精細分流,容易出現「本地域名走境外 DNS 解析導致存取變慢」或「DNS 洩漏真實所在地」的問題。mihomo 的 DNS 模組支援按策略分組:
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 223.5.5.5
- 119.29.29.29
nameserver-policy:
"geosite:cn": [223.5.5.5, 119.29.29.29]
"geosite:geolocation-!cn": [https://1.1.1.1/dns-query]
fake-ip-filter:
- "*.lan"
- "+.local"nameserver-policy 可以按 GeoSite 分類分別指定解析伺服器,中國大陸域名走境內 DNS,境外域名走加密 DNS,從源頭減少不必要的繞行。enhanced-mode 也從原版偏簡單的實作,擴展出更穩定的 fake-ip 模式,配合 TUN 使用時相容性更好。
如果從原版內核設定遷移到 mihomo,DNS 段的舊欄位(例如部分早期版本使用的 dns.fallback 簡單清單)建議按新語法重寫,而不是直接照抄舊檔案,否則可能只是不報錯但實際未生效。
TUN 模式讓 Clash 以虛擬網卡形式接管系統全局流量,不依賴應用層的系統代理設定,對不支援代理協議的程式(遊戲、部分命令列工具)尤為重要。原版內核的 TUN 實作出現較晚,設定項少,平台適配也有限,早期主要在 Linux 上可用,Windows/macOS 支援並不完整。
mihomo 的 TUN 模組重寫了網路堆疊處理邏輯,常見設定如下:
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53stack 可選 system、gvisor 等不同網路堆疊實作,兼顧相容性與效能;auto-route 和 auto-detect-interface 能自動設定路由表和識別出口網卡,減少手工設定路由的步驟。Windows、macOS、Android 客戶端目前的 TUN(或稱虛擬網卡/VPN 模式)入口基本都建立在 mihomo 內核之上,這也是選擇內核版本時優先考慮 mihomo 的直接原因之一。
排查問題前,先確認手上跑的到底是哪套內核,能省下大量無用嘗試。桌面客戶端一般在「設定 — 關於」或「內核管理」頁面直接顯示內核名稱與版本號,出現 mihomo 或 Meta 字樣即為社群內核;若只顯示 Clash v1.x 且沒有額外標記,大概率是原版內核。命令列使用者可以直接執行內核二進位檔加 -v 參數查看版本輸出,mihomo 會印出自身名稱與編譯時間。另一種間接判斷方式是在設定裡臨時加一條 GEOSITE 規則再重新載入:原版內核會因為不認識該規則類型而報錯退出,mihomo 則正常載入。Android 端可以看 VPN/TUN 開關是否可用、節點列表是否能識別 VLESS 與 Hysteria2 節點,兩項都支援的基本都是 mihomo 內核建置版本。
確認內核之後再對照下面這個思路判斷問題歸屬:節點類型報錯、規則語法報錯、DNS 分流失效、TUN 無法啟用這四類現象,若發生在原版內核上,優先換內核而不是改設定;若已經在 mihomo 上仍然出現,才需要回到設定檔本身逐段核對欄位拼寫、縮排層級與策略組引用關係。
功能更多通常意味著更高的開銷,但 mihomo 的實際表現並不比原版內核差多少。日常幾十個節點、兩三個遠端規則集的設定下,記憶體佔用大致在幾十 MB 到一百多 MB 之間,差異主要來自規則集快取和 GeoSite/GeoIP 資料檔案的載入,而不是內核本身的處理邏輯。真正影響佔用的是三個可控項:規則集數量與更新頻率、DNS 快取條目上限,以及 TUN 網路堆疊的選擇——gvisor 堆疊在使用者態處理封包,相容性好但 CPU 佔用略高;system 堆疊交由系統協議堆疊處理,吞吐更高,遇到個別環境不相容時再回退到 gvisor 即可。
穩定性方面,mihomo 迭代頻繁,新特性偶爾會帶來回歸問題,建議不要盲目追最新預覽版;生產環境優先選帶正式版本號的建置,遇到異常先回退到上一個可用版本,再到專案倉庫確認是否為已知問題。原版內核雖然長期不更新,但也因此幾乎不會出現新引入的缺陷,若你的設定只用到早期協議與基礎規則,繼續留在原版內核也沒有明顯風險。
把一份原版內核的設定檔遷移到 mihomo 內核,大多數情況下可以直接使用,因為 mihomo 對原版語法保持了向下相容。但仍有幾處需要留意:
MATCH 或 FINAL 放最後作為兜底,這條規則在 mihomo 中依然要保留在末尾,否則後續規則會被忽略;type 欄位在 mihomo 中新增了 smart、load-balance 等選項,原版不識別的新類型如果誤寫進舊內核設定會導致啟動失敗;整體來看,mihomo 已經是目前多數客戶端的預設選擇,新增協議、更精細的規則語法、按分類的 DNS 策略和更完整的 TUN 實作,都是原版內核短期內難以補齊的差距。除非有特殊的相容性需求,日常使用建議直接選擇整合 mihomo 內核的客戶端版本,設定檔按新語法逐步調整即可,不必強行保留舊寫法。