什麼是 Clash Meta 與 Mihomo 更名
Clash Meta 是由 MetaCubeX 團隊維護的 Clash 核心增強版本;在原版 Clash 宣布停止維護後,Clash Meta 憑藉活躍的社群支援與持續迭代,迅速成為最受歡迎的 Clash 核心替代方案。自 2024 年起,專案正式將 GitHub 儲存庫名稱更名為 Mihomo,但核心功能與設定格式維持完全向下相容,現有使用者無須擔心遷移成本。
Mihomo 的更名不只是品牌重塑,更代表專案從「Clash 相容核心」走向更獨立、更成熟的網路代理工具體系。新版 Mihomo 不再侷限於複製原版 Clash 的功能邊界,而是主動擁抱新一代代理協定,同時對核心的規則引擎、DNS 子系統與記憶體管理進行深度重構,整體效能與穩定性較早期版本有明顯提升。
若您仍在使用舊版 Clash 核心,或長期停留在較早的 Clash Meta 版本,現在正是升級到最新 Mihomo 的好時機。本文以 Windows、macOS 與 Android 三大平台為例,手把手帶您完成升級流程,並說明新版本帶來的三項重點協定支援。
升級前的準備工作
在正式開始升級前,建議您先花幾分鐘完成下列準備,以確保整個遷移過程順利無誤。
1. 備份現有設定檔
將目前使用的 config.yaml 及所有關聯的規則檔複製到安全位置(例如桌面或雲端硬碟)。若您同時維護多份設定檔,建議逐一匯出並以版本號或日期區分,方便回復時快速找到對應檔案。
2. 確認 GUI 用戶端版本
不同圖形介面用戶端(GUI)對 Mihomo 核心的支援程度各異。升級前請確認您使用的 GUI 已適配目前最新的 Mihomo 核心版本。本站下載頁提供經過驗證的最新用戶端整合包,一併更新 GUI 與核心,可避免版本不符導致無法啟動。
3. 檢查訂閱連結相容性
絕大多數服務商提供的訂閱連結在格式上與 Mihomo 完全相容,無須修改。僅少數仍採舊版格式(例如僅含舊版 SS)的訂閱可能在解析時出錯。若升級後發現節點無法載入,請參考本文「常見遷移問題解答」一節。
升級操作步驟詳解
Windows 平台升級
- 開啟目前用戶端,進入「關於」或「核心設定」頁面,記錄目前 Mihomo 核心版本號。
- 前往本站 用戶端下載頁,取得最新 Windows 版安裝包(內含最新 Mihomo 核心)。
- 關閉正在執行的 Clash 用戶端處理程序(在系統匣圖示上按右鍵 → 結束)。
- 執行下載的安裝程式並依精靈操作;安裝程式會自動替換核心檔案,通常無須手動覆蓋。
- 安裝完成後重新啟動用戶端,在「關於」頁面確認版本已更新至最新。
- 點選「測試延遲」或「檢查連線」,確認代理節點運作正常。
macOS 平台升級
- 若使用 ClashX Pro、Mihomo Party 等 GUI 用戶端,請直接從本站下載最新版
.dmg安裝包,開啟後將 App 拖入「應用程式」資料夾覆蓋即可。 - 若透過 Homebrew 管理核心,可在終端機執行下列指令:
# Stop the existing service brew services stop mihomo # Update package to latest version brew upgrade mihomo # Restart the service brew services start mihomo - 若 macOS 提示「無法驗證開發者」,請前往「系統設定 → 隱私權與安全性」,點選「仍要開啟」。
- 設定檔無須任何修改即可沿用。
Android 平台升級
Android 使用者建議直接前往本站下載頁取得最新版 APK,覆蓋安裝後設定檔與訂閱資訊通常會自動保留,無須重新匯入。安裝完成後進入「關於」頁面核對核心版本號,確認為最新即可。
Hysteria2 協定:高速、低延遲的新選擇
Hysteria2 是 Mihomo 導入後相當受歡迎的新協定之一。它基於 QUIC 建構,針對高丟包、高延遲等較差的網路環境做了深度最佳化。在部分實測情境中,Hysteria2 的吞吐量可比傳統 TCP 代理協定高出約 5~10 倍,特別適合跨區、線路品質不穩時使用。
Hysteria2 的核心優勢
- 抗丟包能力強:以 UDP/QUIC 傳輸,即使線路丟包率偏高,速度仍能維持相對穩定。
- 連線建立快:QUIC 的 0-RTT 特性使連線建立速度明顯快於傳統 TLS over TCP。
- 流量特徵較不顯眼:Hysteria2 的流量外觀類似 HTTPS,較不易被深度封包檢測(DPI)辨識與阻擋。
- Mihomo 原生支援:無須額外外掛或獨立二進位檔,直接在設定檔中宣告節點類型即可使用。
Hysteria2 設定範例
在 config.yaml 的 proxies 區段中加入下列節點宣告:
proxies:
- name: "HY2-Node"
type: hysteria2
server: your-server.example.com
port: 443
password: "your-password"
sni: your-server.example.com
skip-cert-verify: false
up: "100 Mbps"
down: "200 Mbps"
其中 up 與 down 用於宣告用戶端上下行頻寬,填寫實際數值有助於 Hysteria2 進行壅塞控制最佳化,建議如實填寫。
TUIC v5 協定:低握手延遲的新選擇
TUIC(Transparent UDP in TCP Carrier)v5 是另一個基於 QUIC 的現代代理協定,以極低的握手延遲與高效率的連線複用著稱。相較之下 Hysteria2 更側重頻寬利用率,TUIC v5 在連線複用上更具優勢,非常適合頻繁建立短連線的情境,例如大量分頁瀏覽、即時通訊,或併發請求較多的應用程式。
Mihomo 對 TUIC v5 的支援為開箱即用,設定格式如下:
proxies:
- name: "TUIC-Node"
type: tuic
server: your-server.example.com
port: 443
uuid: "your-uuid-here"
password: "your-password"
version: 5
alpn:
- h3
congestion-controller: bbr
udp-relay-mode: native
其中 congestion-controller: bbr 指定使用 BBR 壅塞控制演算法,在多數網路環境下吞吐量表現較佳;udp-relay-mode: native 則使用原生 UDP 轉發,適合需要低延遲 UDP 的場景(例如遊戲、視訊會議)。
VLESS + Reality:高強度對抗審查的協定方案
VLESS+Reality 是公認抗審查能力極強的代理方案之一,核心概念是「借用」真實網站的 TLS 憑證指紋,使代理流量在特徵上與造訪合法 HTTPS 網站的一般流量一致,從而降低被以流量特徵辨識、阻擋的機率。
與依賴混淆的傳統協定不同,VLESS+Reality 不要求伺服器端持有目標網域的真實 SSL 憑證,而是透過 Reality 借用外部網站(例如微軟、Cloudflare 等)的公開 TLS 指紋,並結合內建的 X25519 金鑰對完成驗證,更接近「流量難以區分」的目標。
VLESS+Reality 設定範例
proxies:
- name: "VLESS-Reality"
type: vless
server: your-server.example.com
port: 443
uuid: "your-uuid-here"
network: tcp
tls: true
udp: true
flow: xtls-rprx-vision
servername: www.microsoft.com
reality-opts:
public-key: "your-public-key"
short-id: "your-short-id"
其中 flow: xtls-rprx-vision 是啟用 XTLS Vision 資料流處理的關鍵欄位,用於對 TLS 內層資料做特徵處理,進一步降低被辨識的風險。servername 填寫欲借用 TLS 指紋的合法網站網域;public-key 與 short-id 由伺服器端產生後提供。
規則引擎與 DNS 最佳化
除了協定層更新,Mihomo 對規則引擎與 DNS 子系統的重構同樣值得關注;這些改進在日常使用中的感受有時甚至比新協定更明顯。
規則引擎效能大幅提升
新版規則引擎採用更高效的雜湊比對演算法,對含數萬條規則的大型規則集(例如 GitHub 上常見的 Loyalsoldier 規則集),比對速度較舊版顯著提升,同時系統記憶體佔用也明顯下降。這表示即使規則集複雜,Mihomo 對系統資源的消耗仍能維持在較低水準。
DNS 分流策略更細緻
新版 Mihomo 支援更細緻的 DNS 分流策略,可依網域後綴、geosite 集合與自訂規則分別指定不同上游 DNS,有助於緩解跨區混用時的 DNS 污染問題。以下為建議的 DNS 設定範本(可依您實際網路環境調整上游):
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- localhost.ptlogin2.qq.com
nameserver:
- https://223.5.5.5/dns-query
- https://119.29.29.29/dns-query
fallback:
- https://1.1.1.1/dns-query
- https://8.8.8.8/dns-query
fallback-filter:
geoip: true
geoip-code: CN
geosite:
- gfw
上述範例中,nameserver 使用特定 DoH 伺服器處理一般網域查詢;fallback 使用國際 DoH 處理受污染或需繞過限制的解析;fallback-filter 則透過 GeoIP 與 GeoSite 判斷何時啟用 fallback,減少不必要的延遲。若您主要於台灣使用,可將 nameserver 改為慣用的在地或可信上游。
GeoIP 與 GeoSite 資料庫更新
Mihomo 使用 geoip.dat 與 geosite.dat 支援基於地理位置的規則比對。這兩個檔會隨版本持續更新,建議定期檢查用戶端是否有新版本,以維持規則資料正確,避免出現誤走代理或無法連線的情況。
常見遷移問題解答
以下為使用者從舊版 Clash 或早期 Clash Meta 升級至 Mihomo 時最常遇到的問題與處理方式。
Q:升級後用戶端出現「unknown config field」而無法啟動?
常見原因是設定檔中含有僅屬於特定 GUI 的欄位(例如 clash-for-windows 區塊,為原 CFW 的擴充)。請檢查並刪除或註解這些非標準欄位後重新載入設定,通常即可正常啟動。
Q:原本的訂閱還能繼續用嗎?
絕大多數情況下可直接沿用,無須重新取得訂閱連結。若訂閱內含舊版 Shadowsocks 參數或已廢棄的 VMess 參數,部分節點可能無法解析,但不影響其他節點。若大量節點解析失敗,建議聯絡服務商更新訂閱格式。
Q:Mihomo 與原版 Clash 的設定格式有什麼差別?
核心欄位(代理節點、代理群組、規則、DNS、TUN 等)完全相容,可直接沿用。Mihomo 在此基礎上新增 hysteria2、tuic、vless 等節點類型,以及 reality-opts、ssh(實驗性)等擴充欄位。舊版設定檔通常無須修改即可使用。
Q:升級後 TUN 模式無法正常運作?
Mihomo 的 TUN 模式須以系統管理員權限(Windows)或 root 權限(Linux/macOS)執行。並請確認設定檔中 tun 區段正確:
tun:
enable: true
stack: system # or "gvisor" as alternative
auto-route: true
auto-detect-interface: true
dns-hijack:
- "any:53"
若使用 gvisor 模式遇到相容性問題,可改試 system 模式。
Q:如何確認目前使用的 Mihomo 核心版本?
在 GUI 用戶端的「關於」頁面通常可直接查看版本資訊。若以指令列執行,可執行 mihomo -v 或 mihomo version 取得完整版本號。建議維持在最新穩定版,以取得最佳相容性與安全性修補。
為什麼推薦使用本站 Clash 用戶端
透過以上升級說明,相信您已對 Mihomo 的新特性有整體認識。理論上您可自行從 GitHub 下載最新 Mihomo 核心並手動設定執行;但實務上不少使用者反映過程比預期繁瑣:版本更新需手動替換檔案、GUI 與核心適配須自行排除、新協定參數填錯時不易追錯等。
本站提供的 Clash 用戶端,即是為了降低上述門檻而整理的一站式方案。與直接從 GitHub 取得相比,使用本站版本大致有這些優勢:
- 版本經相容性驗證:我們在新核心發布後進行多平台測試,確保 GUI 與核心版本一致,您取得的多為可開箱即用的穩定組合。
- 一鍵匯入訂閱,快速上手:開啟用戶端、貼上訂閱連結、點選「更新」,短時間內即可完成設定,無須手寫 YAML。
- 三大新協定內建支援:Hysteria2、TUIC v5、VLESS+Reality 的解析與使用能力已內建,只要節點支援,用戶端即可正確辨識並使用。
- 預設重視 DNS 防洩漏:我們預先採用較安全的 DNS 設定方向,降低真實 DNS 查詢在不知情下繞過代理、洩漏給電信業者的風險。
- 全平台一致的訂閱體驗:Windows、macOS、Android、iOS、Linux 皆有對應優化版本,同一條訂閱連結可在多裝置直接匯入使用。
若您目前的 Clash 用戶端較舊,或常遇到連線不穩、協定不支援等情況,不妨前往本站下載頁,依裝置系統選擇對應版本,免費下載並體驗最新 Clash 用戶端。