Clash Profile 設定檔是什麼？多組設定檔的切換與管理方式

Profile 與 config.yaml 的差異

Profile 通常是 Clash 圖形用戶端對「可選用的一份設定檔」的稱呼。它可能來自本機 YAML 檔案，也可能連結遠端訂閱網址。除了設定內容，用戶端也可能會記錄名稱、來源、更新時間與覆寫設定。這些管理資訊屬於用戶端，不一定會寫入核心讀取的 YAML 檔案。

config.yaml 則是常見的核心設定檔名稱。mihomo 是由 Clash Meta 專案發展而來的核心，可讀取包含監聽連接埠、節點、代理群組、DNS 與分流規則的設定。檔名不一定要是 config.yaml：命令列可透過 -f 指定其他檔案，圖形用戶端也可能產生自己的執行時檔案。

• Profile 清單：保存多份候選設定，方便依用途選擇。
• 目前啟用的 Profile：用戶端會以這份設定產生或載入目前的設定。
• 執行時設定：核心實際使用的內容，可能已套用全域設定、覆寫與指令碼處理。

因此，排查問題時要區分「原始訂閱」、「用戶端編輯後的結果」與「核心目前使用的設定」。只開啟磁碟上的某個 config.yaml，不一定看得到連線記錄中實際套用的所有規則。

本機設定檔與遠端訂閱怎麼選

本機設定檔也可以包含 proxy-providers 或 rule-providers，繼續從遠端取得節點與規則。「本機」只表示這份 Profile 的來源入口，不能據此認定所有資源都已離線保存。備份時若漏掉 provider 快取與相依檔案，離線環境下仍可能無法還原。

訂閱 URL 不等於設定檔格式

同一個匯入欄位接受的是網址，但網址回傳的內容可能各不相同。完整的 Clash YAML 可以包含 proxies、proxy-groups 與 rules；Base64 編碼的節點清單通常只有節點資訊，不能直接當作完整的規則設定。另有一些 YAML 是專供 provider 使用的 proxies 清單，也不等同於完整 Profile。

匯入失敗時，先查看用戶端的錯誤詳情，確認回傳的是設定檔，而不是登入頁面、過期通知或 HTML 錯誤頁面。若伺服器提供格式選項，請選擇與目前核心相容的 Clash 或 mihomo 設定。訂閱網址通常含有存取權杖，請勿貼到公開的轉換網站、截圖或問題回報中。

多組設定檔的命名與分類方式

命名時先說明用途，再標示來源，最後註明是否為測試副本。避免只用「設定 1」、「新訂閱」或一再加上「最終版」，否則很難判斷哪一份可以安全更新。以下是可直接採用的名稱：

• 日常-主訂閱：保留伺服器更新，用於平時瀏覽。
• 備用-獨立訂閱：使用另一個來源，故障時手動切換。
• 辦公-本機規則：明確處理辦公網域與內部網路位址。
• 測試-DNS-2026-08-18：僅用來驗證 DNS 變更，不影響日常設定。

日期適合用在快照與測試副本，長期使用的訂閱名稱則應保持穩定。建議每份設定都記下三項備註：來源類型、適用核心、相依的覆寫名稱。例如「遠端 YAML；mihomo；套用辦公網域規則」，比只記服務商縮寫更方便日後移轉。

備用設定檔要先測試

兩份名稱不同的 Profile，實際上可能指向同一個訂閱網址。這類副本適合測試修改，卻不能當作獨立的備援線路。請事先確認備用設定可以更新、代理群組中有可選節點，且目標網站能正常連線，再切回日常設定。等主要線路故障後才首次匯入，可能同時遇上訂閱下載與節點連線問題。

切換 Profile 的操作與檢查順序

不同用戶端可能使用「設定」、「訂閱」或「Profiles」等入口，按鈕名稱也會隨版本變更。先在設定清單中找到目標項目，分清楚「編輯」、「更新」與「啟用」：編輯只會修改內容，更新只會取得來源的新內容，啟用才會切換目前使用的設定。有些用戶端更新目前項目後會自動重新載入，有些則需要另外確認。

1. 記錄目前狀態。記下目前的 Profile、規則模式、代理群組選擇與系統代理開關；必要時可截取不含訂閱網址的畫面。
2. 更新目標項目。遠端 Profile 先重新整理一次，確認更新時間與失敗提示。本機設定則先檢查相依檔案的路徑。
3. 啟用目標設定。等待載入完成，並確認記錄中沒有 YAML 解析錯誤、策略不存在或資源下載失敗等訊息。
4. 重新選擇代理群組。新設定的群組名稱可能不同，不要假設上次選取的節點會自動沿用。
5. 建立新連線。重新開啟測試網頁，並在連線詳細資訊中確認規則、策略鏈與目標位址。

例如，舊設定使用 mixed-port: 7890，新設定改為 mixed-port: 7897，但終端仍將代理指向 127.0.0.1:7890，就可能導致連線失敗。圖形用戶端也可能用全域連接埠設定覆蓋 Profile 中的連接埠，因此要檢查實際監聽值，而不是只比對兩個檔案。

在 Linux 上可使用以下命令查看範例連接埠是否正在監聽。若設定了其他連接埠，請依實際值調整：

ss -lntp 'sport = :7890'
ss -lntp 'sport = :7897'

已開始的下載、影片播放或長連線可能仍沿用切換前的連線。驗證時請優先建立新連線；必要時可在用戶端的連線頁面關閉相關連線後再試，避免誤以為舊連線的出口代表新設定尚未生效。

自訂規則放在哪裡才方便維護

遠端訂閱應盡量保留為可更新的原始來源，長期修改則放進用戶端支援的覆寫、合併或指令碼入口。不同用戶端合併欄位的方式不盡相同：有些會取代整個清單，有些則允許將規則插入清單前端或末端。儲存前應檢視產生後的設定，確認修改確實套用到執行時結果。

一併檢查規則順序與代理群組名稱

以下僅示意規則順序，並非完整設定。範例會讓內部示範網域與私有網路網段直連，再交由後續規則處理其他流量：

rules:
  - DOMAIN-SUFFIX,office.example,DIRECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,DIRECT

office.example 使用保留的示範網域，不應將這條規則當成實際辦公環境的網域。最後的 MATCH,DIRECT 只是讓範例結構完整，照搬會讓其餘流量全部直連。實際設定應保留所需的後續規則，並使用已定義的預設策略。

規則會由上往下比對。若自訂網域規則加在 MATCH 後面，就不會執行。若規則指向名為 辦公出口 的代理群組，切換後的設定也必須有同名群組，否則可能無法載入。只引用 DIRECT 可避免依賴群組名稱，但是否符合需求仍須視實際用途判斷。

每次只調整一類設定

先驗證規則，再調整 DNS，最後檢查 TUN。不要一次同時更換訂閱、修改 DNS、變更連接埠並啟用 TUN，否則發生故障時很難找出原因。全域覆寫也可能影響所有 Profile；若只想讓測試設定使用新的 DNS，請先確認覆寫的適用範圍。

備份、設定測試與還原

完整備份至少應包含原始設定、用戶端管理資料與自訂覆寫。只複製執行時的 config.yaml，可能會遺失訂閱 URL、自動更新時間、指令碼與代理群組選擇記錄；只匯出用戶端清單，也可能沒有保存 provider 的實際內容。

1. 使用用戶端支援的匯出或備份功能建立副本，並記錄用戶端與核心版本。
2. 將手動維護的規則、覆寫指令碼、provider 檔案及必要的憑證相依檔案一併封存。
3. 為變更前後的快照標註日期，例如 daily-2026-08-18.yaml，避免覆蓋唯一可用的副本。
4. 將含有節點密碼、訂閱權杖或控制介面金鑰的備份存放在受限目錄；分享前先移除敏感資訊。

使用 mihomo 測試候選設定

命令列使用者可以先檢查核心版本，再於獨立目錄中測試候選檔案。以下假設目前目錄中已有 candidate.yaml，且 mihomo 已加入命令搜尋路徑：

mihomo -v
mkdir -p ./profile-check
mihomo -t -d ./profile-check -f ./candidate.yaml

-t 用於測試設定，-d 指定工作目錄，-f 指定設定檔。相對路徑及外部資源必須依實際目錄準備；若涉及規則集等資源，也可能需要先下載。測試通過只代表核心接受這份設定，不代表節點可用、DNS 正確或系統代理已生效。

還原時，先恢復上一份可用的 Profile，再恢復與其搭配的覆寫；重新載入後建立新連線進行測試。若使用命令列，替換磁碟上的檔案後，還需要透過既有管理方式重新載入設定或重啟對應服務；光是覆寫檔案，不代表核心已重新讀取。

Profile 管理常見問題

日常維護可固定採用一套流程：保留原始來源，以覆寫管理長期規則，切換後確認新連線，並在重要變更前保存可還原的快照。設定檔不必很多，來源清楚、適用範圍明確，且還原步驟可重複執行更重要。