Clash 設定檔(Profile)結構解析:欄位含義與多訂閱管理方法
拆解 Profile 的核心欄位:連接埠、代理群組、規則段各自負責什麼,訂閱更新時哪些內容會被覆蓋;並說明多個設定檔如何切換、去重與備份,避免改動被更新沖掉。
Profile 到底是什麼
在 Clash 生態裡,「設定檔」(Profile)指的是一份 YAML 格式的文本,裡面記錄了本地連接埠、出站節點清單、代理群組的分組邏輯,以及一整套分流規則。用戶端介面上看到的策略群組、延遲測速、規則比對結果,歸根結底都是這份 YAML 被解析後渲染出來的。無論是手動填寫一個訂閱連結,還是匯入本地檔案,用戶端做的事情本質上都是把遠端或本地的這份文本抓取下來、校驗格式、再交給核心(Clash Premium 或 mihomo)載入運行。
理解 Profile 的結構,好處不只是排查故障更快,更重要的是能判斷「哪些改動是安全的、哪些改動會在下次刷新訂閱時被沖掉」。這是本文要講清楚的核心問題。
欄位拆解:一份 Profile 裡都寫了什麼
一份完整的 Profile 大致可以分成四個區塊,順序不強制,但用戶端介面通常按下面的邏輯分組展示。
1. 基礎運行參數
這部分決定核心監聽哪些連接埠、以什麼模式工作,常見欄位包括:
| 欄位 | 作用 |
|---|---|
| port | HTTP 代理監聽連接埠 |
| socks-port | SOCKS5 代理監聽連接埠 |
| mixed-port | HTTP 與 SOCKS5 合用的混合連接埠,多數用戶端預設啟用這個而不是分開兩個連接埠 |
| allow-lan | 是否允許區域網路內其他裝置接入該代理 |
| mode | 運行模式,取值 rule / global / direct |
| log-level | 日誌詳細程度,排查問題時通常臨時調到 debug |
| external-controller | RESTful API 監聽位址,用戶端圖形介面透過它讀取運行狀態 |
這些欄位大多有預設值,用戶端圖形介面裡的「連接埠設定」「混合連接埠」「區域網路連線」等開關,改的其實就是這一區塊的內容。
2. proxies:節點清單
proxies 是一個陣列,每一項描述一個出站節點,常見欄位有 name(節點顯示名稱)、type(協定類型,如 ss、vmess、trojan、hysteria2)、server、port,以及協定特有的加密方式、UUID、密碼等參數。這一段幾乎從不需要手動編輯——它由訂閱服務商產生,你要做的是確保訂閱連結本身有效。
3. proxy-groups:策略群組
proxy-groups 決定節點如何被「打包」成一個可選擇的分組,每一項常見欄位:
- name:分組名稱,規則段會引用這個名稱
- type:分組類型,常見的有 select(手動選擇)、url-test(自動測速切換)、fallback(失敗自動切換)、load-balance(負載平衡)
- proxies:該分組包含哪些節點或其他分組的名稱
- url / interval:url-test 與 fallback 類型使用,指定測速位址與檢測間隔(秒)
用戶端介面上那一排排「選擇節點」的下拉清單,對應的就是這裡每一項 select 類型的分組。
4. rules:分流規則
rules 是一個從上到下依序匹配的清單,格式通常是 類型,匹配內容,目標策略。常見類型包括 DOMAIN-SUFFIX(網域名稱後綴匹配)、DOMAIN-KEYWORD(網域名稱關鍵字)、IP-CIDR(IP 段匹配)、GEOIP(按地理位置資料庫判斷)、RULE-SET(引用外部規則集合)。最後一般會有一條 MATCH,策略名 作為兜底,凡是前面規則都沒命中的流量,統一交給這條規則處理。規則清單越靠前優先級越高,一旦某條命中,後面的規則不再繼續判斷。
補充說明
較新的 Clash Meta(mihomo)核心還支援 rule-providers 欄位,用來聲明外部規則集(比如按網域名稱分類打包好的規則檔案),規則段裡透過 RULE-SET,規則集名稱,策略 引用,這樣規則檔案可以獨立更新,不用把數千條網域名稱硬編碼進主設定裡。
訂閱更新時,哪些內容會被覆蓋
這是最容易踩坑的地方。訂閱連結指向的是服務商託管的一份完整 YAML,用戶端「更新訂閱」這個動作,本質是重新下載這份檔案並整體取代本地快取。也就是說,proxies(節點清單)、proxy-groups(策略群組結構)、rules(規則清單)這三塊內容,只要訂閱服務商的原始檔案裡有,更新後就會被整體覆蓋為服務商提供的最新版本——你手動加的自訂規則、調整過的分組順序,大概率都會隨之消失。
而連接埠、區域網路開關、模式這類基礎運行參數,情況因用戶端而不同:多數圖形用戶端會把這些參數單獨存成一份「運行時覆蓋」,不寫回訂閱檔案本身,所以刷新訂閱通常不影響連接埠設定;但如果你是直接編輯本地 YAML 檔案、再把它當作「本地設定」匯入使用,而不是走訂閱連結刷新機制,那就完全沒有覆蓋問題——因為根本不存在「重新下載」這個動作。
需要特別注意的一種情況是:部分訂閱服務商支援在產生連結時附加參數,插入自訂規則或強制指定某些分組,這類內容同樣會在每次更新時被重新寫入,和你本地的修改無法共存。判斷的關鍵只有一句話:只要內容來自「下載」而不是「手動輸入」,它就會在下次更新時被重新下載覆蓋。
多個設定檔如何管理:切換、去重與備份
大部分圖形用戶端(Clash Verge Rev、FlClash、ClashX Meta 等)都支援同時保存多份 Profile,透過介面上的清單在不同訂閱或本地檔案之間切換,互不影響。管理多份設定時建議遵循以下幾個原則。
按用途分開保存,而不是反覆改同一份
如果你同時使用多個訂閱服務商,或者一份用於日常、一份用於測試新節點,應該把它們作為獨立的 Profile 分別保存,而不是在同一份檔案裡來回貼上取代。這樣切換時只需要在用戶端清單裡點選,不涉及任何文本編輯,出錯機率最低。
本地覆寫規則,避免被訂閱更新沖掉
如果確實需要長期保留一些自訂規則(比如給某個內部服務加白名單直連),更穩妥的做法是使用用戶端提供的「覆寫」或「合併」功能——大多數現代用戶端支援在訂閱之外單獨維護一份本地覆寫檔案,更新訂閱時只取代服務商原始內容,本地覆寫部分保持獨立,不會被一起沖掉。如果用戶端沒有這個功能,退一步的辦法是每次更新前手動備份目前生效的 YAML,更新後再把自訂規則段落貼回去。
定期清理重複與失效節點
長期使用同一個訂閱帳號,時間久了容易出現節點清單冗餘、部分節點已下線但仍留在分組裡的情況。養成定期檢查的習慣:
- 開啟目前生效的 Profile,查看 proxies 數量是否與訂閱商後台顯示的節點數一致
- 對 url-test 類型分組做一次手動測速,剔除長期不可用的節點(部分用戶端支援在介面直接移出分組)
- 確認 proxy-groups 裡沒有重複引用同一節點導致的分組混亂
備份的最小可用集合
如果需要遷移到新裝置或重新安裝用戶端,只要保留以下兩類內容,基本就能完整還原此前的使用狀態:訂閱連結本身(用於隨時重新拉取最新節點與規則),以及本地覆寫或自訂規則檔案(如果有)。不需要額外備份用戶端快取的臨時檔案,那些內容下次拉取訂閱時會自動重新產生。
注意
不要把包含節點密碼、UUID 等敏感資訊的 Profile 檔案上傳到公開儲存庫或分享給不信任的第三方,訂閱連結本身也應當視為敏感資訊保管,洩露後建議第一時間在服務商後台重設。
常見排查場景與對應欄位
結合前面講的欄位劃分,幾類常見問題基本都能對應到具體區塊去定位:
- 連不上網、代理無法生效:先檢查基礎運行參數區塊的連接埠設定和 mode 是否為預期值
- 某個網站走了不該走的節點:回到 rules 區塊,依序檢查是否有更靠前的規則提前命中,規則清單是自上而下短路匹配的
- 切換節點後不生效:確認對應 proxy-groups 的 type 是否為 select,並確認用戶端介面選中的分組和規則裡引用的分組名稱一致
- 更新訂閱後自訂規則消失:這屬於本文第三部分講的覆蓋機制,是預期行為,需要改用本地覆寫方式保存自訂內容
把 Profile 當作一份結構化的設定說明去理解,而不是一堆看不懂的 YAML 文本,大多數排查工作會明顯變得有據可依。遇到介面上某個開關的效果和預期不一致時,回頭看它對應的欄位值,通常比反覆重新安裝用戶端更有效。