Clash 從零到精通完整手冊

Clash 是一個以設定檔驅動的規則式代理核心。它本身沒有圖形介面,啟動後讀取一份 YAML 格式的設定,在本機監聽若干埠號,把進入這些埠號的網路請求逐條依規則比對,再決定這條連線走直連、走某個代理節點,還是直接拒絕。你在各類客戶端裡看到的開關、節點清單、模式切換,底層都是對這份設定與這套比對流程的封裝——理解了這一點,後面每一章都會變得容易上手。

原始的 Clash 核心已停止開發,目前生態的事實標準是社群延續的 Mihomo 核心(常被稱作 Clash Meta)。Mihomo 完整相容原有設定格式,並在此基礎上補齊了更多代理協定、規則類型與 DNS 能力。本站取得客戶端頁收錄的軟體,要麼直接內建 Mihomo,要麼與其設定格式相容,因此本手冊的範例預設以 Mihomo 的行為為準。

客戶端與核心是兩層東西。核心負責真正的流量轉發;客戶端負責把核心管起來:替你下載訂閱、產生設定、拉起核心程序、設定系統代理、顯示節點延遲。換客戶端不影響你對核心的理解,設定檔在不同客戶端之間大致通用,這也是先學概念再挑軟體的原因。

一份完整設定大致由五塊組成:埠號宣告、節點清單(proxies)、代理群組(proxy-groups)、規則(rules)與 DNS 設定。骨架如下:

mixed-port: 7890        # HTTP 與 SOCKS 共用的混合監聽埠
mode: rule              # 執行模式:rule / global / direct
log-level: info

proxies: []             # 節點清單,通常由訂閱填入
proxy-groups: []        # 代理群組:把節點組織成可選擇的策略
rules:                  # 規則:自上而下比對,命中即停
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

規則引擎的比對方式只有一條鐵律:自上而下逐條比對,第一條命中的規則決定這條連線的去向,後面的規則不再參與。所以規則的順序就是優先權,精確規則放前面、兜底規則放最後,這個原則貫穿第 6 章的全部內容。

代理群組是 Clash 區別於簡單代理工具的關鍵抽象。規則的出口不直接指向某個節點,而是指向一個群組;群組內再決定用哪個節點——可以手動選擇,也可以依延遲自動挑選。訂閱更新、節點增減都發生在群組內部,規則本身不用改,這讓設定具備長期可維護性。

最後是埠號:核心預設只在本機回送位址 127.0.0.1 上監聽,瀏覽器或系統代理把流量交到這個埠,核心才開始工作。埠號、監聽位址都可設定,涉及區域網路共享時才需要放開,細節見第 5 章。

挑客戶端之前先回答三個問題:用什麼系統、要不要 TUN 模式接管全部流量、願不願意在設定上花時間。三個問題想清楚,選擇範圍會立刻收窄。下表是本站下載頁收錄客戶端的速查,與取得客戶端頁保持一致:

Clash Plus 是全平台首推:Windows、macOS、Android、iOS 四端覆蓋,是清單裡唯一在 App Store 上架的選擇,iOS 用戶沒有第二條正路。介面把訂閱、模式、節點選擇收在同一層選單裡,預設設定對新手友善,進階選項也沒有閹割,適合作為第一個客戶端。

Clash Verge Rev 是 Linux 桌面的主力,也是本手冊 Linux 範例的預設對象。它直接內建 Mihomo 核心,提供 deb 與 rpm 安裝包,支援設定覆寫、Merge 腳本與服務模式,TUN 相關的權限處理也做得相對完整——願意深入設定的用戶會喜歡它揭露出來的細節。

FlClash 用 Flutter 撰寫,桌面端與行動端介面幾乎一致,如果你在手機和電腦之間頻繁切換、希望兩邊操作習慣統一,它是最省心的選擇。Clash Nyanpasu 是 Windows 上的另一個活躍分支,介面風格更輕快,功能取向與 Verge Rev 接近,作為備選足夠可靠。

Android 上除了 Clash Plus,Clash Meta for Android 是最貼近核心原生行為的選擇,設定項直接對應核心欄位,適合想看清底層的用戶;Surfboard 則走輕量路線,匯入訂閱即用。Clash for Windows 與 ClashX Meta 均已停止維護,舊用戶可以繼續使用手上的版本,新裝機不建議從它們開始。

伺服器與路由器場景不需要圖形介面,直接部署裸 Mihomo 核心:一個執行檔加一個設定目錄即可長期運作,搭配 systemd 管理程序,細節在第 8 章與第 9 章展開。

所有安裝包從取得客戶端頁對應平台的卡片下載。Linux 用戶先確認發行版與 CPU 架構:主流桌面發行版基本是 x86_64(amd64),下載時對準檔名裡的架構標識,別把 arm64 版本裝到英特爾或 AMD 的機器上。

Ubuntu / Debian 系

下載 .deb 包後用 apt 本地安裝,apt 會自動解析並補齊依賴,這比 dpkg 直裝少踩一次依賴坑:

sudo apt update
sudo apt install ./clash-verge-rev_amd64.deb

注意指令裡的 ./ 前綴不能省:它告訴 apt 這是本地檔案而不是軟體庫裡的套件名稱。安裝完成後可以在應用程式選單找到圖示,也可以直接在終端機輸入程式名稱啟動。

Fedora 系

sudo dnf install ./clash-verge-rev.rpm

dnf 同樣會處理依賴。若提示缺少 webkit2gtk 一類元件,依提示確認安裝即可,那是圖形介面渲染所需的系統函式庫,並非軟體本身的問題。

Arch 系

# 已有二進位套件時本地安裝
sudo pacman -U clash-verge-rev.pkg.tar.zst

# 或從 AUR 建置(以 paru 為例)
paru -S clash-verge-rev

AUR 路線的好處是後續升級隨系統滾動更新,壞處是建置耗時;兩條路裝出來的東西一致,依習慣選就好。

其他平台

Windows 雙擊安裝程式依指引完成,首次啟動時防火牆會詢問是否放行網路存取,選擇允許,否則核心無法監聽埠號。macOS 把應用程式拖入「應用程式」資料夾,首次開啟如被系統擋下,到「系統設定 → 隱私權與安全性」點「仍要打開」;下載前先分清 Apple Silicon 與 Intel 兩種版本。Android 直接安裝 APK,系統詢問「安裝未知應用程式」權限時對瀏覽器或檔案管理器授權一次即可;iOS 在 App Store 搜尋安裝 Clash Plus。

首次啟動檢查

不論哪個平台,第一次啟動後花一分鐘確認三件事:一,系統匣或狀態列出現了程式圖示,說明主程序活著;二,打開客戶端的日誌頁面,能看到核心啟動輸出而不是紅色錯誤訊息;三,設定裡找到「開機自動啟動」並依需求開啟。Linux 桌面用戶如果客戶端提供「服務模式」,建議此時順手安裝——它會註冊一個系統服務替你以足夠的權限拉起核心,第 7 章的 TUN 模式會用到。

訂閱本質上是一個 URL:服務商把節點清單(通常是一份完整的 Clash 設定,或可被客戶端轉換的節點清單)放在這個位址上,客戶端定期去抓取,抓回來的內容落地成本地設定檔,再交給核心載入。理解「訂閱 = 遠端設定的來源」這層關係,後面訂閱更新、覆寫、失效排查都順理成章。

匯入訂閱

各客戶端流程一致:完整複製服務商提供的訂閱連結,打開客戶端的「訂閱」或「Profiles」頁面,貼到輸入框,點匯入或下載。成功後清單裡會出現一個設定項,點擊啟用,再回到「代理」頁面就能看到節點清單。如果節點清單是空的,說明下載或解析環節出了問題,別反覆重試同一個動作,依下文的失敗排查走。

更新訂閱

服務商的節點會變動,訂閱需要定期更新。多數客戶端支援為訂閱設定自動更新間隔(如每 24 小時),也可以隨時手動點更新按鈕。注意一個容易吃虧的行為:更新訂閱會用遠端內容覆蓋本地檔案,你直接改在訂閱檔案裡的自訂規則會在下一次更新時消失。正確做法是使用客戶端的「覆寫」或「Merge」機制,把自訂內容放在訂閱之外的獨立檔案裡,更新時自動合併,第 9 章會展開。

匯入失敗排查

訂閱匯入報錯時,依層次自查:連結是否完整(結尾參數被截斷很常見)、在瀏覽器裡打開該連結是否回傳文字內容而不是 404 或一個網頁、服務商是否限制了 User-Agent(部分訂閱只對 Clash 系 UA 回傳設定)、回傳內容是否為合法 YAML。逐項對照的完整清單見技術筆記《Clash 訂閱連結失效與解析失敗排查清單》。

設定檔在哪

客戶端會把訂閱落地在自己的設定目錄裡,Linux 下通常位於 ~/.config 或 ~/.local/share 下以客戶端命名的子目錄,裸核心預設讀取 ~/.config/mihomo/config.yaml。知道位置有兩個用途:備份,以及在客戶端介面異常時直接查看檔案內容判斷問題出在設定還是程式。

手動維護設定的用戶可以完全不用訂閱:自己編寫 config.yaml,把節點寫進 proxies,客戶端以「本地檔案」方式匯入。這條路自由度最高,也最考驗對欄位的理解,建議先用訂閱跑通全流程,再逐步過渡。

核心有三種執行模式,對應設定裡的 mode 欄位。規則模式(rule)是日常預設:每條連線都過一遍規則表,該直連的直連、該走代理的走代理,速度與可用性兼顧。全域模式(global)把所有流量都交給代理出口,適合臨時驗證「到底是不是分流規則的問題」,不適合長期開著——本地流量繞一圈國外節點,又慢又耗流量。直連模式(direct)讓所有流量都不走代理,等同於臨時停用而不必退出程式。排障時在三種模式間切換對比,是定位問題最快的手段之一。

埠號:流量的入口

模式決定流量的去向,埠號決定流量怎麼進來。現代設定推薦只宣告一個 mixed-port(慣例用 7890):它同時接受 HTTP 與 SOCKS5 兩種協定,瀏覽器、系統代理、命令列工具都指向這一個埠即可,不必再分別維護 port 與 socks-port。

「開了 Clash 但網頁沒走代理」的第一原因,是流量根本沒進這個埠。桌面客戶端的「系統代理」開關做的事,就是把作業系統的代理設定指向 127.0.0.1:7890;這個開關沒開,核心就只是空轉監聽。GNOME 用戶可在「設定 → 網路 → 網路代理」確認,KDE 在「系統設定 → 網路 → 代理」,兩處都應顯示回送位址加埠號。

終端機程式不吃系統代理

Linux 下大量命令列工具(curl、git、套件管理器)不讀取桌面環境的代理設定,它們認環境變數。臨時給目前終端機工作階段掛上代理:

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890

寫進 ~/.bashrc 可長期生效,但更推薦做成 shell 函式按需開關,避免代理停用後終端機請求全部卡住。驗證是否生效:curl -I https://www.google.com 能快速回傳回應標頭即為成功。

區域網路共享與埠號衝突

預設監聽 127.0.0.1 意味著只有本機能用。把 allow-lan 設為 true 並放開綁定位址後,同一區域網路的手機、電視盒可以把這台機器當作代理伺服器,設定方法與防火牆放行、安全邊界的完整討論見技術筆記《Clash 混合埠與區域網路共享代理設定》。另一類高頻問題是啟動時報 address already in use——7890 被別的程序占用了,定位與改埠號的全流程見《Clash 埠被占用怎麼辦》;改完 mixed-port 記得同步更新系統代理與環境變數裡的埠號,漏一處就會出現「一半程式能上一半不能」的怪象。

規則分流是 Clash 的靈魂。每條規則由三段組成:類型,比對內容,出口——出口可以是某個代理群組、內建的 DIRECT(直連)或 REJECT(拒絕)。第 1 章講過的鐵律在這裡重述一次:自上而下比對,首條命中即定終身。常用規則類型如下:

兩個細節值得單獨講。其一,IP 類規則會觸發網域解析:一條連線的目標如果還是網域,核心要先解析出 IP 才能比對 IP-CIDR,這次解析可能帶來延遲甚至洩露查詢。給純內網段規則加上 no-resolve 參數,讓它只比對「本來就是 IP 的連線」,是通行做法。其二,MATCH 必須放最後一條,它是所有規則都沒命中時的兜底出口;兜底指向哪個群組,決定了「陌生流量」的預設去向。

代理群組:規則的出口

規則出口指向群組而不是節點,群組的類型決定選擇策略:select 手動挑選,url-test 定期測延遲自動選最快,fallback 依序找第一個可用的,load-balance 把請求分散到多個節點。群組還可以互相嵌套——手動群組裡放一個自動測速群組,平時交給自動,特殊時期手動指定,是最常見的組織方式:

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies: []        # 訂閱節點通常經 provider 注入

rules:
  - DOMAIN-SUFFIX,openai.com,PROXY
  - DOMAIN-KEYWORD,github,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

這五條規則是一個可直接使用的最小骨架:前兩條把明確需要代理的網域送進 PROXY 群組,第三條放行內網,第四條讓歸屬地為中國大陸的 IP 直連,最後兜底走代理。日常擴充就是往前面插入更精確的網域規則。

最後強調一次維護姿勢:自訂規則不要直接寫進訂閱檔案(下次更新會被覆蓋),用客戶端的覆寫機制注入到訂閱規則之前。規則越靠前優先權越高,所以「我的規則在上、訂閱規則在中、GEOIP 與 MATCH 在底」是穩定的三明治結構。GEOIP 判斷依賴本地資料庫,長期不更新會出現歸屬地誤判,更新方法見第 8 章。

系統代理有個先天局限:它只是一份「建議」,遵不遵守由應用程式自己決定。瀏覽器會遵守,大量遊戲、聊天軟體、走 UDP 的程式根本不看代理設定。TUN 模式換了一條路:核心建立一塊虛擬網卡,配合路由規則把整個系統的出站流量都導向這塊網卡,應用程式對此毫無感知——從它們的視角看,網路本來就長這樣。要讓「所有程式無差別走分流」,TUN 是正解。

設定範例

tun:
  enable: true
  stack: system          # 可選 system / gvisor / mixed
  auto-route: true       # 自動設定路由表
  auto-detect-interface: true
  dns-hijack:
    - any:53             # 劫持發往 53 埠的 DNS 查詢

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

逐項解釋:stack 是虛擬網卡的協定堆疊實作,system 依賴作業系統、效能好,gvisor 是使用者態實作、相容性問題少,mixed 取兩者折衷,Linux 上一般先試 system。auto-route 與 auto-detect-interface 負責路由表的自動增刪,讓流量進虛擬網卡、核心自身的出站流量走實體網卡,不開它們就得手動維護路由,極易把自己鎖在斷網狀態。

為什麼 TUN 必須管 DNS

TUN 拿到的是 IP 層流量,如果 DNS 解析仍在系統層完成,核心看到的全是 IP、失去了依網域分流的能力,所以 dns-hijack 把 DNS 查詢也抓進來。fake-ip 模式更進一步:核心對每個網域查詢先回傳一個保留段假 IP,應用程式拿假 IP 發起連線,核心憑假 IP 反查出網域再做規則比對——省掉一次真實解析,延遲更低。副作用是個別對 IP 有校驗的程式會不適,那時可換回 redir-host 模式或給特定網域設定 fake-ip-filter 排除項。

Linux 上的權限

建立虛擬網卡與改路由需要 CAP_NET_ADMIN 權限。桌面客戶端走「服務模式」最省事:客戶端註冊一個系統服務,由服務以特權拉起核心,介面裡一鍵開關 TUN。裸核心用戶可以用 setcap 給執行檔授權,免去每次 sudo:

sudo setcap 'cap_net_admin,cap_net_bind_service=+ep' /usr/local/bin/mihomo

常見的坑有三個:一,TUN 與系統代理同時開著,流量被處理兩次,關掉系統代理開關即可;二,切換網路(如插拔網路線、連不同 Wi-Fi)後 NetworkManager 重寫路由導致斷流,重啟一次 TUN 讓 auto-route 重建路由;三,核心異常退出沒來得及清理路由,表現為關了 Clash 反而上不了網,同樣以「再開再關」或重啟網路服務恢復。TUN 開啟後,驗證方式是隨便找一個不支援代理設定的命令列程式存取網路,觀察客戶端連線頁裡是否出現了它的行程名稱。

設定跑通之後,維護工作其實很少,但有幾件事值得養成習慣,能把「突然連不上」的機率壓到最低。

三樣東西要定期更新

第一是訂閱:開自動更新或每週手動點一次,節點變更服務商不會逐一通知你。第二是 GeoIP / Geosite 資料庫:第 6 章的 GEOIP,CN,DIRECT 依賴本地資料庫判斷 IP 歸屬,資料庫過舊會把該直連的流量送去代理、或反過來,多數客戶端在設定裡提供一鍵更新入口,裸核心可替換設定目錄下的資料庫檔案後重啟。第三是客戶端本身:從哪裝的就從哪升級——apt 裝的用 apt 升級、AUR 裝的隨系統滾動更新,別在同一台機器上混用兩種安裝來源,那是「卸載不乾淨、兩個版本打架」這類玄學問題的溫床。

學會看日誌

日誌是排障的第一現場。設定裡 log-level: info 適合日常,排障時臨時調成 debug 看細節,問題解決後調回來(debug 量大且影響效能)。幾條高頻日誌行值得眼熟:dial tcp ... i/o timeout 通常指向節點無法連線,connection refused 多為目標埠沒開或被本機防火牆擋下,規則命中行則能告訴你某條連線實際比對到哪條規則、走了哪個出口——分流不符合預期時先看這一行,而不是盲目改規則。逐條解讀見技術筆記《看懂 Clash 執行日誌》。

備份與復原

值得備份的只有設定目錄:訂閱位址、覆寫檔案、自訂規則都在裡面,打包一份丟進你的常規備份流程,換機或重灌時解包回原路徑即可復原。裸核心場景一條指令的事:tar czf mihomo-backup.tar.gz ~/.config/mihomo。客戶端場景先在設定裡確認設定目錄路徑再打包。

開機自動啟動

桌面客戶端在設定裡勾選自動啟動即可。伺服器上的裸核心交給 systemd 管理,寫一個服務單元:

# /etc/systemd/system/mihomo.service
[Unit]
Description=mihomo daemon
After=network-online.target

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

[Install]
WantedBy=multi-user.target

隨後 sudo systemctl enable --now mihomo 一步完成註冊與啟動,journalctl -u mihomo -f 即時追蹤日誌。Restart=on-failure 保證程序異常退出後自動拉起,長期無人值守場景必配。

最後留一個排障總原則:一次只改一個變因。改了埠號就先驗證埠號,換了節點就先測節點,同時動三處設定再出問題,你將無從知道是哪一處引起的。啟動類故障(閃退、白畫面、核心拉不起來)的分類排查見《Clash 客戶端啟動閃退與當機處理》。

走完前八章,日常使用已經沒有障礙。這一章給願意繼續深入的用戶畫一張路線圖,每個方向都有明確的收益,依需求挑著走即可,不必全部點亮。

方向一:覆寫與設定合併

第 4 章提過訂閱更新會覆蓋本地改動,覆寫機制就是解法:把自訂埠號、TUN 設定、私有規則寫在獨立的覆寫檔案裡,客戶端在每次載入訂閱時自動合併。Clash Verge Rev 提供 Merge(YAML 層面的欄位合併)與腳本(以程式碼方式改寫最終設定)兩種形式,前者能覆蓋九成需求,後者留給真正的特殊場景。掌握覆寫之後,你的個人化設定就和訂閱徹底解耦了——換訂閱、換服務商,自己的東西一行不丟。

方向二:provider 拆分

proxy-providers 與 rule-providers 把節點和規則從主設定裡拆出去,各自獨立成遠端或本地檔案、獨立設定更新週期。規則集(rule-set)尤其實用:社群維護著依用途分類的網域清單,設定裡引用清單名稱而不是逐條抄寫網域,規則表從幾百行縮到十幾行,可讀性與維護性都上一個台階。

方向三:外部控制介面

設定裡宣告 external-controller: 127.0.0.1:9090 後,核心會開放一套 RESTful 介面,切換節點、查看連線、測延遲都能透過 HTTP 請求完成。配合社群的 Web 面板,瀏覽器裡就能管理執行中的核心——這正是伺服器場景的標準操作方式,也是理解「客戶端到底替你做了什麼」的最好教材:客戶端介面上的每個按鈕,背後都是這套介面的某次呼叫。

方向四:伺服器裸核心部署

把第 8 章的 systemd 單元、本章的外部控制介面、第 7 章的 TUN 組合起來,就是一台旁路閘道或軟路由的完整方案:區域網路裝置把閘道指向這台機器,全家裝置統一分流,終端裝置上不需要裝任何東西。這個方向動的是路由與 DNS 基礎設施,建議在虛擬機裡演練一遍再上真實網路,並給自己留一條不經過閘道的管理通道。

學習資源的使用順序

建議的查閱順序:概念疑問先查術語手冊(依核心與客戶端、代理協定、規則與分流、網路與埠號、設定檔欄位五類組織);操作路徑回看使用文件;具體故障對著技術筆記的排查文逐項核對;高頻短問題在 FAQ 類內容裡通常有現成答案。手冊本身也會隨核心與客戶端生態的變化持續修訂,遇到與實際介面不一致的地方,以客戶端內的最新文案為準,思路不變。

精通沒有捷徑,但有明確的標誌:看到一條日誌能說出它屬於哪個環節,拿到一份陌生設定能預判它的分流行為,網路異常時知道先切哪個模式、看哪一行輸出。到那時,這份手冊就完成任務了——祝順利。