核心概念:代理、規則與訂閱
把 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 類用戶端按規則逐條分流,台灣本地直連與海外走代理可以共存。按規則分流是這類用戶端的核心價值,也是本手冊第六章用一整章展開的原因。
選擇用戶端:依平台對號入座
用戶端沒有絕對的好壞,只有平台與使用習慣的匹配。本章給出依平台對號入座的結論;逐個用戶端的橫向參數比較見用戶端比較頁,安裝包統一在下載中心按平台領取。
五大平台的選擇
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 核心,用設定檔加外部控制器管理,第九章展開說明。
| 平台 | 首推 | 備選 | 封存(停止維護) |
|---|---|---|---|
| Windows | Clash Plus | Clash Verge Rev / FlClash / Clash Nyanpasu | Clash for Windows |
| macOS | Clash Plus | Clash Verge Rev / FlClash | ClashX Meta |
| Android | Clash Plus | Clash Meta for Android / FlClash / Surfboard | — |
| iOS | Clash Plus(App Store) | — | — |
| Linux | Clash Verge Rev | FlClash / mihomo 核心 | — |
核心線:原版與 mihomo
原版 Clash 核心停更後,基於它的經典用戶端也隨之停止維護:Windows 平台的 Clash for Windows、macOS 平台的 ClashX Meta。下載頁保留這兩個用戶端僅供封存參考,卡片上會標註「已停止維護」。新裝使用者不需要糾結歷史:直接選 mihomo 系仍在維護的用戶端,協議支援最完整,規則類型最新。
從停止維護的用戶端遷移
如果機器上還在用 Clash for Windows 或 ClashX Meta,短期繼續使用沒有問題,但新協議與新規則類型不會再獲得支援,遇到節點連不上先懷疑這一點。遷移成本很低:記下現有訂閱連結,裝一個 mihomo 系用戶端,重新匯入訂閱即可;訂閱裡自帶的策略群組與規則會自動帶過來,不需要逐條手動抄寫。
選型結論
不想逐個比較就直接裝 Clash Plus,五大平台都有對應版本。想看逐項參數比較就去用戶端比較頁;想直接拿安裝包就去下載中心,每個平台的卡片上都標了系統需求。
安裝與首次啟動
本章按平台講安裝路徑與裝完之後的檢查項,下載連結不在此重複,統一去下載中心按平台領取。四大平台首次安裝的通用流程與新手常踩的坑,部落格另有《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 之類的代理外掛,開啟系統代理後流量會被外掛再攔截一次,出現繞兩圈、規則不生效的怪現象。二選一:要麼系統代理接管全域、外掛停用;要麼只用外掛、用戶端不開系統代理。建議選前者,分流涵蓋範圍更完整。
訂閱匯入與更新
節點、策略群組、規則三樣東西,靠一個訂閱連結一次到位。本章講訂閱是什麼、怎麼匯入、怎麼更新,以及更新失敗時該按什麼順序排查。
訂閱連結是什麼
訂閱連結是一個回傳設定文字的 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 系)一般不需要轉換;確有需要時要注意,轉換服務會經手完整節點資訊,涉及憑證安全,請自行評估風險。
代理模式:規則、全域與直連
三種代理模式決定「規則表用不用、怎麼用」。切換入口一般在用戶端首頁或系統匣選單,隨時可切、立即生效,不需要重新啟動用戶端。判斷目前處於哪個模式,看用戶端首頁或系統匣圖示的模式標示即可。
規則模式(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 顯示的延遲是到測速位址的握手延遲,不等於實際瀏覽體驗,更不代表頻寬。別為了幾毫秒的差距頻繁切換節點;真正影響體驗的是節點穩定性,而穩定性要靠幾天以上的觀察才能判斷。
規則分流:類型、順序與實戰
規則分流是 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 詳解》有完整說明。
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 是否開啟。九成問題出在前兩項。
日常維護:更新、備份與故障自查
用戶端裝好之後,真正花時間的不是設定而是維護:訂閱會更新、資料檔會過時、節點會失效、用戶端本身也在持續迭代。本章給出一份可照做的維護清單,外加常見故障的自查路徑。FAQ 頁收錄了更零碎的問答,本章只講成體系的維護動作。
維護清單
訂閱更新:保持 24 小時自動更新開啟;節點大面積連不上時,第一件事就是手動更新一次訂閱,排除「用戶端拿著過期節點清單」這個最常見的原因。
GEOSITE / GEOIP 資料更新:每月一次,入口在用戶端設定裡。資料檔決定網域與 IP 的分類準確度,長期不更新,分流結果會漸漸偏離現實。
用戶端更新:用戶端內建更新提示,跟著更新即可。核心更新常帶協議與安全性修復,不建議長期停留在舊版本。更新前不需要卸載舊版,設定會保留。
設定備份:把訂閱連結單獨記在密碼管理器或加密筆記裡;手寫設定(自訂規則、覆寫)另外匯出一份副本。換機、重裝時,有訂閱連結加一份覆寫備份就能完整還原。
節點失效的處理
單個節點連不上,先在策略群組裡手動切到備用節點,別急著改設定。整組節點逾時,按順序查:手動更新訂閱 → 切全域模式驗證是否規則誤判 → 切直連模式確認本機網路正常 → 換網路環境(手機熱點)排除寬頻出口問題。四步走完仍不通,再找節點服務方處理。
日誌與連線面板
用戶端有兩個排查利器。連線面板:即時列出每條連線的行程、目標、命中規則、出口節點與流量計數,「某網站為什麼沒走代理」在這裡一眼就能定位。日誌:預設 info 等級記錄關鍵事件;排查疑難時調到 debug,能看到規則逐條判定與 DNS 解析細節,查完記得調回 info——debug 日誌量大且會記錄存取目標,不適合常開。
常見故障自查表
| 現象 | 先查 | 再查 |
|---|---|---|
| 用戶端開著但完全沒有網路 | 系統代理是否誤開、TUN 路由是否殘留 | 防火牆與安全軟體攔截 |
| 部分網站打不開 | 連線面板看命中規則 | 規則順序、GEOSITE 資料是否過時 |
| 所有網站都很慢 | 是否掛著全域模式繞路 | 節點負載,換節點對照 |
| 訂閱更新失敗 | 直連環境重試、連結是否失效 | 用戶端 UA、系統時間 |
| 本地網站走了代理 | GEOSITE/GEOIP 資料版本 | DNS 解析結果是否被污染 |
自查表覆蓋不了的問題,去FAQ 頁按分類翻找;部落格的故障排除標籤下也有依症狀整理的專文,例如《Clash DNS 洩漏檢測》。
維護的核心原則
先更新、再切換、最後才改設定。絕大多數「故障」靠更新訂閱與切換節點就能解決,真正需要動設定的情況很少。設定改動越少,出問題時越容易定位。
進階路線:從覆寫到獨立部署
前八章走完,日常使用已經沒有障礙。本章給想繼續深入的使用者一張路線圖,按投入程度由淺到深排列,每一站都有明確的目標與對應的站內資料。
第一站:覆寫訂閱設定
訂閱自帶的設定由服務方維護,直接改動會在下次更新時被覆蓋。正確做法是用用戶端的「覆寫/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 解決的是「分流準確」,共享與獨立部署解決的是「多裝置涵蓋」——它們對應三類真實需求,不是為了進階而進階。