Clash 從零到精通完整手冊

Clash 是一款規則驅動的網路代理工具。它的運作方式可以濃縮成一句話:讀取一份 YAML 格式的設定檔,依設定裡定義的規則,決定每一條網路連線是直接發出、還是交由某個代理節點轉送。理解這句話,後面所有章節都是它的展開。

核心與用戶端

「Clash」這個詞在日常語境裡其實指兩層東西。第一層是核心:一個沒有圖形介面的命令列程式,負責真正的流量處理、規則比對與協定實作。原始 Clash 核心已經封存,目前社群持續維護的接班者是 mihomo 核心。第二層是用戶端:包在核心外面的圖形介面,負責訂閱管理、開關切換、日誌顯示這些人機互動工作。Clash Plus、Clash Verge Rev、FlClash 這些名字都屬於用戶端層,它們內部驅動的是同一類核心。這也解釋了一個常見疑問:為什麼不同用戶端能共用同一份訂閱——因為設定檔是寫給核心的,用戶端只是搬運工。專案系譜的完整梳理見這篇筆記。

四個繞不開的名詞

• 節點(proxy):一台可用的代理伺服器,設定裡的一條 proxies 記錄,包含伺服器位址、連接埠、協定與金鑰。
• 訂閱(subscription):服務商託管的一個 URL,存取它會回傳完整設定或節點列表。用戶端定期拉取,節點變更自動同步,不需要手動改檔案。
• 策略組(proxy-group):把多個節點打包成一個可選單元,例如「手動選擇組」「自動測速組」。規則的出口指向策略組,而不是直接指向某個節點。
• 規則(rule):一行「比對條件 + 出口」的宣告,例如「github.com 結尾的域名走代理組」。規則列表自上而下比對,命中即停。

一條連線的完整旅程

瀏覽器發起存取,連線先進入 Clash 監聽的本機連接埠。核心取出目標域名或 IP,從規則列表第一條開始逐條比對,命中某條後,把連線交給該規則指定的策略組;策略組再依自身類型(手動選擇或自動測速)確定最終節點;資料經節點轉送到目標。整個過程發生在本機,毫秒級完成。之後講的每一個功能——模式切換、規則撰寫、TUN——都只是改變這段旅程裡某一段的行為。

用戶端選錯不會造成損失,但會浪費時間。選型只需要回答三個問題:用什麼系統;是否需要 TUN 模式接管全域流量;專案是否仍在維護。第三個問題最容易被忽略——已停止維護的用戶端不會跟進核心更新,新協定、新規則類型都用不上,系統升級後還可能出現相容性問題。

平台速查表

幾點選型經驗

Clash Plus 涵蓋全部五個平台,介面統一、訂閱管理完整,是省心的預設答案;多裝置用戶尤其受益於操作邏輯一致。Clash Verge Rev 基於 mihomo 核心,設定能力最深,適合願意接觸 YAML 的用戶,也是 Linux 桌面的首選。FlClash 走輕量路線,資源佔用低,舊機器與背景常駐情境表現好。Clash Nyanpasu 僅支援 Windows,介面風格獨特,功能與 Verge Rev 接近。Surfboard 是 Android 上的輕量用戶端,只做基本代理,不追求進階功能。

四個維度(系統佔用、TUN 支援、訂閱管理、易用度)的逐項評分對照,見橫向評測頁,那裡有更詳細的結論;部落格裡的選型對照筆記補充了具體使用情境。確定選擇後直接前往下載頁,各平台安裝包依同樣的順序排列。

安裝本身不複雜,但每個平台都有一道系統級關卡:桌面系統的安全提示、行動系統的 VPN 授權。提前知道會出現什麼提示、該點哪個按鈕,就不會在第一步卡住。

Windows

從下載頁取得安裝程式,雙擊執行。首次執行時 SmartScreen 可能跳出「Windows 已保護您的電腦」——這是對未簽署或下載量低的程式的通用提示,不是病毒警告。點擊「其他資訊」,再點「仍要執行」即可繼續。安裝路徑建議保持預設;之後若要使用 TUN 模式,首次啟動時依用戶端提示安裝系統服務,授權一次後續不再詢問。

macOS

下載 .dmg 映像檔,開啟後把應用程式圖示拖入 Applications 資料夾。首次開啟時 Gatekeeper 會提示應用程式來自網路下載,選擇「打開」確認。注意晶片架構:Apple Silicon 機型(M 系列)下載 arm 版,Intel 機型下載 x64 版,裝錯架構會經轉譯層執行,效能明顯下降。開啟增強模式或 TUN 時,系統會要求輸入密碼安裝輔助工具,屬於正常授權流程。

Android

安裝 APK 時系統可能提示「不允許安裝未知來源應用程式」,在設定裡為瀏覽器或檔案管理器暫時開啟該權限即可。首次點擊連線,系統跳出「XX 想要設定 VPN 連線」對話框——Android 用戶端透過系統 VPN 介面接管流量,必須同意才能運作,這一步只會出現一次。部分廠商系統會積極清理背景程式,建議在電池最佳化設定裡將用戶端加入白名單,否則鎖螢幕後連線可能被中斷。

iOS

iOS 的發布渠道是 App Store,搜尋 Clash Plus 或透過官網 clashplus.io 提供的入口取得。安裝後首次啟動,同樣會請求新增 VPN 設定的權限,在系統彈出視窗中確認並驗證一次 Face ID 或密碼即可。iOS 的代理在系統網路層生效,所有應用程式統一走用戶端的規則,不需要逐個應用程式設定。首次設定的逐步截圖版流程,見部落格iPhone 首次設定筆記。

Linux

桌面發行版推薦 .deb 包,Debian/Ubuntu 系直接安裝:

sudo apt install ./clash-verge.deb
# 如提示相依套件缺失:
sudo apt --fix-broken install

Fedora 系使用 .rpm 包配合 dnf install。沒有圖形介面的伺服器可直接下載 mihomo 核心二進位檔,解壓縮後配合 systemd 常駐執行,核心下載入口同樣在下載頁核心區。

用戶端裝好之後是空的——沒有節點,連不上任何地方。節點資料透過訂閱進入用戶端,這是整條鏈路裡唯一需要外部提供的東西。

訂閱的本質

訂閱是服務商託管的一個 URL。用戶端存取它,取得一份完整的 Clash 設定(或節點列表),裡面已經寫好 proxies、proxy-groups 和 rules 三大段。之後用戶端依設定的間隔重新拉取,服務商更換伺服器、增刪節點,本機自動同步。匯入方式所有用戶端一致:複製訂閱連結,在訂閱或設定頁面貼上,確認下載。具體到每個平台點哪裡,教學頁有分步說明,此處不重複。

看懂設定檔的骨架

訂閱下載下來就是一份 YAML 文字檔。不需要會寫,但看懂骨架對排查問題極有幫助。一份最小設定的全域段長這樣:

mixed-port: 7890          # HTTP 與 SOCKS 共用的本機監聽連接埠
allow-lan: false          # 是否允許區域網路內其他裝置連入
mode: rule                # 啟動時的代理模式
log-level: info           # 日誌等級,排查時可暫時調為 debug
external-controller: 127.0.0.1:9090   # 本機控制介面

下面依序是 proxies(節點列表)、proxy-groups(策略組)、rules(規則列表)。三段的關係:規則指向策略組,策略組指向節點。任何一段名稱對不上,設定就會載入失敗,用戶端日誌會給出具體行號。

訂閱轉換是什麼

如果服務商只提供其他格式的節點資訊(例如通用分享連結),需要經過「訂閱轉換」服務把它轉譯成 Clash 設定格式。轉換過程會經手第三方伺服器,訂閱內容對其可見,存在外流風險。能拿到原生 Clash 訂閱就優先用原生;必須轉換時,選擇可信的自建或開源轉換服務。

多台裝置共用一份訂閱時,建議「訂閱連結集中管理」而不是互相拷貝設定檔,三種同步方案的取捨見多裝置同步筆記。

模式決定「規則列表是否參與決策」。三種模式是互斥的全域開關,用戶端主介面一鍵切換,對應設定裡的 mode 欄位。

常見誤用是長期停在 GLOBAL。全域模式下台灣本地網站的流量也會繞道海外節點,速度反而變慢,還白白耗用流量配額。正確做法:99% 的時間停在 RULE,GLOBAL 與 DIRECT 只作為排查工具短暫使用——「切到 GLOBAL 能存取、切回 RULE 不能」,說明問題出在規則;「切到 DIRECT 也不能存取」,說明問題與代理無關。

系統代理與模式的差異

另一個容易混淆的開關是「系統代理」。它不屬於三種模式,而是決定「作業系統是否把流量送進 Clash」:開啟後,系統級代理設定指向 Clash 的本機連接埠,遵循該設定的應用程式(瀏覽器等)流量才會進來;不遵循系統代理的應用程式(部分遊戲、命令列程式)則完全繞過。想讓所有程式無差別進入 Clash,需要第七章的 TUN 模式。層級關係記住一句話:系統代理/TUN 決定流量進不進來,模式決定進來之後怎麼走。

規則分流是 Clash 有別於單純代理工具的核心能力,也是 RULE 模式背後的全部邏輯。訂閱自帶的規則集能涵蓋大部分需求,但早晚會遇到「某個網站分流不對」的時刻——這時候需要看懂規則,必要時自己補一條。

規則的語法

每條規則是一行以逗號分隔的宣告:類型,比對值,出口。出口可以是策略組名稱,也可以是內建的 DIRECT(直連)與 REJECT(攔截)。常用類型如下:

順序決定一切

規則列表自上而下比對,第一條命中的規則立即生效,後面的全部忽略。因此排列有固定章法:精確的放前面,寬泛的放後面,保底的放最後。一個最小可用的境內外分流規則集:

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-SUFFIX,openai.com,PROXY
  - DOMAIN-KEYWORD,google,PROXY
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

讀法:命中已知海外域名走代理;.cn 尾碼直連;解析出的 IP 歸屬中國大陸直連;以上都沒命中,保底走代理。注意 GEOIP 需要先做 DNS 解析才能拿到 IP,把域名規則放在它前面,能讓大多數連線在解析前就完成分流;IP-CIDR 規則加上 no-resolve 參數可以避免為純域名連線觸發不必要的解析。

策略組:規則的出口

上例中的 PROXY 是策略組名稱。常見組類型:select 手動選擇,url-test 定期測速自動選最快,fallback 首選節點故障時自動切換備用。一個典型組合:

proxy-groups:
  - name: PROXY
    type: select
    proxies: [AUTO, 香港節點, 日本節點]
  - name: AUTO
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies: [香港節點, 日本節點]

手動組裡嵌一個自動測速組,平時選 AUTO 省心,特殊需求時手動鎖定某個節點。

規則不生效的排查路徑

1. 確認目前是 RULE 模式——GLOBAL 與 DIRECT 下規則完全不參與。
2. 打開用戶端的連線面板,找到目標連線,看它實際命中了哪條規則。絕大多數「分流不對」是被列表更靠前的寬泛規則截走。
3. 檢查自訂規則是否寫在了訂閱規則之後——追加在 MATCH 後面的規則永遠輪不到。
4. 域名規則不生效但 IP 規則生效,通常是 DNS 層的干擾,結合第七章的 fake-ip 排查。

附真實案例的完整實戰,見部落格規則分流實戰筆記。

第五章留了一個缺口:系統代理只對「遵循系統代理設定」的應用程式有效。命令列工具、部分遊戲用戶端、某些聊天軟體會自行建立連線,完全繞過代理。TUN 模式就是補上這個缺口的方案。

原理

開啟 TUN 後,用戶端會在系統裡建立一塊虛擬網路卡,並把它設為預設路由。所有應用程式的網路流量——不論是否理會代理設定——都會先經過這塊網路卡進入 Clash 核心,再依規則分流。效果上等同於行動端的 VPN 接管:應用程式無感知,分流對全系統生效。代價是需要更高的系統權限:Windows 上要以服務方式執行或授予系統管理員權限,macOS 上要授權系統延伸功能,Linux 上需要相應的網路管理權限。各用戶端首次開啟時都會引導完成授權,授權一次即長期有效。

設定範例

tun:
  enable: true
  stack: system
  auto-route: true              # 自動設定路由表
  auto-detect-interface: true   # 自動偵測實體出口網路卡

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://223.5.5.5/dns-query
    - https://120.53.53.53/dns-query

圖形用戶端裡這些項目通常是現成的開關,不必手寫;貼出來是為了讓你知道開關背後改的是什麼。stack 是協定堆疊實作,不同實作相容性略有差異,遇到特定應用程式異常時可以換一種再試。

為什麼 TUN 總是和 fake-ip 一起出現

TUN 接管流量後,DNS 解析也必須由 Clash 統一處理,否則會出現「解析在外、流量在內」的錯位,域名規則失效。fake-ip 模式下,核心對每次域名解析回傳一個保留網段的虛擬 IP,應用程式拿虛擬 IP 發起連線,核心憑對照表還原出原始域名再做規則比對——既跳過了真實解析的等待,又保證域名規則始終可靠。副作用是個別對 IP 敏感的程式(區域網路探索、部分登入驗證)可能不適應,此時把相關域名加入 fake-ip 過濾清單即可。

設定跑通只是開始。代理是長期使用的基礎設施,值得花十分鐘建立一套低成本的維護習慣,避免「某天突然全斷」時手忙腳亂。

訂閱更新策略

在用戶端裡為訂閱設定自動更新間隔,24 小時一次是合理預設;服務商公告更換伺服器時,手動觸發一次立即更新。更新失敗不會清空現有節點,用戶端會繼續使用上一份快取,所以偶發的更新失敗不必緊張,連續多天失敗才需要檢查訂閱位址是否已被服務商重設。

日誌:排查的第一現場

所有用戶端都提供日誌面板。日常保持 info 等級即可;排查問題時暫時調到 debug,可以看到每條連線的規則命中、DNS 解析與出口選擇。看日誌的基本做法:重現問題,立刻看最新幾行,關鍵字通常是 error、timeout、refused。定位後記得調回 info,debug 日誌量大,長期開啟浪費磁碟空間。

備份與多裝置一致性

需要備份的東西其實很少:訂閱連結本身、自訂規則片段、用戶端裡改過的設定項目。訂閱連結存進密碼管理器;自訂規則單獨存一份文字檔。多裝置情境優先讓每台裝置各自拉取同一訂閱,而不是手動搬運設定檔;部分用戶端支援 WebDAV 備份,可以把介面設定也一併同步。三種方案的完整對比見多裝置同步筆記。

常見故障的排查順序

斷線時不要立刻改設定,按由外到內的順序確認,九成問題在前三步就能定位。第一步:關掉用戶端,直接連一個國內網站,確認本機網路本身通暢——家用寬頻斷線、Wi-Fi 認證過期這類原因與 Clash 無關,卻最常被誤判成用戶端故障。第二步:打開用戶端但切到 DIRECT 模式,如果這時一切正常,說明問題出在代理鏈路而不是用戶端安裝;如果連 DIRECT 都不通,那是本機代理設定或虛擬網卡殘留的問題,結束用戶端並檢查系統代理開關是否被遺留在開啟狀態。第三步:切回 RULE 模式,在策略群組裡手動換一個節點並做延遲測試,全部節點都逾時通常意味著訂閱過期、流量額度用盡或服務商線路調整,登入服務商後台看公告與剩餘流量比改任何設定都直接。

如果前三步都正常,只有個別網站或應用程式異常,那就屬於分流問題而非連通問題,回到第六章的排查方法:看日誌裡那條連線命中了哪一行規則,再決定是補一條更精確的規則,還是調整規則順序。還有一類容易被忽略的現象是「能開啟網頁但影片不載入、登入一直轉圈」,多數與 DNS 或 fake-ip 相關,可以先關掉 TUN 改用系統代理複測:如果關掉就正常,說明需要把相關網域加入 fake-ip 過濾名單,而不是換節點。養成「一次只改一個變數」的習慣,每改一項就複測一次,才能真正知道是哪一處生效,否則改了五處全部恢復,下一次遇到同樣問題依然要從零開始。

升級用戶端

用戶端更新通常同時帶來核心更新,建議跟進,新規則類型與協定支援都依賴核心版本。升級前看一眼發布說明裡是否有設定不相容提示;主流用戶端升級會保留訂閱與設定,但重大版本跨越前,把訂閱連結另外複製保存再動手,成本幾乎為零,收益是絕對安心。新版安裝包始終從下載頁對應平台取得。

走完前八章,日常使用已經沒有障礙。這一章給出繼續深入的三個方向,依投入產出排序。

方向一:掌握自己的規則

訂閱自帶的規則是服務商的通用方案,進階的第一步是建立自己的規則層。多數現代用戶端支援「設定覆寫」或「Merge/Script」機制:在不修改訂閱原文的前提下,把自訂規則注入到規則列表最前面——訂閱更新不會蓋掉你的修改。從小處開始:把日常遇到的分流錯誤逐條修正,累積三個月,你會得到一份完全貼合自己使用習慣的規則層。規則集(rule-providers)是更工程化的組織方式,把規則依用途拆成可獨立更新的遠端檔案,值得在規則超過百條後引入。

方向二:讀懂 mihomo 的強化能力

mihomo 核心在經典 Clash 設定格式之上擴充了不少能力:更多協定支援、更細緻的 DNS 控制、行程層級比對規則、出站介面繫結等。這些特性大多需要手寫設定片段才能啟用,官方文件是唯一權威來源。學習方法是逐項實驗:每次只加一段,載入成功再加下一段,設定出錯時日誌會精確到行號。在伺服器或軟體路由器上直接部署核心 + systemd,是這個方向的畢業專案——沒有圖形介面兜底,所有行為都由你寫的 YAML 決定。

方向三:理解生態,判斷資訊

Clash 生態專案多、更名頻繁,搜尋到的教學常基於已封存的舊專案,照著做容易踩雷。建立系譜認知——哪個核心是活躍的、哪些用戶端基於它、哪些專案已停止維護——能讓你快速判斷一篇教學的時效性。開源系譜梳理是入口;之後關注各專案的發布頁,而不是二手轉載。

建議的學習順序

1. 用教學頁跑通基本流程,穩定使用兩週。
2. 回到第六章,看懂訂閱自帶的規則列表,修正一條真實遇到的分流錯誤。
3. 開啟 TUN,理解 fake-ip,覆蓋命令列與全域情境。
4. 引入設定覆寫,建立自己的規則層。
5. 在閒置裝置上部署純核心,完成從用戶到管理者的轉變。

每一步都建立在上一步的肌肉記憶上,不建議跳級。遇到具體名詞回名詞解釋查,用戶端相關疑問看橫向評測,工具本身隨時從下載頁取得。