Clash 設定檔參考大全

詳圖 B-01手冊定位與閱讀路線

本站的內容分兩條線。入門教學是快速上手主線,按「安裝客戶端 → 匯入訂閱 → 選擇模式 → 驗證連通」的順序走完,即可進入正常使用狀態,全程不要求閱讀設定檔。本頁是另一條線:系統化查閱手冊,面向需要打開 config.yaml 閱讀或修改的場景——例如排查某條規則為什麼不生效、在訂閱之外追加幾條自訂分流、或從零手寫一份最小可用設定。兩條線互為索引:第一次接觸 Clash 的讀者應先完成教學頁流程,設定能跑起來之後,再回到本頁按欄位編號查閱。

欄位口徑需要先說清楚。目前主流圖形客戶端——Clash Plus、Clash Verge Rev、FlClash 等,完整清單見安裝包頁與客戶端對比頁——底層均運行 mihomo 核心或相容核心,讀取的是同一套 YAML 設定格式。本頁以各核心公認的通用欄位為主體;個別僅新核心支援的擴充能力,會在對應段落單獨註明,避免照抄到舊核心後出現「欄位無法識別」的載入錯誤。

閱讀路線建議如下:想改分流規則,直接查詳圖 B-07 與 B-08;訂閱一更新手動修改就丟失,查詳圖 B-09;某個節點連不上,先看節點逾時排查文再考慮動設定;完全上不了網,優先回 常見問題頁與教學頁排查客戶端與系統代理狀態,不要在故障狀態下盲改設定檔。

詳圖 B-02YAML 結構總覽

三條書寫鐵律

config.yaml 是一份標準 YAML 文件,由若干頂層鍵組成,每個頂層鍵負責一個子系統。YAML 的書寫有三條鐵律,絕大多數「設定載入失敗」都是其中之一被破壞:其一,縮排只能用空格,約定俗成兩個空格一級,禁止使用 Tab 定位字元;其二,「鍵: 值」的冒號後面必須有一個空格,port:7890 會被當作整個字串而不是鍵值對;其三,清單項目以「- 」開頭,同層級項目的短橫線必須對齊在同一欄。

字串引號也常出問題:值裡含有 #、冒號、花括號,或以特殊符號開頭時,必須用引號包住,否則 # 之後的內容會被當成註解截斷。節點名含 emoji、空格或全角字元時,建議一律加雙引號,消除解析歧義,策略組引用時也照原樣帶引號書寫。

頂層鍵索引

最小可用骨架

下面是一份結構完整的最小設定骨架,五個部分齊備即可被核心載入。後續各詳圖逐段放大講解:

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://doh.pub/dns-query

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

proxy-groups:
  - name: "節點選擇"
    type: select
    proxies:
      - "範例節點"
      - DIRECT

rules:
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

閱讀一份陌生設定的建議順序:先看 mode 與連接埠段確認工作方式,再看 proxy-groups 理解出口的組織結構,最後看 rules 確認流量走向;proxies 段通常由訂閱自動生成,只在排查單一節點問題時才需要逐欄位細看。

詳圖 B-03通用欄位:連接埠、模式與控制介面

連接埠三件套

port 是純 HTTP 代理連接埠,socks-port 是 SOCKS5 連接埠,mixed-port 則在同一連接埠上同時受理兩種協定。現行客戶端預設使用 mixed-port: 7890,系統代理、瀏覽器手動代理、終端機環境變數都指向這一個連接埠即可,不必分別設定。三個鍵填 0 或直接省略表示不監聽對應連接埠。需要注意:修改連接埠號之後,系統代理設定必須同步更新,否則會出現「客戶端在運行、流量卻不進來」的假故障——這類問題的完整排查見系統代理不生效排查文。

區域網路共享

allow-lan: true 會讓區域網路內其他裝置把本機當作代理伺服器使用,常見用途是給不方便裝客戶端的電視盒子、遊樂器指定一個代理出口;搭配 bind-address 可以限定只在某張網卡上監聽。在咖啡廳、機場等公共網路環境下應保持 false,否則同網段任何人都能使用你的出口。

工作模式 mode

日誌與控制介面

log-level 取值從簡到繁為 silent / error / warning / info / debug。日常保持 info 即可;排查某條規則是否命中時切到 debug,核心會逐條印出連線的匹配結果,查完切回,長期 debug 會產生大量日誌。external-controller 定義 RESTful 控制介面的監聽位址(常見 127.0.0.1:9090),圖形客戶端的連線面板、節點切換、延遲測試全部透過它讀寫核心狀態;secret 是該介面的存取密鑰。ipv6: false 時核心不解析也不連線 IPv6 位址,所在網路的 IPv6 連線不穩時可先保持關閉。

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090
secret: "xxxx"

另有一個體量較大的頂層鍵 tun:以虛擬網卡方式接管全部系統流量,可以解決部分程式不讀系統代理的問題。它的子欄位在不同核心版本間差異較大,且涉及系統權限,建議直接使用客戶端介面提供的「TUN 模式」開關,由客戶端生成正確欄位,不手寫;開啟前的注意事項見 常見問題頁對應條目。

詳圖 B-04DNS 設定:解析層的分流地基

為什麼代理場景要單獨設定 DNS

規則匹配大量發生在網域層。如果網域在進入核心之前就被本地網路污染解析成錯誤 IP,那麼 GEOIP 一類按 IP 歸屬判斷的規則也會跟著誤判,表現為「規則寫得沒錯,流量卻走錯出口」。dns 段的作用就是讓核心接管解析過程,確保匹配所依據的解析結果可信。enable: true 是整段生效的前提。

enhanced-mode 兩種工作方式

fake-ip 模式下,核心對每個網域傳回一個保留網段(預設 198.18.0.1/16)裡的假位址,真正建立連線時再按網域匹配規則並解析。好處是省去一次前置解析、延遲更低,且從根本上避免解析結果被本地網路干擾,是目前的預設推薦。redir-host 模式傳回真實 IP,相容性更好,但每個連線多一次解析。選用 fake-ip 時,fake-ip-filter 必須列出需要拿到真實 IP 的網域——區域網路裝置的管理網域、NTP 時間同步、部分遊戲對戰平台等,否則這些服務會拿著假位址無法運作。

三組伺服器的職責邊界

default-nameserver 只承擔一件事:解析 nameserver 裡 DoH/DoT 伺服器自身的網域,因此必須填純 IP 位址,不能再填網域,否則出現「先有雞還是先有蛋」的死結。nameserver 是主解析組,承擔全部日常查詢,建議填寫加密 DNS 位址。部分核心還支援 fallback 組:當主組結果命中污染特徵時,改用該組(通常填海外解析服務)的結果,屬可選增強。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "time.windows.com"
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query

詳圖 B-05代理節點欄位:proxies 陣列

proxies 是節點定義陣列。使用訂閱的使用者,這一段由訂閱轉換服務自動生成,日常不需要手寫;需要手寫的典型場景是自建伺服器或偵錯單一節點。所有協定共用四個公用欄位:name(節點名,全檔案唯一,策略組按名稱引用)、type(協定類型)、server(伺服器位址,網域或 IP)、port(伺服端連接埠)。其餘欄位隨協定不同,以下按下載頁涵蓋的常見協定逐一列出。

Shadowsocks(type: ss)

核心欄位兩個:cipher 加密方法與 password 密碼,兩者必須與伺服端完全一致,任一項不匹配的表現都是連線建立後立即斷開或無回應:

- name: "ss-範例"
  type: ss
  server: example.com
  port: 8388
  cipher: aes-128-gcm
  password: "your-password"

VMess(type: vmess)

身分憑證是 uuid,須與伺服端逐字元一致;alterId 現行部署一律為 0;cipher 通常填 auto。走 WebSocket + TLS 的節點還需要 network: ws 與 ws-opts 子段,其中 path 與 headers.Host 必須與伺服端設定對齊,這兩處寫錯是 VMess 節點逾時的高發原因:

- name: "vmess-範例"
  type: vmess
  server: example.com
  port: 443
  uuid: 00000000-0000-0000-0000-000000000000
  alterId: 0
  cipher: auto
  tls: true
  network: ws
  ws-opts:
    path: /your-path
    headers:
      Host: example.com

Trojan 與 Hysteria2

Trojan 以 password 為憑證,依賴真實 TLS 憑證,sni 需要指向憑證對應網域。Hysteria2 基於 QUIC(UDP 傳輸),除 password 外可用 up / down 宣告頻寬以啟用其壅塞控制;所在網路封鎖 UDP 時該協定整體無法使用,排查時優先確認這一點:

- name: "trojan-範例"
  type: trojan
  server: example.com
  port: 443
  password: "your-password"
  sni: example.com

- name: "hy2-範例"
  type: hysteria2
  server: example.com
  port: 443
  password: "your-password"

欄位確認無誤仍然連不上時,問題通常不在設定檔本身,按節點逾時排查清單的順序檢查訂閱有效性、系統時間與防火牆。

詳圖 B-06策略組欄位:proxy-groups 陣列

策略組是規則與節點之間的中間層:規則的出口指向組名,組再決定實際使用哪個節點。這一層解耦的價值在於,訂閱節點改名、增刪時只需要維護組的成員清單(訂閱轉換通常自動完成),規則一行都不用動。四種常用類型如下:

自動測速參數

url-test 與 fallback 依賴三個參數:url 填輕量測活位址(慣用 https://www.gstatic.com/generate_204,傳回空回應,開銷極小);interval 是測速週期,單位秒,常用 300;tolerance 單位毫秒,表示新節點延遲必須比目前節點低出該值才切換,用來防止兩個延遲相近的節點來回抖動。可選的 lazy: true 讓組只在被實際使用時才發起測速,減少背景請求。

巢狀與內建出口

組可以巢狀:慣例做法是建一個 select 總出口組,把 url-test 自動組和若干手動節點一併列為成員,日常掛自動組,需要時一鍵切到指定節點。DIRECT(直連)與 REJECT(拒絕)是核心內建的兩個出口,可直接作為任何組的成員或規則的出口使用,不需要定義:

proxy-groups:
  - name: "節點選擇"
    type: select
    proxies:
      - "自動測速"
      - "香港-01"
      - "日本-01"
      - DIRECT

  - name: "自動測速"
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - "香港-01"
      - "日本-01"

命名紀律:組名不要與節點名重複;規則與組成員裡引用的名字必須與定義處逐字一致,包括 emoji、空格與全半角——任一處不一致,核心會以「proxy not found」類錯誤拒絕載入整份設定,這也是訂閱節點改名後設定突然報錯的常見根因。

詳圖 B-07規則語法與匹配順序

rules 陣列自上而下逐條匹配,命中第一條即停止,不再看後面的規則——書寫順序就是優先順序,這是理解一切分流行為的第一原理。每條規則的基本格式為「類型,匹配值,出口」,部分類型支援附加參數。出口可以是策略組名、節點名,或內建的 DIRECT / REJECT。

排序原則與 no-resolve

建議排序:精確類(DOMAIN)在前,範圍類(DOMAIN-SUFFIX / DOMAIN-KEYWORD)居中,IP 類(GEOIP / IP-CIDR)靠後,MATCH 必須且只能是最後一條。IP 類規則匹配前需要先把網域解析成 IP,會引入額外解析開銷;對內網段、保留段這類「目標本來就是 IP」的規則,在行尾加上 no-resolve 參數,聲明「目標不是 IP 就跳過本條」,避免無謂解析:

rules:
  - DOMAIN,dl.google.com,節點選擇
  - DOMAIN-SUFFIX,github.com,節點選擇
  - DOMAIN-KEYWORD,google,節點選擇
  - DOMAIN-SUFFIX,cn,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

三處高發誤寫

其一,MATCH 之後還寫了規則——由於命中即停,那些規則永遠不會被執行,屬於無效行;其二,以為 DOMAIN-SUFFIX,cn 能涵蓋所有中國大陸站點——它只匹配 .cn 後綴,大量中國大陸服務使用 .com 網域,中國大陸流量的兜底應交給 GEOIP,CN;其三,出口名與策略組定義不一致(差一個空格或 emoji),整份設定拒絕載入。境內外分流的完整寫法與匹配演算,另見規則分流設定實戰一文;只想快速用起來,可直接套用入門教學給出的成品規則段。

詳圖 B-08規則集:rule-providers 外部規則

手動維護上千行規則不現實。規則集機制把大批量規則外置成獨立檔案,設定裡只保留來源宣告與一行引用,核心按週期自動抓取更新。它由兩部分配合:頂層鍵 rule-providers 定義來源,rules 裡的 RULE-SET 條目消費它。

欄位逐項說明

type 取 http(遠端抓取)或 file(本地檔案)。behavior 宣告檔案的內容形態,共三種:domain 表示檔案只含網域清單;ipcidr 表示只含網段清單;classical 表示每行是「類型,匹配值」的完整規則。behavior 必須與檔案實際內容一致——不一致時規則集不會報錯,而是靜默失效,這是規則集「看起來載入了卻不生效」的頭號原因。format 宣告檔案格式(yaml 或 text);url 是遠端位址;path 是本地快取路徑,不同規則集不要共用同一個 path,否則互相覆蓋;interval 是更新週期,單位秒,86400 即一天一次。

rule-providers:
  reject-list:
    type: http
    behavior: domain
    format: yaml
    url: https://example.com/rules/reject.yaml
    path: ./ruleset/reject.yaml
    interval: 86400

  cn-cidr:
    type: http
    behavior: ipcidr
    format: yaml
    url: https://example.com/rules/cn-cidr.yaml
    path: ./ruleset/cn-cidr.yaml
    interval: 86400

rules:
  - RULE-SET,reject-list,REJECT
  - RULE-SET,cn-cidr,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

兩點補充:RULE-SET 條目在 rules 裡的位置同樣遵循「自上而下、命中即停」的總順序,規則集不是插隊通道;引用 ipcidr 類規則集時,與 IP-CIDR 規則同理,建議在引用行尾加 no-resolve。遠端規則集首次抓取需要網路可連通,若初裝時尚未連通,可先用 type: file 指向隨客戶端分發的本地檔案過渡。

詳圖 B-09覆寫與合併:讓手動修改在訂閱更新後存活

問題與原則

直接編輯訂閱生成的設定檔,是新手最常踩的維護陷阱:下一次訂閱更新會把整份檔案重新生成,所有手動修改隨之丟失。正確做法是一條紀律——訂閱原文不動,修改一律放在「覆寫層」:客戶端在每次載入設定時,把覆寫內容與訂閱原文合併後再交給核心,訂閱怎麼更新都不影響你的客製化。

各客戶端的覆寫入口

主流客戶端都提供了這一機制,叫法不同、思路一致:Clash Verge Rev 提供「全域擴充設定」,分 Merge(宣告式合併)與 Script(腳本改寫)兩種;Clash Plus 提供設定覆寫入口;FlClash 支援設定疊加。入口位置與欄位名稱隨客戶端演進,以客戶端內的說明為準。以 Merge 寫法為例,在訂閱規則最前面插入兩條自訂規則、同時覆蓋 DNS 段:

prepend-rules:
  - DOMAIN-SUFFIX,intra.example.com,DIRECT
  - PROCESS-NAME,Steam.exe,DIRECT

dns:
  enable: true
  enhanced-mode: fake-ip

prepend- 前綴表示插到訂閱同名陣列之前(優先順序最高),append- 表示追加到末尾;直接寫頂層鍵(如上例 dns)則整段替換訂閱裡的對應段。自訂規則絕大多數場景用 prepend——規則匹配命中即停,插在最前面才能保證優先生效。

修改後的驗收流程

每次修改覆寫內容,按固定流程驗收:儲存覆寫 → 在客戶端重新載入設定 → 確認日誌無載入錯誤 → 用下面的指令驗證代理連接埠是否正常轉發 → 在連線面板存取一次目標網站,確認命中的規則與出口符合預期。指令傳回 HTTP/2 204 或 204 No Content 即連線正常:

curl -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204 -I

詳圖 B-10載入報錯對照:從提示文字定位到具體行

設定改錯之後,核心會拒絕載入並在日誌裡留下一行提示。這些提示的措辭在不同客戶端裡略有出入,但類別是固定的,讀懂類別就能直接定位到出錯的欄位,不必逐行通讀整份檔案。下表把最常見的幾類提示與真實原因對應起來,排查時先按提示歸類,再回到對應詳圖核對寫法。

一條通用的二分定位法

如果提示只給了模糊的行號,而那一行看起來沒有問題,通常是上一段的結構沒有正常閉合,把錯誤「推」到了下一行。此時用二分法最省時間:先把 rules 段整段註解掉重新載入,能載入說明問題在規則;不能載入再註解 proxy-groups,依次向上收縮範圍,直到定位到具體段落,然後在段落內部再對半註解。YAML 註解是行首加 #,批次註解在任何文字編輯器裡都能一次完成,幾輪之內必定收斂到出錯的那幾行。

還有一類「不報錯但不生效」的情況更容易耗時間:核心載入成功、日誌乾淨,行為卻不對。這類問題的根因往往不在語法,而在語意——規則被上面某條更寬的規則提前命中、規則集的 behavior 與檔案內容不匹配、或者覆寫層解析失敗被靜默回退。判斷方法統一是把 log-level 調到 debug,存取一次目標網站,看日誌裡這條連線實際命中了哪條規則、走了哪個出口,一次就能把「猜」變成「看」。若連日誌都沒有該域名的紀錄,說明流量根本沒進核心,應回到系統代理不生效排查文先解決入口問題。

詳圖 B-11備份、版本與長期維護紀律

備份該備份什麼

需要長期保存的其實只有三樣:一是訂閱連結本身(丟了要重新去服務商面板取),二是你寫的覆寫層內容(這是唯一無法自動恢復的手動資產),三是自訂規則集的本地檔案(如果用了 type: file)。訂閱生成的 config.yaml 本體不必備份——它隨時可以重新抓取,備份反而容易造成「編輯了備份檔案卻在納悶為什麼沒生效」的混亂。把這三樣放進一個純文字目錄,重裝系統或換機器時,新裝客戶端 → 填回訂閱 → 貼回覆寫層,幾分鐘即可完全恢復。

用註解代替記憶

覆寫層裡每加一條自訂規則,順手在上一行寫一句註解,說明「為什麼加」和「什麼時候可以刪」。半年之後回看,沒有註解的規則你既不敢刪也想不起用途,只能一直帶著;有註解的規則則可以定期清理。註解的成本是一行字,收益是設定檔不會隨時間膨脹成不可維護的歷史包袱:

prepend-rules:
  # 公司內網 OA,必須直連,離職後可刪
  - DOMAIN-SUFFIX,intra.example.com,DIRECT
  # Steam 下載走直連以跑滿頻寬,2026-07 新增
  - PROCESS-NAME,Steam.exe,DIRECT

三個需要定期回看的點

其一,規則集的 interval 與 path:多個規則集共用同一個 path 會互相覆蓋,新增規則集時容易複製貼上出錯,值得每次新增後確認一遍。其二,策略組成員:訂閱節點更名後,手動寫在覆寫層裡的節點名可能已經失效,表現為組裡少了成員或載入報 proxy not found。其三,核心與客戶端版本:新欄位在舊核心上會被判為無法識別,升級客戶端後再啟用新欄位更穩妥,各客戶端的更新節奏與差異見客戶端對比頁,安裝包統一從安裝包頁取得。

什麼時候該重建而不是繼續修

當一份設定被反覆手動修改到自己都說不清哪些欄位還在起作用時,重建比繼續修更快:刪掉舊設定,重新抓取訂閱得到乾淨原文,把覆寫層裡確認還需要的規則挑出來重貼一遍,其餘全部丟棄。以詳圖 B-02 的最小骨架為參照,五個部分齊備就能跑;在此之上按需逐段添加,每加一段重新載入一次,任何一處出錯都能立刻定位。這條路看似繞遠,實際比在一份混亂檔案裡排查省時間得多。

詳圖 B-12常見場景的欄位組合

本節把前面各段的欄位組合成幾套完整可用的寫法,涵蓋日常最高頻的四類需求。每套都寫在覆寫層裡,訂閱更新不受影響;直接複製後按註解替換自己的域名與行程名即可。

場景一:某個網站必須直連

公司內網系統、銀行、政務網站這類只認當地出口的服務,走代理會被拒絕或反覆驗證。用 DOMAIN-SUFFIX 指向 DIRECT,並放在 prepend 段確保優先於訂閱自帶的任何規則:

prepend-rules:
  - DOMAIN-SUFFIX,intra.example.com,DIRECT
  - DOMAIN-SUFFIX,example-bank.com,DIRECT

場景二:某個程式整體走直連或走代理

桌面端可以按行程名分流,適合遊戲下載器、大檔案同步工具這類不需要代理卻會跑滿頻寬的程式。行程名要寫系統裡的實際執行檔名稱,Windows 含 .exe 後綴,macOS 與 Linux 一般不含;名稱可以在客戶端的連線面板裡直接看到:

prepend-rules:
  - PROCESS-NAME,Steam.exe,DIRECT
  - PROCESS-NAME,Docker Desktop.exe,節點選擇

場景三:封鎖廣告與追蹤域名

把不想連線的域名指向 REJECT,核心會直接拒絕該連線。少量域名可以手寫;成規模的名單應交給規則集,由 rule-providers 自動更新,避免手動維護上千行:

prepend-rules:
  - DOMAIN-KEYWORD,doubleclick,REJECT
  - DOMAIN-SUFFIX,ads.example.com,REJECT

場景四:分地區出口

串流影音、AI 服務等按地區提供內容的網站,需要固定走某個地區的節點。做法是先建一個只含該地區節點的 select 或 url-test 組,再把對應域名指向這個組;這樣節點增減時只維護組成員,規則不動:

prepend-proxy-groups:
  - name: "日本出口"
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - "日本-01"
      - "日本-02"

prepend-rules:
  - DOMAIN-SUFFIX,example-stream.jp,日本出口

四套組合都遵循同一個套路:確定「哪些流量」(域名、行程、IP 段)、確定「去哪個出口」(內建出口或策略組)、放在 prepend 段保證優先順序。理解了這三步,任何新需求都能自己拼出來,不必等現成設定。規則之間的匹配演算與更複雜的國內外分流方案,見規則分流設定實戰。

至此,config.yaml 的主要欄位均已收錄。本頁未涵蓋的具體故障現象,查 常見問題頁按分類檢索;拿不準該用哪個客戶端承載這份設定,見客戶端對比頁的選型結論;尚未安裝客戶端的讀者,前往安裝包頁按平台取得,各平台首推 Clash Plus。