舊核心謝幕 · mihomo 接棒

Clash Meta下載全平台用戶端與設定入口

下載官方Clash 查看教學

圍繞 mihomo 核心整理 Windows、macOS、Android、iOS 與 Linux 用戶端入口，並提供 中文設定文件和規則分流教學。舊 Clash 核心停止開發後，常用功能由新核心持續承接。

永久免費 程式碼開源 五大平台 中文文件

選擇平台

Windows Android iOS macOS Linux

常見線路地區

美國 日本 香港 新加坡 韓國

核心世代對照台

mihomo 接棒後的核心能力

從系統流量接管到 DNS 解析鏈路，常用設定不再只是簡單轉送。選擇左側功能，即可查看它解決的問題、設定入口與使用範圍。

TUN 流量接管

mihomo core

TUN 模式用於接管不讀取系統代理設定的應用程式，包括部分遊戲啟動器、命令列工具和獨立網路程式。啟用後，核心會透過虛擬網卡統一接收流量，再交由規則系統判斷直連、代理或拒絕。與只開啟系統代理相比，涵蓋範圍更完整，但也更依賴管理員權限、路由設定與 DNS 配合。初次使用應先採用 mixed 堆疊，並確認本地網段仍可直連；遇到區域網路裝置無法連線時，先檢查路由排除項，不要反覆更換節點。

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: false

用戶端下載入口

依作業系統選擇 Clash 用戶端

圖形用戶端負責匯入訂閱、切換策略與控制系統代理，mihomo 核心則負責實際連線與規則判斷。先依裝置系統進入下載頁，再按照安裝方式與使用習慣選擇用戶端。

Windows

適合桌面辦公、瀏覽器代理以及需要 TUN 接管的程式。下載頁集中列出圖形用戶端，並區分仍在維護與已封存的專案。安裝後先匯入訂閱，再按需開啟系統代理；只有不讀取系統代理的應用程式才需要進一步設定 TUN。

前往下載

macOS

適合 Apple Silicon 與 Intel Mac。選擇安裝套件時先確認處理器架構，首次開啟還需要允許系統網路延伸功能或代理權限。選單列用戶端方便日常切換策略，桌面型用戶端則更適合查看連線記錄、規則命中與訂閱內容。

前往下載

Android

Android 用戶端通常透過系統 VPN 介面接管應用程式流量，不需要修改每個應用程式的代理設定。匯入設定後，可以按應用程式決定是否經過代理。遇到背景斷線時，應檢查系統省電策略、VPN 權限與背景執行限制，而不是只調整節點。

前往下載

iOS

iPhone 與 iPad 透過系統網路延伸功能建立代理連線。安裝後需要允許加入 VPN 設定，再於用戶端匯入訂閱。行動網路與 Wi-Fi 切換時，系統可能會重新建立連線；若規則未如預期生效，可先重新載入設定並檢查目前的策略組。

前往下載

Linux

桌面使用者可以選擇具備圖形介面的用戶端；伺服器、軟路由與容器環境則更常直接執行 mihomo 核心。直接執行核心時，需要自行管理設定路徑、執行權限、記錄與開機啟動，並釐清透明代理所需的路由與防火牆規則。

前往下載
查看所有用戶端 →

快速入門預覽

從安裝到規則模式的三步驟主線

第一次使用不必立即修改所有設定。先完成用戶端安裝與訂閱匯入，確認基本連線正常後，再逐步處理策略組、DNS 與 TUN。

  1. 01

    安裝與系統相符的用戶端

    進入下載頁後選擇目前的作業系統，再依處理器架構與使用情境挑選用戶端。Windows 與 macOS 使用者通常從圖形用戶端開始；Android 與 iOS 需要授予系統 VPN 權限；Linux 伺服器使用者則可直接使用核心。安裝完成後先開啟用戶端，確認介面能正常載入，不要在尚未匯入設定時反覆切換系統代理。

  2. 02

    匯入訂閱並檢查策略組

    在設定或訂閱頁面貼上服務提供者給出的訂閱網址，更新後選取剛匯入的設定。接著進入代理或策略頁面，確認選擇組中已出現可用節點。訂閱網址不是一般網頁連結，不應直接在瀏覽器中判斷內容是否完整；若用戶端提示解析失敗，應檢查複製時是否帶入空格、網址是否已過期，以及設定內容是否符合 YAML 結構。

  3. 03

    開啟規則模式並驗證命中

    先選擇規則模式，再開啟系統代理或行動裝置 VPN。開啟連線記錄，觀察請求是否進入預期的策略組，同時造訪一個本地服務，確認直連規則仍然有效。若一般瀏覽器可以連線、獨立應用程式卻沒有流量，再考慮啟用 TUN；若網域解析異常，則回到 DNS 設定檢查增強模式與過濾清單。依照這個順序排查，可以分開定位節點、規則、系統接管與解析問題。

查看完整教學 →

開源生態與核心交接

從舊 Clash 核心到 mihomo 的工程關係

用戶端介面與代理核心是兩個獨立元件。理解這層關係，才能判斷更新來自哪裡，也能在發生問題時找到正確的記錄與設定入口。

A

專案歷史：舊核心停止開發，相容設定持續沿用

Clash 最初建立了以 YAML 設定、規則清單與策略組為核心的使用方式，許多桌面與行動用戶端都圍繞這套結構開發。舊核心停止開發後，使用者既有的訂閱格式、規則習慣與用戶端操作邏輯並沒有同時消失。mihomo 在相容常見 Clash 設定的基礎上持續維護核心功能，因此今天看到的許多「Clash Meta 用戶端」，本質上是由圖形介面呼叫 mihomo，完成連線、DNS、規則比對與流量接管。

這種交接表示遷移通常不需要從頭重寫設定，但也不代表所有舊欄位都應原樣保留。長期未更新的範本可能包含已失去意義的選項，或依賴舊用戶端的私有欄位。遷移時較穩妥的做法是先匯入原設定、查看啟動記錄，再逐項整理 DNS、TUN 與策略組，而不是一次複製大量覆寫內容。

B

開源生態：核心、介面與規則集分開演進

mihomo 核心負責網路連線與規則執行，Clash Plus、Clash Verge Rev、FlClash 等用戶端負責圖形操作、系統整合與設定管理，規則集專案則提供可重複使用的網域或 IP 分類。這些元件可以依各自節奏更新，使用者也能依平台更換介面，同時保留相近的設定思路。遇到介面崩潰、系統匣失效或系統代理無法切換時，應優先檢查用戶端；遇到設定解析、協定連線與規則命中問題時，則應查看核心記錄。

分層結構也減少了對單一用戶端的依賴。桌面端設定可以遷移到另一款呼叫 mihomo 的用戶端，伺服器設定也能在確認路徑與權限後直接交由核心執行。不過，不同用戶端對覆寫腳本、設定儲存與系統服務的實作並不相同，遷移前仍需匯出本地規則，並記錄目前使用的 DNS 與策略設定。

C

核心關係：設定負責宣告，核心負責執行

一份 Clash 設定主要宣告連接埠、代理節點、策略組、DNS 與規則。用戶端讀取設定後，可能先合併訂閱與本地覆寫，再將最終結果交給 mihomo。真正決定連線走向的是合併後的執行設定，而不是訂閱原文或某個獨立的覆寫片段。排查問題時，應找出用戶端產生的最終設定並結合記錄判斷，這比只盯著訂閱編輯器更可靠。

規則會依順序比對，前面的具體條件通常優先於後面的寬泛條件；策略組則決定命中後如何選擇節點。DNS 解析會影響網域規則與 IP 規則看到的目標，TUN 又決定哪些應用程式流量能進入核心。四者彼此連動，因此「更換節點仍然無效」不能直接證明節點有問題，也可能是請求根本沒有進入核心，或被更前面的規則送往其他策略。

D

更新機制：先看變更範圍，再決定是否調整設定

用戶端更新與核心更新解決的問題不同。用戶端更新可能改變安裝方式、介面配置、系統服務與訂閱管理；核心更新則更可能涉及協定實作、DNS 行為、規則語法與網路堆疊。更新後若基本連線正常，通常不需要立即重寫設定。只有記錄出現欄位淘汰、解析失敗，或原有網路行為發生明確變化時，才需要查閱對應文件並調整相關段落。

長期使用時可以保留一份結構簡單的基礎設定：明確指定執行模式、連接埠、DNS、策略組與末尾規則，再透過規則集或覆寫擴充需求。設定越複雜，更新時越難判斷是哪一層產生衝突。先確保基礎鏈路可運作，再逐項增加自訂規則，是從舊核心遷移到新核心時成本較低的維護方式。

設定與排錯文章

近期 Clash 技術文章

從 DNS 運作機制、憑證錯誤到路由器部署，文章依具體問題拆解設定鏈路，方便在用戶端能連線但行為不符預期時繼續定位。

進階技巧

Clash Fake-IP 模式原理詳解：與 Redir-Host 的差異及適用情境

從 DNS 查詢進入核心開始，梳理虛假位址池如何保存網域對映、連線階段如何還原目標，以及瀏覽器、遊戲與區域網路服務分別適合哪些過濾策略。文章同時說明 Redir-Host 的解析路徑，協助判斷異常究竟來自位址對映還是上游解析。

閱讀全文 →
故障排查

開啟代理後 HTTPS 憑證報錯怎麼辦：常見原因與逐項排查

憑證錯誤可能來自系統時間、瀏覽器快取、節點鏈路、本地安全軟體或解密設定。文章依報錯出現的範圍逐層驗證：先判斷是否只有單一網站受影響，再對照直連結果、系統憑證狀態與代理記錄，避免把所有憑證問題都歸咎於節點。

閱讀全文 →
平台部署

路由器與旁路由直接執行 mihomo 核心部署概覽：架構選擇與基本步驟

比較主路由直接執行與旁路由接管兩種架構，說明二進位檔架構、設定目錄、透明代理、DNS 轉送與開機啟動之間的關係。內容著重部署前的架構判斷，協助確認哪些流量會經過核心，以及原路由是否仍負責 DHCP 與閘道功能。

閱讀全文 →
查看所有文章 →