ZERO TO PRO · 完整手冊

Clash 從零到精通:安裝設定與規則分流完整手冊

本站資訊量最大的一頁。九章按學習順序線性排列:先弄清代理用戶端在做什麼,再選用戶端、裝用戶端、匯入訂閱,然後逐層深入代理模式、規則分流與 TUN 全域接管,最後給出日常維護清單與進階路線。教學頁是十分鐘跑通的快速主線,本頁則是可以反覆查閱的系統手冊,兩者互補:走流程去教學頁,查細節回本頁。

9 章 · 階梯推進 5 平台涵蓋 MIHOMO 核心 YAML 範例可套用
S-01

核心概念:代理、規則與訂閱

把 Clash 類用戶端拆開看,本質只有三件事:在本機開一個監聽埠接收流量、按一套規則判斷每條連線該走哪條路、把決定走代理的連線轉發到遠端節點。後面章節出現的每一個設定項,都能歸到這三件事裡的某一件。本章不操作任何東西,只把概念講到後面用得上的程度。

代理用戶端在做什麼

用戶端啟動後,會在本機監聽一個或多個埠,最常見的是 HTTP 與 SOCKS5 合一的混合埠。作業系統或瀏覽器把網路請求發給這個埠,用戶端拿到請求後查規則表:命中直連規則的,從本機網卡直接發出;命中代理規則的,封裝後發給遠端代理伺服器,由伺服器代為存取目標。對系統裡其他程式來說,用戶端就是一個普通的本機代理;對目標網站來說,存取來源是遠端節點。

新手最容易搞混的一點:裝了用戶端不等於有了代理能力。用戶端本身不附帶任何節點,它是「調度器」;節點來自訂閱或手動新增,才是流量的「出口」。兩者缺一不可,第四章專門講節點怎麼進來。

核心:mihomo 是目前活躍主線

Clash 生態有兩條核心線。原版 Clash 核心早已停止更新並封存;社群主線是 Clash Meta,後續更名為 mihomo,本站下載中心提供的圖形用戶端全部基於 mihomo。mihomo 在原版基礎上擴充了更多代理協議、規則類型與 TUN 增強能力,設定語法保持向下相容,舊設定檔基本可以直接沿用。兩條核心線的詳細差異,部落格有專文《Clash 核心區別:原版 Clash、Clash Meta 與 mihomo》逐條梳理,這裡只記結論:新裝一律選 mihomo 系用戶端。

節點、規則、訂閱:三要素

節點(Proxy)是一台遠端代理伺服器加一組連線參數:位址、埠、協議、憑證。常見協議有 Shadowsocks、VMess、Trojan、Hysteria 等,用戶端負責按協議封裝流量,一般使用者不需要關心封裝細節。

規則(Rule)是分流判斷條件,形如「網域尾碼是某值就走直連」。規則表是一份有序清單,第六章展開說明。

策略群組(Proxy Group)是規則與節點之間的中間層:規則不直接指向某個節點,而是指向一個策略群組,群組內再決定用哪個節點——可以手動選,也可以自動測速選。第五章展開說明。

訂閱(Subscription)是一個定時回傳設定文字的 URL,文字內容裡打包了節點、策略群組與規則。有了訂閱,上述三樣東西一次到位,第四章展開說明。

一次請求的完整路徑

以瀏覽器存取一個網站為例:瀏覽器把請求交給系統代理設定指向的本機埠;用戶端接管連線,從上到下逐條比對規則表;規則命中「代理」策略群組,策略群組按自身策略選出一個節點;用戶端與節點建立加密連線,把請求轉發出去;回應沿原路返回。整個過程在本機完成,對瀏覽器完全透明。

與傳統 VPN 的差異

傳統 VPN 在系統層建立一條通道,所有流量無條件進通道;Clash 類用戶端按規則逐條分流,台灣本地直連與海外走代理可以共存。按規則分流是這類用戶端的核心價值,也是本手冊第六章用一整章展開的原因。

S-02

選擇用戶端:依平台對號入座

用戶端沒有絕對的好壞,只有平台與使用習慣的匹配。本章給出依平台對號入座的結論;逐個用戶端的橫向參數比較見用戶端比較頁,安裝包統一在下載中心按平台領取。

五大平台的選擇

Windows:首推 Clash Plus,介面與核心同步更新;備選 Clash Verge Rev(功能面板完整)、FlClash(跨平台一致體驗)、Clash Nyanpasu(介面風格獨特)。

macOS:首推 Clash Plus,Apple Silicon 與 Intel 雙架構分別提供安裝包;備選 Clash Verge Rev 與 FlClash,同樣區分晶片架構,裝錯架構能啟動但效能打折。

Android:首推 Clash Plus;備選 Clash Meta for Android(與核心同名的用戶端,更新頻繁)、FlClash、Surfboard(介面極簡)。

iOS:Clash Plus 已上架 App Store,直接搜尋安裝即可,官網 clashplus.io 有平台說明。iOS 上代理用戶端以系統層級設定形式運作,體驗與桌面端一致。

Linux:桌面環境用 Clash Verge Rev 或 FlClash,提供 deb 與 rpm 套件;伺服器、路由器等無介面場景直接部署 mihomo 核心,用設定檔加外部控制器管理,第九章展開說明。

平台首推備選封存(停止維護)
WindowsClash PlusClash Verge Rev / FlClash / Clash NyanpasuClash for Windows
macOSClash PlusClash Verge Rev / FlClashClashX Meta
AndroidClash PlusClash Meta for Android / FlClash / Surfboard
iOSClash Plus(App Store)
LinuxClash Verge RevFlClash / mihomo 核心

核心線:原版與 mihomo

原版 Clash 核心停更後,基於它的經典用戶端也隨之停止維護:Windows 平台的 Clash for Windows、macOS 平台的 ClashX Meta。下載頁保留這兩個用戶端僅供封存參考,卡片上會標註「已停止維護」。新裝使用者不需要糾結歷史:直接選 mihomo 系仍在維護的用戶端,協議支援最完整,規則類型最新。

從停止維護的用戶端遷移

如果機器上還在用 Clash for Windows 或 ClashX Meta,短期繼續使用沒有問題,但新協議與新規則類型不會再獲得支援,遇到節點連不上先懷疑這一點。遷移成本很低:記下現有訂閱連結,裝一個 mihomo 系用戶端,重新匯入訂閱即可;訂閱裡自帶的策略群組與規則會自動帶過來,不需要逐條手動抄寫。

選型結論

不想逐個比較就直接裝 Clash Plus,五大平台都有對應版本。想看逐項參數比較就去用戶端比較頁;想直接拿安裝包就去下載中心,每個平台的卡片上都標了系統需求。

S-03

安裝與首次啟動

本章按平台講安裝路徑與裝完之後的檢查項,下載連結不在此重複,統一去下載中心按平台領取。四大平台首次安裝的通用流程與新手常踩的坑,部落格另有《Clash 首次安裝與初始設定》一文可作對照。

Windows

下載 .exe 安裝包按向導安裝即可;多數用戶端同時提供免安裝版,解壓即用、不寫入登錄檔,適合放隨身碟或多機搬移。系統需求以下載頁各卡片標注為準,主流用戶端要求 Windows 10 及以上。首次啟動時若系統跳出防火牆提示,允許用戶端在專用網路通訊——即使僅本機使用也建議放行,避免後續排查網路問題時多一層干擾。

macOS

下載與晶片對應的 dmg:Apple Silicon 選 arm64 版,Intel 機型選 x64 版。把應用程式拖進「應用程式」資料夾後首次開啟,如果系統提示「無法驗證開發者」,到「系統設定 → 隱私權與安全性」裡點「仍要開啟」。選單列出現用戶端圖示即代表啟動成功。

Android 與 iOS

Android 從下載頁拿 apk 直接安裝,系統會要求允許「安裝不明來源應用程式」,裝完可以把這項授權關掉。首次連線時系統會跳出 VPN 連線請求,這是 Android 上代理用戶端的標準運作方式,必須允許,否則用戶端無法接管任何流量。iOS 在 App Store 安裝 Clash Plus,首次新增設定時同樣要允許系統跳出的 VPN 設定請求。

Linux

桌面發行版用 deb 或 rpm 套件裝 Clash Verge Rev 或 FlClash,裝完從應用程式選單啟動。伺服器與路由器場景不需要圖形介面:下載對應架構的 mihomo 核心執行檔,搭配 config.yaml,用 systemd 託管行程,再透過外部控制器管理,具體做法見第九章。

首次啟動四項檢查

裝完先別急著匯入訂閱,花兩分鐘確認四件事:

  • 介面語言:多數用戶端首次啟動可在設定裡切換中文介面。
  • 開機自動啟動:在設定裡打開,避免每次開機都要手動啟動。
  • 系統代理開關的位置:先找到它在哪裡——第四章匯入訂閱之後要開它,流量才真正進入用戶端。
  • 混合埠號:記下來(常見預設 7890),之後命令列工具臨時走代理、區域網路共享都會用到這個埠。

四項確認完,安裝階段結束,進入第四章匯入訂閱。

系統代理與瀏覽器代理外掛只留一個

瀏覽器裡如果還裝著 SwitchyOmega 之類的代理外掛,開啟系統代理後流量會被外掛再攔截一次,出現繞兩圈、規則不生效的怪現象。二選一:要麼系統代理接管全域、外掛停用;要麼只用外掛、用戶端不開系統代理。建議選前者,分流涵蓋範圍更完整。

S-04

訂閱匯入與更新

節點、策略群組、規則三樣東西,靠一個訂閱連結一次到位。本章講訂閱是什麼、怎麼匯入、怎麼更新,以及更新失敗時該按什麼順序排查。

訂閱連結是什麼

訂閱連結是一個回傳設定文字的 URL,文字內容就是節點清單、策略群組與規則表。用戶端會定時請求這個 URL 取得最新設定。訂閱連結由節點服務方提供,用戶端本身不附帶任何節點。連結裡通常帶有使用者憑證,地位等同帳號密碼:不要貼到公開場所,不要匯入來源不明的訂閱,換裝置時手動搬移而非轉發到群組聊天。

匯入訂閱的三種方式

URL 匯入(最常用):複製訂閱連結,打開用戶端的「設定/訂閱」頁,新增設定,貼上 URL,取個名字儲存。剪貼簿匯入:部分用戶端能辨識剪貼簿裡的訂閱連結,複製後打開用戶端會提示一鍵匯入。本機檔案匯入:手上已有 config.yaml 時,從設定頁選擇「匯入本機檔案」,或直接把檔案放進用戶端的設定目錄。

匯入只是讓設定出現在清單裡,還要把它設為「啟用/使用中」設定,用戶端才會真正按這份設定運作。多份訂閱可以並存,切換使用中設定即可切換整套節點與規則。

更新訂閱與自動更新

節點會增減、規則會修訂,訂閱需要定期更新。用戶端通常同時提供手動「更新」按鈕與自動更新間隔,建議開啟 24 小時自動更新,再養成「感覺節點不對就先手動更新一次」的習慣。更新失敗時用戶端會沿用舊設定繼續運作,不會立刻斷網;但長期更新失敗意味著節點清單停留在舊版本,失效節點會越積越多。

訂閱更新失敗:按四步排查

網路可達性:訂閱位址本身是否能存取。先關閉系統代理用直連試一次——部分訂閱位址在代理環境下反而會被擋。②連結有效性:連結是否過期、被重設或套餐到期,找服務方核對。③用戶端識別:部分服務方按用戶端 UA 分發不同格式,換用戶端或把用戶端更新到新版後再試。④系統時間:TLS 憑證驗證依賴系統時間,時間偏差過大會直接握手失敗,校準時間後再更新。

訂閱回傳的設定文字長這樣(片段):

proxies:
  - name: "節點-範例"
    type: ss
    server: example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: PROXY
    type: select
    proxies: ["節點-範例", "DIRECT"]

rules:
  - GEOSITE,cn,DIRECT
  - MATCH,PROXY

拿到一份設定能認出這三段,後面章節改設定就不慌了:proxies 是節點、proxy-groups 是策略群組、rules 是規則表。

訂閱轉換是什麼

訂閱轉換指把一種用戶端的訂閱格式線上轉成另一種格式的工具。同生態內遷移(舊用戶端換成 mihomo 系)一般不需要轉換;確有需要時要注意,轉換服務會經手完整節點資訊,涉及憑證安全,請自行評估風險。

S-05

代理模式:規則、全域與直連

三種代理模式決定「規則表用不用、怎麼用」。切換入口一般在用戶端首頁或系統匣選單,隨時可切、立即生效,不需要重新啟動用戶端。判斷目前處於哪個模式,看用戶端首頁或系統匣圖示的模式標示即可。

規則模式(Rule)

預設建議,日常常駐使用。每條連線按規則表從上到下逐條比對:命中代理就走節點,命中直連就走本機網卡。台灣本地網站直連保證速度,海外網站走代理保證可達,兩者互不干擾。訂閱自帶的規則表已涵蓋主流場景,大多數人長年不需要動它。

全域模式(Global)

所有連線無條件走代理策略群組選出的節點,規則表整體停用。適用場景有兩個:臨時驗證節點是否可用;存取某些必須全程使用同一出口的服務。長期開全域會把本地流量也繞到海外節點,速度變慢還容易觸發網站風控,用完記得切回規則模式。

直連模式(Direct)

所有連線不走任何節點,用戶端只接管不轉發。適用場景:對照測試——懷疑「是節點壞了還是用戶端壞了」時,切直連能存取就代表用戶端與規則沒問題,問題在節點;在完全可信的網路裡短暫停用代理時也可以用。

模式規則表流量走向典型場景
規則 Rule啟用按規則分流日常常駐
全域 Global停用全部走節點臨時驗證節點、統一出口
直連 Direct停用全部走本機對照測試、可信網路

策略群組:節點的分組容器

策略群組是規則與節點之間的中間層。規則不直接指向節點,而是指向策略群組;策略群組按自身類型決定最終使用哪個節點。常見四種類型:

  • select 手動選擇:群組內列出節點,由使用者手動點選切換,最常用,適合「主力節點+備用節點」的固定組合。
  • url-test 自動測速:定時對群組內節點發起測速請求,自動切到延遲最低的一個,適合節點多、不想手動維護的場景。
  • fallback 故障轉移:按清單順序使用第一個可用節點,掛掉自動切下一個,適合追求穩定而非追求最快的場景。
  • load-balance 負載平衡:把連線分攤到群組內多個節點,適合大流量下載類場景。

策略群組在設定裡長這樣:

proxy-groups:
  - name: PROXY
    type: select
    proxies: ["自動選擇", "節點-範例", "DIRECT"]
  - name: 自動選擇
    type: url-test
    proxies: ["節點-範例"]
    url: http://example.com/generate_204
    interval: 300

訂閱自帶的策略群組通常已經夠用:一個手動選擇群組管日常,一個自動測速群組管兜底。想按地區、按用途自訂分組,屬於第九章手寫設定的內容。

測速數字只代表當下

url-test 顯示的延遲是到測速位址的握手延遲,不等於實際瀏覽體驗,更不代表頻寬。別為了幾毫秒的差距頻繁切換節點;真正影響體驗的是節點穩定性,而穩定性要靠幾天以上的觀察才能判斷。

S-06

規則分流:類型、順序與實戰

規則分流是 Clash 類用戶端的核心能力,也是它區別於「全部進通道」式工具的核心價值。本章把規則類型講全、把比對順序講透,再給一套本地與海外分流的實戰設定與驗證方法;更細的規則寫法案例,部落格有《Clash 規則分流設定實戰》一文可作補充。

規則類型清單

mihomo 支援的規則類型很多,日常高頻使用的就這幾類:

  • DOMAIN:精確比對單一網域,如 DOMAIN,example.com,PROXY,只命中這個網域本身。
  • DOMAIN-SUFFIX:比對網域尾碼,如 DOMAIN-SUFFIX,example.com,PROXY,命中該網域及其所有子網域,是最常用的網域規則。
  • DOMAIN-KEYWORD:網域包含某關鍵字即命中,如 DOMAIN-KEYWORD,example,PROXY,涵蓋範圍大、誤判範圍也大,請謹慎使用。
  • GEOSITE:按網域分類庫比對,如 GEOSITE,cn,DIRECT 命中分類庫裡的中國大陸網域合集,一條規則可頂上數萬條手寫規則。
  • IP-CIDR:按目標 IP 位址段比對,如 IP-CIDR,192.168.0.0/16,DIRECT 讓區域網路位址全部直連。帶 no-resolve 參數的規則不會觸發 DNS 解析,只有純 IP 連線才會命中。
  • GEOIP:按 IP 歸屬地比對,如 GEOIP,CN,DIRECT,網域會先解析成 IP 再查歸屬地庫。
  • PROCESS-NAME:按發起連線的行程名稱比對,桌面端可用,如讓某個下載工具固定走代理。
  • DST-PORT / SRC-IP-CIDR:按目標埠、來源 IP 位址段比對,常用於區域網路共享與閘道場景。
  • MATCH:兜底規則,比對所有連線,必須是規則表的最後一條。

比對順序:從上到下,首條命中即停止

規則表是一份有序清單:每條新連線從第一條開始向下比對,命中哪條就按哪條執行,後面的規則不再看。這個機制引出兩條鐵律:①越具體、越特殊的規則放越前面,越寬泛的放越後面;②MATCH 兜底規則永遠放在最後,一旦排前面,後面的規則就全部失效。排查「某網站走的路線不對」時,第一反應應該是查順序——是不是有一條更寬鬆的規則排在前面把它截走了。

規則引用的目標可以是策略群組,也可以是保留字:DIRECT 直連、REJECT 拒絕連線(常用於封鎖廣告與追蹤網域)、策略群組名則交由該群組決定出口。

GEOSITE 與 GEOIP 資料檔

GEOSITE 與 GEOIP 規則依賴兩個分類資料檔(geosite.dat 與 geoip 系列資料),它們隨用戶端分發,也持續由社群更新。資料檔過時會導致新網域分類不準,表現為「該直連的卻走了代理」或反之。主流用戶端在設定裡提供資料檔更新入口,建議與訂閱更新一起列入每月維護,詳見第八章。

實戰:本地與海外分流設定

一套典型的本地與海外分流規則表(節選,順序即比對順序):

rules:
  # 區域網路與保留位址直連
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  # 本地網域與 IP 直連
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  # 其餘全部交給代理策略群組
  - MATCH,PROXY

在這個骨架上做加減:某個海外站點想強制走代理,在 GEOSITE 行前加一條 DOMAIN-SUFFIX,目標網域,PROXY;某類廣告網域想直接封鎖,加 GEOSITE,category-ads-all,REJECT 並放在最前面。訂閱自帶規則表時,優先在用戶端的「覆寫/自訂規則」入口追加,而不是直接改訂閱檔——訂閱一更新,手動改的內容就會消失。

驗證分流結果

改完規則必須驗證。打開用戶端的「連線」面板,存取目標網站,看新產生的連線項目:面板會顯示這條連線命中的規則、最終走的策略群組與節點。命中與預期不符,就按連線面板顯示的規則名稱回去調整順序。用戶端日誌開到 debug 等級時,也會逐條印出規則判定過程,適合更細緻的排查。

網域規則依賴正確的 DNS 解析

GEOIP 規則需要先把網域解析成 IP 才能查歸屬地。如果 DNS 設定不當或遭污染,解析結果錯誤,GEOIP 判定就會跟著出錯。DNS 模組的設定思路見第九章進階路線,部落格《Clash DNS 詳解》有完整說明。

S-07

TUN 模式:系統層級全域接管

系統代理有一個天然盲區:它只對「遵循系統代理設定」的應用程式生效。瀏覽器、多數桌面軟體會讀取系統代理;但命令列工具、部分遊戲、一些自行管理網路堆疊的應用程式,以及幾乎所有 UDP 流量,都會繞過它直連。TUN 模式解決的就是這個盲區。

TUN 是什麼

TUN 模式在系統裡建立一張虛擬網卡,並修改路由表,讓全系統的 TCP/UDP 流量都先經過這張虛擬網卡進入用戶端,再由用戶端按規則分流。接管發生在網路層,不依賴應用程式是否配合,因此命令列、遊戲、系統服務、UDP 應用程式全部納入分流範圍。Android 上用戶端原本就以 VPN 服務方式運作,效果與 TUN 等價;TUN 主要是桌面端(Windows/macOS/Linux)的增強開關。

與系統代理的分工

兩者不衝突,可以疊加使用:系統代理管「聽話的應用程式」,TUN 管「不聽話的」。多數用戶端開啟 TUN 時會自動處理好與系統代理的關係,不需要手動二選一。以瀏覽為主、偶爾用命令列的使用者,只開系統代理就足夠;經常跑命令列工具、玩海外服遊戲、需要 UDP 轉發的使用者,建議常駐開啟 TUN。

開啟條件

TUN 要動系統網路堆疊,權限要求比一般代理高。Windows 上主流用戶端以「服務模式」實現:在用戶端設定裡按提示安裝服務,之後 TUN 開關即可正常使用,不需要每次以系統管理員身分啟動用戶端本體。macOS 首次開啟會要求輸入系統密碼以授權安裝輔助程式。Linux 桌面端同樣需要授權;伺服器上用核心直接開啟 TUN 時,行程需要對應的網路權限。

設定範例

圖形用戶端裡 TUN 通常只是一個開關,底層對應設定裡的 tun 段落,手寫設定時長這樣:

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

幾個關鍵欄位:stack 是虛擬網卡的協議堆疊實作,mixed 是兼顧相容性與效能的常用值;auto-route 讓用戶端自動設定路由表;auto-detect-interface 自動辨識出口網卡,避免流量繞圈;dns-hijack 把系統裡所有發往 53 埠的 DNS 查詢劫持進用戶端的 DNS 模組,配合第九章的 DNS 設定使用。

注意事項

與其他 VPN/加速器衝突:系統裡同時存在兩個改動路由表的虛擬網卡,流量走向會變得不可預期,同一時間只保留一個。②防火牆攔截:部分安全軟體會攔截虛擬網卡驅動,開啟 TUN 後斷網先查這一項。③關閉要乾淨:異常退出可能殘留路由表項目導致斷網,重新開關一次用戶端的 TUN 或重新開機即可恢復。④不是所有場景都需要:只是瀏覽網頁就不開 TUN,少一層接管少一類故障。

開啟 TUN 後斷網的排查順序

先關閉 TUN 確認系統代理模式下正常,再逐項查:服務模式是否安裝好、是否有其他 VPN 佔用路由、防火牆是否放行虛擬網卡、設定裡 auto-route 是否開啟。九成問題出在前兩項。

S-08

日常維護:更新、備份與故障自查

用戶端裝好之後,真正花時間的不是設定而是維護:訂閱會更新、資料檔會過時、節點會失效、用戶端本身也在持續迭代。本章給出一份可照做的維護清單,外加常見故障的自查路徑。FAQ 頁收錄了更零碎的問答,本章只講成體系的維護動作。

維護清單

訂閱更新:保持 24 小時自動更新開啟;節點大面積連不上時,第一件事就是手動更新一次訂閱,排除「用戶端拿著過期節點清單」這個最常見的原因。

GEOSITE / GEOIP 資料更新:每月一次,入口在用戶端設定裡。資料檔決定網域與 IP 的分類準確度,長期不更新,分流結果會漸漸偏離現實。

用戶端更新:用戶端內建更新提示,跟著更新即可。核心更新常帶協議與安全性修復,不建議長期停留在舊版本。更新前不需要卸載舊版,設定會保留。

設定備份:把訂閱連結單獨記在密碼管理器或加密筆記裡;手寫設定(自訂規則、覆寫)另外匯出一份副本。換機、重裝時,有訂閱連結加一份覆寫備份就能完整還原。

節點失效的處理

單個節點連不上,先在策略群組裡手動切到備用節點,別急著改設定。整組節點逾時,按順序查:手動更新訂閱 → 切全域模式驗證是否規則誤判 → 切直連模式確認本機網路正常 → 換網路環境(手機熱點)排除寬頻出口問題。四步走完仍不通,再找節點服務方處理。

日誌與連線面板

用戶端有兩個排查利器。連線面板:即時列出每條連線的行程、目標、命中規則、出口節點與流量計數,「某網站為什麼沒走代理」在這裡一眼就能定位。日誌:預設 info 等級記錄關鍵事件;排查疑難時調到 debug,能看到規則逐條判定與 DNS 解析細節,查完記得調回 info——debug 日誌量大且會記錄存取目標,不適合常開。

常見故障自查表

現象先查再查
用戶端開著但完全沒有網路系統代理是否誤開、TUN 路由是否殘留防火牆與安全軟體攔截
部分網站打不開連線面板看命中規則規則順序、GEOSITE 資料是否過時
所有網站都很慢是否掛著全域模式繞路節點負載,換節點對照
訂閱更新失敗直連環境重試、連結是否失效用戶端 UA、系統時間
本地網站走了代理GEOSITE/GEOIP 資料版本DNS 解析結果是否被污染

自查表覆蓋不了的問題,去FAQ 頁按分類翻找;部落格的故障排除標籤下也有依症狀整理的專文,例如《Clash DNS 洩漏檢測》

維護的核心原則

先更新、再切換、最後才改設定。絕大多數「故障」靠更新訂閱與切換節點就能解決,真正需要動設定的情況很少。設定改動越少,出問題時越容易定位。

S-09

進階路線:從覆寫到獨立部署

前八章走完,日常使用已經沒有障礙。本章給想繼續深入的使用者一張路線圖,按投入程度由淺到深排列,每一站都有明確的目標與對應的站內資料。

第一站:覆寫訂閱設定

訂閱自帶的設定由服務方維護,直接改動會在下次更新時被覆蓋。正確做法是用用戶端的「覆寫/Mixin」功能:定義一份自己的補充片段——追加規則、調整策略群組、修改埠——用戶端在每次訂閱更新後會自動把片段合併進去。這是從「用訂閱」到「管設定」的第一步,投入小、收益立竿見影。

第二站:規則提供者 rule-providers

規則多了之後,全堆在 rules 清單裡難以維護。mihomo 支援 rule-providers:把一類規則(比如某個應用程式的全部網域)做成獨立的外部規則集檔案或線上位址,設定裡按名稱引用,規則集可以獨立更新。配合策略群組,能搭出「一個應用程式一個規則集一個出口」的清晰結構。

第三站:DNS 模組

DNS 是分流準確性的地基。用戶端內建 DNS 模組接管網域解析:nameserver 指定常規解析伺服器,fallback 指定海外網域的備用解析通道,enhanced-mode 控制增強解析行為。設定得當可以消除 DNS 污染對 GEOIP 判定的干擾,並防止解析請求洩漏到代理通道之外。這一站內容較多,直接讀部落格兩篇專文:《Clash DNS 詳解》講參數,《Clash DNS 洩漏檢測》講驗證與修復。

第四站:區域網路共享與閘道

開啟設定的 allow-lan: true 後,區域網路內其他裝置(手機、平板、電視)可以把代理指向這台機器的 IP 與混合埠,共享同一個用戶端。再進一步,把用戶端部署在軟體路由器或常開裝置上,配合 TUN 接管整個網段,就是家庭閘道方案——所有連網裝置免設定即可分流。

第五站:伺服器與路由器部署 mihomo

無圖形介面場景直接用核心:下載對應架構的 mihomo 執行檔,準備一份完整 config.yaml,用 systemd 託管行程實現開機自動啟動與崩潰重啟;開啟 external-controller 後,可以透過 API 或網頁儀表板遠端管理——切節點、看連線、查日誌都不需要登入伺服器。範例單元檔:

[Unit]
Description=mihomo proxy core
After=network.target

[Service]
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure

[Install]
WantedBy=multi-user.target

設定目錄 /etc/mihomo 裡放 config.yaml 與 GEOSITE/GEOIP 資料檔。改完設定用 systemctl restart mihomo 生效,用 journalctl -u mihomo 查日誌。

持續學習路徑

進階內容的更新入口在站內三處:FAQ 頁按「基礎認知 / 安裝設定 / 使用技巧 / 故障排除」分類收錄高頻問答;部落格持續更新核心、設定、DNS、排查四類專文;教學頁適合帶新同事、新裝置時快速過一遍主線。遇到本手冊沒涵蓋的場景,先查 FAQ 的分類導覽,再翻部落格標籤。

進階的節奏建議

五站按順序走,每站穩了再進下一站。覆寫和 rule-providers 解決的是「設定可維護」,DNS 解決的是「分流準確」,共享與獨立部署解決的是「多裝置涵蓋」——它們對應三類真實需求,不是為了進階而進階。