Clash Profile 設定檔基礎：匯入、切換與多設定檔管理

PROFILE / 01

Profile 究竟儲存哪些內容

在 Clash 圖形化客戶端中，Profile 通常是指一份可供核心讀取的設定檔。它可能來自遠端訂閱網址，也可能是手動匯入的本機 YAML 檔案。客戶端負責下載、儲存、切換與更新 Profile；Clash 或 mihomo 核心則會依目前啟用的設定建立監聽連接埠、載入節點、產生策略組，並按照規則處理連線。

不同客戶端對 Profile 的中文名稱不完全一致，常見顯示包括「設定」「設定檔」「訂閱」或「Profiles」。雖然介面名稱不同，核心關係大致相同：設定清單可儲存多份檔案，但同一時間通常只有一份主要設定交由核心執行。切換項目不只是更換節點，也可能同時替換連接埠、DNS、策略組、規則與 TUN 參數。

一份簡化設定可以呈現這些部分之間的關係。實際訂閱通常包含更多節點與規則，支援的欄位範圍也取決於所使用的核心版本。

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

proxies:
  - name: example-node
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: 節點選擇
    type: select
    proxies:
      - example-node
      - DIRECT

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

SOURCE / 02

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

遠端訂閱 Profile 由訂閱網址提供。客戶端儲存網址後，可以依需求或排程重新下載設定。更新後的新內容通常會取代客戶端快取的舊版本，因此節點增減、策略組調整與規則變更會在下次載入時生效。訂閱網址往往包含存取憑證，應視同密碼處理，不要貼到公開截圖、日誌或問題描述中。

本機 Profile 則來自裝置上的 YAML 檔案。它適合儲存手動規則、固定連接埠、實驗性 DNS 設定，或作為故障排查用的最小設定。由於本機檔案沒有遠端來源，客戶端通常不會自動取得更新；後續變更需要重新編輯檔案，或再次匯入修訂後的副本。

還有一種容易混淆的情況：部分客戶端允許複製遠端設定並建立本機副本。副本在建立當下會繼承訂閱內容，但之後通常不會再隨原訂閱自動更新。要判斷設定檔的來源，可以查看項目是否顯示訂閱網址、更新時間、更新間隔或重新整理按鈕。如果只顯示檔案路徑與修改時間，通常更可能是本機檔案。

如果既需要訂閱更新，又需要長期保留自訂規則，建議優先使用客戶端提供的覆寫、合併或擴充功能；具體名稱可能是 Override、Mixin、Merge 或覆寫設定。這類功能會在訂閱下載完成後追加或修改指定欄位，減少直接編輯快取檔案造成的覆寫問題。不同客戶端採用的合併語法並不一致，遷移前應先閱讀對應客戶端的欄位說明。

IMPORT / 03

匯入設定檔與首次檢查

匯入遠端訂閱時，應在客戶端的 Profile 頁面使用「從 URL 匯入」或類似入口，而不是把訂閱網址貼到節點名稱、規則編輯器或瀏覽器代理設定中。匯入成功只代表客戶端取得回應，還需要確認回傳內容能由目前的核心解析。若伺服器回傳登入頁面、提示文字或格式不完整的 YAML，客戶端可能建立項目，但核心載入時仍會報錯。

匯入本機檔案前，可以先檢查副檔名與文字編碼。YAML 通常使用 .yaml 或 .yml，建議儲存為 UTF-8。YAML 依靠縮排表達層級，應使用空格，避免在同一層級混用定位字元。策略組引用的節點名稱必須與節點定義一致，規則指向的策略名稱也必須確實存在。

1. 保留目前可用的設定。首次匯入新的 Profile 前，不要立即刪除原有設定，以便載入失敗時快速切回。
2. 完成匯入並查看更新時間。遠端項目應顯示最近擷取時間，本機項目則應能辨識檔案名稱。
3. 啟用設定並觀察核心狀態。確認客戶端沒有持續顯示解析失敗、啟動失敗或連接埠衝突。
4. 核對策略組。查看群組中是否有可選節點，以及自動測試組是否能完成延遲測試。
5. 檢查代理接管方式。系統代理模式要核對監聽連接埠；TUN 模式則要確認虛擬網卡狀態與權限。
6. 分別測試直連與代理目標。單一網頁能夠開啟，不足以證明規則、DNS 與所有策略都正確。

對於 mihomo 設定，還要留意僅由特定核心支援的欄位。某份 Profile 在 mihomo 客戶端中運作正常，不代表它能直接交給較早期的原版 Clash 核心。遷移時若出現「未知欄位」或解析失敗，應比較核心類型與版本，而不是反覆修改訂閱網址。

SWITCH / 04

正確切換多份 Profile

切換設定前，先記錄目前的執行模式與正在使用的策略組。部分客戶端會依 Profile 儲存策略選擇，另一些則會嘗試在新設定中恢復同名策略。如果兩份設定都包含「節點選擇」，但群組內的節點完全不同，介面可能會回到第一個可用選項。切換後應重新確認重要策略，不要預設沿用舊結果。

連接埠是另一個需要校對的欄位。設定甲使用 mixed-port: 7890，設定乙使用 mixed-port: 7893 時，如果系統代理仍指向 7890，切換到設定乙後就可能出現瀏覽器無法連線，但核心本身看似正常的情況。有些桌面客戶端會自動同步系統代理連接埠，有些只負責載入設定；因此每次跨設定檔切換後，都應查看客戶端顯示的實際監聽位址。

TUN 模式的切換影響更廣。不同 Profile 可能包含不同的 DNS 模式、路由排除項目、自動路由設定與介面偵測參數。切換時虛擬網卡可能短暫重建，既有連線也可能繼續沿用舊路徑，直到連線關閉。驗證新設定時，建議重新開啟測試應用程式，必要時中斷舊連線後再觀察規則命中情況。

適合日常使用的切換順序

1. 確認目標 Profile 最近一次更新成功，並查看是否有載入錯誤。
2. 記下目前的策略組選擇，尤其是手動選擇組與全域模式出口。
3. 切換至目標 Profile，等待核心完成重新載入。
4. 檢查執行模式是 Rule、Global 還是 Direct，避免模式被另一份設定改寫。
5. 確認系統代理或 TUN 狀態，並核對實際監聽連接埠。
6. 開啟連線日誌，測試一條直連規則與一條代理規則。

如果切換後只想更換出口，不需要替換規則與 DNS，那麼直接在目前 Profile 的策略組中選擇節點會更合適。減少不必要的設定切換，也能降低連接埠、規則與 TUN 參數同時變動所帶來的排查成本。

CATALOG / 05

多設定檔整理與命名方法

設定檔數量增加後，問題往往不在匯入，而在於辨認。多個項目都叫 config.yaml，很難判斷來源、用途與更新方式。建議名稱至少包含「來源類型」與「使用情境」，例如「訂閱-A-日常」「本機-規則測試」「備份-遷移前」。名稱中不必寫入訂閱憑證、完整 URL 或節點伺服器位址。

日期適合放在一次性快照中，例如「備份-2026-05-18」；持續更新的訂閱則不宜每次改名，否則會產生大量難以區分的重複項目。對於長期使用的設定，可以在獨立記錄中保存核心需求、連接埠、DNS 模式與自訂內容，而不要依賴記憶。

建議保留的資訊

• 來源：遠端訂閱、本機檔案，還是由訂閱複製出的本機副本。
• 用途：日常使用、規則除錯、TUN 測試或遷移備份。
• 核心需求：適用於原版 Clash，還是依賴 mihomo 擴充欄位。
• 接管方式：系統代理、TUN，或僅為區域網路裝置提供代理連接埠。
• 修改項目：是否調整過 DNS、連接埠、規則或策略組。
• 更新時間：訂閱最後重新整理時間或本機檔案最後修訂日期。

刪除設定前要確認它是否正在使用中。部分客戶端會阻止刪除目前的 Profile，另一些則會自動切換到清單中的其他項目。穩妥的做法是先啟用一份確認可用的設定，再刪除重複項目。對於含有重要手動規則的本機檔案，應先匯出到明確的備份目錄。

REVISION / 06

更新、修改與覆寫關係

遠端 Profile 的核心特徵是「本機快取由遠端內容管理」。直接修改客戶端快取中的節點、規則或 DNS 欄位，短期內可能生效，但下一次重新整理訂閱時通常會被新檔案取代。如果發現自訂規則總是在更新後消失，應先檢查修改位置，而不是把更新失敗誤判為核心問題。

長期修改可以採用三種方式。第一種是使用客戶端的覆寫或合併功能，只儲存需要變更的欄位；第二種是將訂閱複製為本機設定，之後完全自行維護；第三種是使用 proxy-providers 與 rule-providers，將節點集合、規則集合與主要設定分開。第三種方式更適合熟悉 YAML 與 mihomo 設定結構的使用者，並且需要確認遠端資源格式符合對應 provider 的要求。

proxy-providers:
  remote-set:
    type: http
    url: "https://example.invalid/provider.yaml"
    path: ./providers/remote-set.yaml
    interval: 3600
    health-check:
      enable: true
      interval: 600
      url: "https://www.example.com/generate_204"

proxy-providers 不等同於客戶端 Profile。Profile 是交給核心的主要設定；provider 則是主要設定引用的外部資源。一個 Profile 可以引用多個 provider，也可以完全不使用 provider。區分兩者後，才能判斷究竟應重新整理客戶端訂閱、更新 provider，還是重新載入主要設定。

編輯 YAML 時還要注意清單覆寫。某些合併工具會以新的 rules 整體取代舊清單，另一些則支援前置或後置插入。規則會由上而下比對；如果自訂規則被追加到 MATCH 之後，即使檔案能正常載入，這些規則也永遠不會命中。完成合併後，應查看最終產生的設定，而不只是檢查覆寫片段。

PROOF / 07

多 Profile 常見故障排查

切換後所有應用程式都無法連網

先確認核心是否正在執行，再檢查系統代理連接埠與目前 Profile 的監聽連接埠是否一致。如果使用 TUN，請查看虛擬網卡是否成功建立，並確認客戶端具備所需權限。也可以暫時關閉接管功能，確認基礎網路本身是否正常。不要一開始就刪除設定，因為連接埠不同或 TUN 重建失敗更為常見。

設定更新成功，但節點沒有變化

檢查目前啟用的是否確實是剛更新的項目。名稱相近的重複 Profile 很容易造成誤判。接著查看更新時間、策略組內容與核心日誌。如果主要設定引用 provider，還要分別確認 Profile 與 provider 的重新整理狀態；只更新其中一層，不一定會立即改變節點清單。

本機規則儲存後又消失

這通常表示編輯的是訂閱快取，之後的一次更新覆寫了修改。應將規則移至客戶端支援的覆寫機制，或建立獨立的本機 Profile。遷移時同步複製規則引用的策略組名稱，避免規則存在但目標策略缺失。

一份設定在舊客戶端正常，新客戶端卻載入失敗

比較兩邊實際使用的核心，而不只是比較客戶端名稱。mihomo 支援的擴充欄位會隨版本演進，原版 Clash 與不同分支的欄位集合也有所差異。查看錯誤訊息所對應的欄位，確認問題是語法縮排、欄位類型，還是核心不支援。布林值、數字與字串也要維持正確類型，不要為了繞過錯誤而一律加上引號。

切換後策略組選擇被重設

先確認新舊設定是否有完全相同的策略組名稱，以及新群組是否包含原先選擇的節點。若目標不存在，客戶端只能退回可用選項。自動測試組也可能依延遲重新選擇節點，這是群組類型的正常行為，不代表 Profile 切換失敗。

只有部分網域無法存取

開啟連線日誌，查看請求命中的規則與策略。若網域解析失敗，應進一步檢查 DNS 設定、fake-ip 過濾項目與上游連線能力；若命中錯誤策略，則檢查規則順序。在多設定檔環境中，還要確認目前看到的規則編輯器屬於正在執行的 Profile，避免在未啟用的項目中反覆修改。

有效的排查記錄應包含目前 Profile 名稱、來源類型、核心名稱與版本、執行模式、監聽連接埠、接管方式以及一項具體錯誤。訂閱網址與節點憑證應在分享前隱藏。透過這些資訊，可以快速將問題歸類為「設定解析」「核心啟動」「連接埠接管」「DNS 解析」或「規則比對」，減少無方向的重複匯入。

FINAL CHECK / 08

多設定檔管理檢查表

• 設定名稱能辨認來源與用途，不依賴預設檔名。
• 遠端訂閱與本機檔案分開管理，明確哪些內容會被更新覆寫。
• 切換後檢查執行模式、策略組、監聽連接埠，以及系統代理或 TUN 狀態。
• 重要的自訂規則儲存在覆寫或本機檔案中，並備有可還原的備份。
• 升級客戶端或核心前，確認 Profile 是否使用特定分支的擴充欄位。
• 排查時先確認目前啟用的項目，避免修改到未執行的設定。
• 刪除重複設定前，先切換至已驗證可用的 Profile。

Profile 管理的重點不是儲存盡可能多的設定，而是讓每份設定的來源、用途與更新界線都清楚。日常設定保持穩定，測試內容放入獨立項目，遠端訂閱避免直接修改快取，切換後依序核對連接埠、模式、策略與 DNS，便能大幅降低多份設定並存時的排查成本。