Clash 設定檔是什麼：Profile 結構入門與多設定檔管理

Clash Profile 到底儲存了什麼

Clash 用戶端中的 Profile 通常翻譯為「設定」或「設定檔」。它不只是單純的節點清單，而是一份描述代理核心如何監聽連接埠、解析 DNS、整理節點、建立策略群組並比對流量規則的結構化文件。經典 Clash、Clash Meta 以及後續的 mihomo 核心主要使用 YAML 格式，但不同圖形化用戶端也可能在 YAML 之外儲存已選策略、訂閱更新時間與介面偏好設定。

一份可以啟動的基本設定通常包含監聽連接埠、執行模式、代理節點、策略群組與規則。使用 mihomo 時，還可能包含 TUN、sniffer、rule-providers、proxy-providers 等擴充欄位。用戶端讀取 Profile 後會解析 YAML，再將有效內容交給核心程序；縮排錯誤、欄位型別不符，或引用不存在的策略群組，都可能使載入程序中止。

常見欄位	作用	典型內容
`mixed-port`	提供 HTTP 與 SOCKS 混合代理入口	`7890`
`mode`	決定流量依規則、全域代理或直連處理	`rule`
`proxies`	儲存靜態代理節點定義	節點名稱、伺服器、連接埠與通訊協定參數
`proxy-groups`	組織手動選擇、自動測速與故障轉移策略	`select`、`url-test`、`fallback`
`rules`	由上到下比對網域、IP、程序或規則集	`DOMAIN-SUFFIX`、`IP-CIDR`、`MATCH`
`dns`	控制 DNS 監聽、上游伺服器與解析模式	`fake-ip` 或 `redir-host`

以下精簡範例展示欄位之間的引用關係。規則最後一欄必須指向既有的策略群組，例如規則中的「節點選擇」必須與 proxy-groups 中的名稱完全一致，包括空格與大小寫。

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: "節點 A"
    type: socks5
    server: 192.0.2.10
    port: 1080

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

rules:
  - DOMAIN-SUFFIX,example.com,節點選擇
  - MATCH,DIRECT

訂閱設定與本機設定檔的差異

訂閱設定透過遠端 URL 取得。用戶端向該網址發出 HTTP 請求，伺服器回傳 Clash YAML，用戶端再儲存為本機副本並載入。訂閱連結本身等同於存取憑證，複製到記錄檔、截圖或公開儲存庫，都可能造成帳戶資訊外洩。日常管理時應將它當作密碼處理。

本機設定則是使用者直接匯入或編輯的 YAML 檔案。它不會因為點選「更新訂閱」而自動變更，適合保存自建節點、固定規則、除錯設定與離線環境。兩者最後都必須成為核心可讀取的 YAML，但來源、更新方式與覆寫行為不同。

比較項目	訂閱設定	本機設定
內容來源	遠端訂閱服務回傳	本機檔案或手動編輯
更新方式	依週期或手動重新請求 URL	直接修改檔案後重新載入
遠端覆寫	更新時通常會替換下載副本	不受訂閱更新影響
適用情境	節點經常變動、由伺服器統一維護	固定規則、實驗設定、自建服務

為什麼直接修改訂閱 YAML 容易遺失

許多用戶端允許開啟目前訂閱的快取檔案並編輯，但下次更新時會重新下載整份文件，手動加入的規則、DNS 參數或策略群組因此被覆寫。即使用戶端保留舊檔案，新 Profile 也可能取得另一個內部識別碼，導致修改內容不再被使用。

需要長期保留自訂內容時，優先使用用戶端提供的覆寫、腳本或合併功能。不同用戶端的選單名稱並不一致，常見入口包括「設定」→「覆寫」、「Profiles」→「Merge」，或設定卡片右側的編輯選單。使用 mihomo 的用戶端也可能支援覆寫 DNS、規則與 TUN 欄位。啟用前應確認合併順序：後寫入的同名純量通常會覆蓋前值，而陣列是替換還是追加，則取決於用戶端實作。

更新與切換實際發生了什麼

手動更新與自動更新

點選設定卡片上的更新按鈕後，用戶端通常會依照「請求訂閱網址、檢查回應、寫入暫存檔、解析 YAML、替換舊快取、通知核心重新載入」的順序運作。HTTP 請求成功並不代表設定一定可用：若回傳登入頁面、錯誤提示或格式不完整的 YAML，狀態碼可能仍是 200，但解析階段會失敗。

自動更新只是定時執行相同流程。常見間隔為 6、12 或 24 小時；部分用戶端會讀取訂閱回應中的更新間隔，部分則使用「設定」→「設定」或「Profiles」頁面設定的固定週期。筆記型電腦在睡眠期間通常不會執行工作，喚醒後是否立即補充更新，取決於用戶端的排程邏輯。

更新前記下目前的 Profile 名稱與已選策略群組，避免更新後難以確認變更來源。
確認系統時間正確。系統時間偏差過大，可能導致 HTTPS 憑證驗證失敗。
更新後檢查節點數量、策略群組名稱與最後更新時間，不要只看「請求成功」。
開啟核心記錄，確認沒有 yaml、parse 或 proxy group 等錯誤。
使用一般 HTTPS 頁面驗證規則是否命中，再測試需要代理的目標，不要只依賴延遲數字。

切換 Profile 不等於只更換節點

在設定清單中選擇另一份 Profile 後，用戶端會讓核心重新載入整份設定。監聽連接埠可能從 7890 變成 7897，DNS 模式可能從 fake-ip 變成 redir-host，TUN 開關、路由規則與策略群組也可能同時變更。因此，切換後若出現「瀏覽器可以存取，但終端機無法連線」或「系統代理仍指向舊連接埠」，應先核對連接埠與接管模式。

系統代理只是作業系統中的代理位址設定。例如 Profile 使用 mixed-port: 7890 時，用戶端通常會將系統 HTTP 與 HTTPS 代理指向 127.0.0.1:7890。如果新設定改為 7891，但圖形化用戶端沒有同步重新整理系統代理，應用程式仍會連線至舊連接埠。可先關閉再開啟系統代理，讓用戶端重新寫入位址。

TUN 模式的影響範圍更大。mihomo 會建立虛擬網路介面，並接管符合路由條件的流量；DNS 劫持、嚴格路由與自動路由參數，都來自目前的設定或用戶端覆寫。切換 Profile 後，應在「設定」→「網路」或「設定」→「TUN 模式」檢查狀態；macOS 也可能要求重新確認網路延伸功能或管理員權限。

多設定檔並存的命名與分組方法

同時使用多個訂閱時，最常見的問題不是設定檔數量，而是名稱失去辨識度。只使用「服務 A」、「備用」或自動產生的隨機檔名，幾個月後很難判斷設定用途、來源與更新策略。名稱應描述用途，而不是描述當下的臨時狀態。

建議採用四段式名稱

用途-來源-平台-更新方式

工作-服務A-macOS-自動12h
個人-服務B-全平台-手動
測試-本機規則-mihomo-固定
緊急-服務C-iOS-自動24h

「用途」用於區分工作、個人、測試或緊急；「來源」只填寫方便辨識的簡稱，不要把完整訂閱網址放進名稱；「平台」標示是否包含特定系統規則；「更新方式」提示這份設定是否會自行變更。用戶端名稱長度有限時，可以縮短為 Work-A-Mac-12h，但應讓所有設定檔維持相同順序。

不要把所有節點塞進同一份檔案

將多個來源合併成一份大型 YAML 看似方便，實際上會帶來重複命名、規則覆蓋與更新困難。兩個訂閱都可能包含「自動選擇」、「香港節點」等同名項目；若合併工具沒有穩定的重新命名規則，策略群組可能會引用錯誤節點。設定達到數百個節點後，測速請求也會在短時間內建立大量連線。

更清楚的做法是保留獨立的 Profile，需要跨來源選擇時再使用 proxy-providers。mihomo 的 provider 可以從多個遠端檔案載入節點，並在主要設定中透過 use 引用。如此一來，主要設定負責規則與策略，節點來源則可獨立更新。

proxy-providers:
  provider-a:
    type: http
    url: "https://subscription.example/provider-a.yaml"
    path: ./providers/provider-a.yaml
    interval: 43200
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: "自動選擇"
    type: url-test
    use:
      - provider-a
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

範例中的 interval: 43200 表示每 12 小時更新一次 provider，健康檢查每 600 秒執行，策略群組每 300 秒重新評估延遲。實際間隔不宜設得過短；節點較多時，每 60 秒進行一次完整測試會增加連線數與耗電量。行動裝置可將策略評估調整為 600 至 1800 秒。

備份與復原應保留哪些內容

設定備份的目的不是複製整個應用程式目錄，而是保存足以重建執行環境的必要資料。不同用戶端的目錄結構與資料庫格式會隨版本變化，直接覆蓋應用程式資料目錄可能將舊版狀態帶入新版。更可靠的做法是同時保留可讀的 YAML、訂閱來源說明與重要設定記錄。

建議備份的五類資料

本機 YAML：包括手寫的主要設定、覆寫檔案、自訂規則與 provider 定義。
訂閱清單：記錄服務名稱、用途與更新週期；訂閱 URL 應儲存在受保護的密碼管理工具中。
用戶端設定：記錄系統代理、TUN、開機啟動、允許區域網路連線與連接埠設定。
版本資訊：記錄圖形化用戶端版本與核心版本，例如用戶端 2.0.0、mihomo v1.19.x，方便重現欄位相容性。
復原說明：寫明匯入順序、預設 Profile、常用策略群組與必要的系統授權步驟。

備份檔案可以依日期歸檔，例如 clash-profile-backup-2026-07-09。每次大幅修改 DNS、TUN 或規則前，先保存一個版本，並在檔名中加入用途，例如 work-mac-before-tun-change.yaml。YAML 本身適合使用 Git 記錄差異，但包含訂閱網址、驗證參數或私人伺服器資訊的檔案，只應存放在存取受控的私有儲存庫中。

復原時不要一次開啟所有功能

安裝與原環境相容的用戶端版本，先保持系統代理與 TUN 關閉。
匯入 YAML，檢查核心能否啟動，並確認記錄中沒有欄位解析錯誤。
手動選擇一個可用節點，使用 127.0.0.1:7890 測試本機代理連接埠。
開啟系統代理，驗證遵循系統代理的瀏覽器與應用程式。
最後開啟 TUN，檢查 DNS、區域網路存取，以及睡眠喚醒後的網路狀態。

分階段復原可以釐清問題屬於 Profile、節點、系統代理還是 TUN。若匯入後立即開啟所有功能，一旦網路中斷，記錄中會同時出現 DNS、路由與連線錯誤，很難判斷最初的失敗點。

常見 Profile 問題與定位方法

設定已更新，但節點清單沒有變化

先確認更新的是目前啟用的 Profile，而不是名稱相近的另一份設定。接著查看更新時間與訂閱回應內容。如果遠端確實回傳新節點，但介面仍顯示舊清單，可以切換到其他 Profile 再切回，或重新啟動核心以觸發重新載入。仍未變化時，檢查用戶端是否啟用了固定覆寫或 provider 快取。

匯入 YAML 後顯示解析失敗

YAML 使用空格表示層級，不能依賴 Tab 縮排。請重點檢查清單項目前的短橫線、冒號後的空格、包含特殊字元的節點名稱，以及重複欄位。若錯誤記錄提供行號，應從該行向上檢查完整區塊，因為真正的縮排問題經常發生在前幾行。

# 正確：proxies 是陣列
proxies:
  - name: "節點 A"
    type: socks5

# 錯誤：清單項目與欄位層級不一致
proxies:
 - name: "節點 A"
    type: socks5

切換設定後所有網站都變成直連

檢查 mode 是否為 direct，規則末尾是否寫成 MATCH,DIRECT，以及目標網域是否命中直連規則。mihomo 記錄會顯示連線目標、命中規則與最終策略。若記錄完全沒有新的連線，問題通常出在系統代理、應用程式代理設定或 TUN 接管，而不是規則本身。

策略群組選擇每次重新啟動都會還原

經典設定欄位 profile.store-selected: true 可讓支援該欄位的核心保存策略群組選擇；mihomo 也支援與 Profile 持久化相關的設定。不過圖形化用戶端可能會接管這部分狀態，或在每次更新時產生新的設定識別碼。除了啟用持久化，也應保持策略群組名稱穩定，避免訂閱轉換時自動加入日期或節點數量。

profile:
  store-selected: true
  store-fake-ip: true

新手管理流程：從一份設定開始

剛開始使用時，不必立即合併多個訂閱或撰寫複雜規則。先保留一份主要訂閱，確認更新、切換節點、系統代理與記錄檢視都能正常運作。第二份設定只作為緊急來源，並使用明確名稱加以區分。等到確實需要跨來源選擇節點時，再導入 provider 或覆寫機制。

日常操作可以固定成一套簡短流程：每週檢查一次訂閱更新時間；設定更新後確認節點數量與策略群組；修改規則前複製本機 YAML；切換 Profile 後檢查連接埠與接管模式；用戶端升級後記錄核心版本。如此可將「突然無法連線」拆解成幾個可驗證的環節，而不是反覆刪除再重新匯入。

Profile 管理的關鍵在於區分三層內容：遠端維護的訂閱、本機長期保留的規則，以及用戶端記錄的執行狀態。訂閱負責提供持續變動的節點，本機設定負責表達穩定的路由意圖，用戶端狀態負責記住目前的選擇。三者分開管理後，多設定檔並存、自動更新與裝置遷移都更容易控管。