Clash Profile 是什麼:設定檔基礎概念與多重設定檔切換管理入門
Profile 是 Clash 客戶端載入的完整設定單元,與訂閱、節點、規則屬於包含關係。本文說明設定檔的來源、存放位置、更新機制,以及多組設定並存時的切換與管理方式。
Profile 到底是什麼:一份 YAML,裝了四類東西
在 Clash 及其衍生核心(Clash Premium、Clash Meta、mihomo)的語境裡,Profile(設定檔)指的是客戶端實際載入並生效的那一份完整 YAML 檔案。它不是「訂閱」的同義詞,也不是「節點列表」的同義詞——訂閱只是取得設定檔的一種管道,節點只是設定檔裡的一段內容。先弄清楚這層包含關係,後面談到存放位置、更新邏輯、多重設定切換時才不會混著講。
一份典型的 Clash 設定檔通常依序包含以下幾段:
- 通用執行參數:連接埠(port / socks-port)、區域網路存取開關(allow-lan)、執行模式(mode: rule / global / direct)、記錄層級(log-level)、外部控制器位址(external-controller)等,決定客戶端啟動後的基礎行為。
- DNS 設定段:是否啟用內建 DNS、上游伺服器位址、是否使用 fake-ip 模式、是否針對特定網域使用 DoH/DoT,直接影響網域解析速度與分流準確性。
- proxies 節點列表:每一個代理伺服器的連線參數——協定類型(如 Shadowsocks、VMess、Trojan、Hysteria2)、伺服器位址、連接埠、加密方式與金鑰等。這是「能不能連上」的基礎。
- proxy-groups 策略群組:把 proxies 裡的節點依用途分類,定義選擇方式(select 手動選擇、url-test 自動測速切換、fallback 故障轉移、load-balance 負載平衡),這是「怎麼用節點」的邏輯層。
- rules 規則段:依網域、IP 範圍、GEOIP、程序名稱等條件,把流量比對到某個策略群組或直連/攔截,這是「什麼流量走哪條路」的調度層。
這五段合在一起,才構成一份完整可用的 Profile。少了 proxies 段,策略群組無從選擇;少了 rules 段,客戶端只能依 mode 裡的全域預設行為處理所有流量,談不上「分流」。
注意 NOTICE
訂閱連結所回傳的內容本質上也是一份 Profile(或是可以被客戶端解析、補齊成 Profile 的節點資料),客戶端會把它儲存為本地檔案後才載入。換句話說,訂閱是「設定檔的一種自動化來源」,並不是脫離設定檔獨立存在的實體。
設定檔的三種來源:訂閱、本地匯入、手動編寫
依取得方式,Profile 大致可分三類,日常使用中經常混用:
1. 訂閱連結自動產生
這是最常見的方式。服務方提供一個 HTTP(S) 連結,客戶端請求該連結後,伺服端回傳節點資訊(有的直接是完整 YAML,有的是 Base64 編碼的節點列表)。多數 Clash 系客戶端(Clash Verge、FlClash、ClashX Meta 等)會在取得節點資料後,結合內建或自訂的規則範本,拼裝成一份完整可用的 Profile,再儲存到本地。這也是為什麼同一條訂閱連結,在不同客戶端匯入後,策略群組結構、規則數量可能不完全一樣——拼裝範本不同。
2. 匯入本地檔案
如果已經有別人分享的或自己整理的 YAML 檔案,可以透過客戶端的「從檔案匯入」功能直接載入,不須經過網路請求。這類 Profile 不會自動更新,內容完全固定,適合除錯與離線場景。
3. 手動編寫/線上編輯器修改
進階使用者會直接用文字編輯器或客戶端內建的設定編輯面板,手寫或修改 proxy-groups、rules 段,常見場景包括:替某個策略群組加入自訂節點、替某類 App 單獨指定出口、封鎖特定網域。這類修改建議先備份原始檔案,避免語法出錯導致客戶端載入失敗後無法還原。
設定檔存放在哪:不同客戶端的路徑差異
Profile 是本地檔案,具體存放路徑因客戶端而異,排查問題時經常需要手動到目錄裡確認檔案是否真的更新了。常見客戶端的大致存放規律如下:
| 客戶端 | 設定檔存放規律 | 說明 |
|---|---|---|
| Clash Verge / Clash Verge Rev | 應用程式資料目錄下的 profiles 資料夾,每個訂閱對應一個以雜湊值/UUID 命名的 .yaml 檔案 | 由 config.yaml 記錄目前啟用的是哪一份 |
| ClashX Meta(macOS) | 使用者目錄下的 .config/clash/ 資料夾 | 可直接用終端機或編輯器開啟對應檔案 |
| FlClash(跨平台) | 應用程式私有資料目錄內的 profile 子目錄 | 行動端一般不建議直接改檔案,走內建編輯面板更安全 |
| 純核心(mihomo/Clash Meta core) | 啟動參數 -f 指定的路徑,預設讀取目前目錄下的 config.yaml | 沒有 GUI 包裝,路徑完全由啟動方式決定 |
需要強調的是,大多數圖形化客戶端並不建議使用者直接到應用程式資料目錄裡手動修改這些自動產生的檔案——因為客戶端自身的更新邏輯可能會在下次刷新時把手動修改的內容覆蓋掉。如果確實需要長期保留自訂規則,更穩妥的做法是使用客戶端提供的「合併設定」或「覆寫(override)」功能,把自訂片段單獨存放,再疊加到訂閱產生的主設定之上。
設定檔怎麼更新:自動刷新與手動更新的差異
只有透過訂閱連結取得的 Profile 才具備「更新」這個動作,本地匯入或手寫的檔案不會自己變化。更新機制主要看兩個欄位:
- update-interval:部分客戶端會在訂閱資訊裡記錄這個值(單位通常是分鐘),達到時間間隔後自動向訂閱連結重新請求一次,取得最新節點後覆蓋舊檔案對應的 proxies 段。
- 手動更新按鈕:客戶端訂閱管理介面通常都有一個「更新」或刷新圖示,點擊後立即觸發一次請求,不受 update-interval 限制,常用於服務方剛更換節點、需要立刻同步的場景。
更新時客戶端一般只替換節點相關內容,不會動到使用者在本地額外新增的自訂規則(前提是用了「合併/覆寫」機制,而不是直接改了自動產生的檔案本體)。如果發現更新後自訂的分流規則消失了,大概率是因為改動寫在了會被覆蓋的主檔案裡,應該改用覆寫功能重新設定。
注意 NOTICE
訂閱更新依賴網路請求成功。如果客戶端顯示更新失敗,先確認訂閱連結本身能否正常存取,再檢查是否觸發了伺服端的請求頻率限制,這兩類問題比軟體本身故障更常見。
多個設定檔如何切換與管理
大多數使用者不會只用一份設定——比如同時訂閱了兩個服務商,或者本地儲存了一份用於串流媒體分流的客製版本、一份用於日常上網的精簡版本。這種情況下,設定檔的「切換」和「管理」就成了日常操作裡繞不開的一環。
切換邏輯:同一時刻只有一份處於啟用狀態
客戶端核心在運行時只會載入一份 Profile。圖形介面上看到的「設定清單」本質上是多份已儲存的 YAML 檔案,點擊某一項即把它設為目前啟用的設定,客戶端會重新讀取核心並套用新的 proxies、proxy-groups、rules。切換過程通常伴隨短暫的連線中斷,是正常現象。
命名與分類建議
設定數量一多,靠預設產生的檔名很難分清用途,建議在客戶端裡替每份設定重新命名,標註清楚來源與用途,例如區分「日常訂閱」「臨時測試」「本地自訂規則」等類別,減少切錯設定的機率。部分客戶端支援替設定加上標籤或分組,可以依場景歸類管理。
合併與覆寫:不切換也能疊加規則
如果只是想在現有訂閱基礎上加幾條自訂規則(比如把某個內部服務網域強制直連),不必新建一份完整設定,更推薦使用客戶端的「覆寫(override)」或「合併設定」功能。這類功能允許單獨維護一小段 YAML 片段(通常只包含要新增或取代的規則),套用時疊加在主設定之上,主設定更新後覆寫片段依然保留,不需要重複新增。
刪除與清理
長期不用的測試設定建議及時刪除,尤其是包含真實節點憑證的檔案——即便訂閱已經失效,檔案裡的金鑰資訊仍然是明文儲存在本地的,清理舊設定也是基本的使用衛生習慣之一。
常見疑問快速對照
| 疑問 | 結論 |
|---|---|
| Profile 和訂閱是一回事嗎 | 不是,訂閱是取得 Profile 的一種管道,Profile 是最終生效的完整設定檔 |
| 手動修改設定檔會不會被下次更新覆蓋 | 直接改自動產生的主檔案會被覆蓋,建議用覆寫/合併功能單獨保存自訂內容 |
| 多份設定能同時生效嗎 | 核心同一時刻只載入一份,多重設定靠切換而非同時疊加(疊加靠覆寫機制) |
| 本地匯入的檔案會自動更新嗎 | 不會,只有綁定了訂閱連結的設定才具備自動/手動更新能力 |
把這幾點理清之後,再去看客戶端介面上的「設定管理」「訂閱資訊」「覆寫」這些標籤,就能對應到本文講的儲存、更新、疊加三套機制,不容易再把 Profile、訂閱、節點、規則這幾個概念混著用。