Clash Profile 是什麼？訂閱設定與本機 YAML 設定差異、多組設定切換管理

Profile 是用戶端管理的設定檔

Profile 通常是用戶端儲存的一份設定檔，不等於單一節點，也不等於某種代理協定。設定檔可能來自遠端訂閱，也可能是本機 YAML 檔案。用戶端負責記錄來源、名稱、更新資訊與選取狀態；核心則讀取最終產生的設定，建立監聽連接埠、載入節點並套用分流規則。

一份完整設定可以同時包含 mixed-port、mode、dns、proxies、proxy-groups 和 rules。節點包含連線參數，策略群組是選取節點的入口，規則則決定連線使用哪個策略。切換 Profile 可能同時改變這三部分，不能把它當成只是換了一台伺服器。

不同用戶端可能將入口標示為「設定」、「訂閱」或「Profiles」；這些只是介面名稱，並非 Clash 或 mihomo 核心統一規定的選單。要判斷操作是否生效，應查看目前設定標記、核心載入結果和實際規則，而不只是看清單裡有沒有多出一張卡片。

遠端訂閱與本機 YAML 有什麼差異？

兩者的主要差異在於來源與更新方式，而非 YAML 的功能。遠端訂閱通常由用戶端透過 URL 取得；本機設定則由使用者匯入、建立或編輯。遠端回傳的內容若是完整 Clash 設定，通常也會以 YAML 表示；但「訂閱連結」不保證回傳的就是可直接載入的完整設定。

比較項目	遠端訂閱 Profile	本機 YAML Profile
來源	用戶端記錄的訂閱 URL	磁碟檔案或用戶端編輯器
內容更新方式	手動或定期重新取得	手動修改，或由外部工具更新
直接編輯的風險	下次更新可能會覆蓋修改	通常不受遠端訂閱更新影響
節點時效	以服務提供者回傳的內容為準	複製的節點不會自行更新
移轉注意事項	保存來源與本機覆寫設定	保存檔案及其引用的外部資源

訂閱網址不一定就是設定檔網址

有些服務會回傳完整 YAML，有些只回傳節點清單，還有些會回傳編碼過的協定連結集合。後兩種內容必須由用戶端支援相應的匯入格式，或經過可信任的轉換流程，才能成為可用設定。瀏覽器能開啟 URL，只能表示請求有收到回應，無法證明回應內容適用於目前的核心。

匯入後若提示缺少欄位或解析失敗，請先確認回傳內容是不是登入頁面、錯誤訊息或不相容的格式。訂閱 URL 通常含有存取權杖，排除問題時請勿公開完整網址，也不要交給來路不明的線上轉換服務。

從最精簡的 YAML 了解設定的範圍

以下是一份用來理解欄位關係的本機設定，監聽 127.0.0.1:7890，所有連線都使用內建的 DIRECT。由於沒有遠端代理節點，無法用來驗證代理出口；適合在隔離的測試設定中檢查 YAML 載入與規則結構。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: ROUTE
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,ROUTE
  - MATCH,DIRECT

mixed-port: 7890 表示同一個入口接受 HTTP 與 SOCKS 代理連線；如果該連接埠已被占用，請改用未占用的連接埠。
mode: rule 表示依規則清單處理連線；若執行時切換成全域模式，就不能再用這份規則判斷分流結果。
ROUTE 是策略群組名稱，規則引用時必須與名稱完全一致；內建策略 DIRECT 不必另外建立節點。
MATCH 是兜底規則，應放在本例最後，否則後續規則就沒有比對機會。

縮排請使用空格，不要使用定位字元。匯入現有訂閱時，請勿用這段範例整份覆蓋原始檔案；它只展示結構，不包含服務提供者提供的節點與策略。欄位完整說明請參閱設定欄位說明。

多組設定的命名、更新與切換方式

名稱標示用途，備註記錄來源

建議依「用途－來源－管理方式」命名，例如「日常－訂閱 A－遠端」、「辦公－本機規則－覆寫」、「排障－直連－本機」。避免只寫「設定 1」、「設定 2」，也不要把訂閱權杖放進名稱。若用戶端支援備註，可另外記錄匯入日期、核心類型與覆寫位置，避免把所有資訊都塞進名稱。

分別檢查更新與切換

更新前先做好備份：匯出可用設定，並保存目前的策略群組選擇與本機覆寫。匯出的檔案可能含有節點憑證，請存放在受控目錄。
只更新指定項目：確認操作對象的名稱與來源，並檢查更新時間是否改變；更新時間改變不代表設定已啟用。
查看載入結果：啟用目標 Profile 後檢查核心記錄，確認沒有 YAML 解析錯誤、未知欄位造成的載入失敗或策略引用錯誤。
重新確認執行參數：檢查代理模式、監聽連接埠、DNS 與 TUN 開關。部分用戶端會以全域設定覆蓋檔案中同名的欄位。
驗證新連線：發起一筆新連線，並在連線面板查看命中規則、策略鏈與出口，不要只看節點延遲。

例如舊設定監聽 7890，新設定改為 7891，終端機中原有的 http_proxy 不會自動跟著變更。瀏覽器的系統代理入口與終端機環境變數也不是同一套設定。多組設定盡量固定本機入口，可減少切換後連接埠設定不一致的情況。

如何避免訂閱更新覆蓋自訂規則

優先將個人規則保存在用戶端支援的持久覆寫層，不要直接修改訂閱下載的副本。常見作法包括合併設定、前置規則或設定處理指令碼，但名稱、適用範圍與陣列合併方式依用戶端而異。沒有適用於所有用戶端的通用覆寫檔格式，操作前請先確認目前用戶端的說明文件。

先確認插入位置，再確認策略名稱

假設要讓範例網域直連，可以將下列規則放在最終 rules 清單較前面的位置。這裡展示的是最終設定應有的排列方式，並非可直接套用於任何用戶端的覆寫語法：

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,ROUTE

在規則模式下，系統會依序比對規則，命中第一條後就執行對應策略。如果個人規則被加在 MATCH 後面，通常不會達到預期效果。若改為引用 ROUTE，最終設定就必須包含同名策略群組。訂閱更新若將群組名稱改成其他名稱，舊的覆寫也需要一併調整。

確認適用範圍：覆寫只套用於單一 Profile，還是會影響所有設定？請避免讓辦公規則意外套用到其他設定。
確認清單合併方式：用戶端可能會取代整個 rules 陣列，也可能將項目加在前面或後面；不能只憑「合併」二字推斷實際行為。
檢查最終設定：若用戶端提供執行設定預覽，請確認個人規則是否出現、順序是否正確，以及目標策略是否存在。
更新後再測一次：儲存覆寫後手動更新訂閱，再檢查規則與新連線，確認修改在更新後仍然保留。

若用戶端不支援持久覆寫，可以複製成一份本機設定再編輯，但副本不會繼續自動取得原訂閱的節點更新。請明確選擇「手動維護副本」或「繼續使用遠端更新」，不要把本機修改和自動更新混在同一個暫存檔案中。

proxy-providers 與多組 Profile 屬於不同管理層級

proxy-providers 是在設定內引用節點提供者的機制；多個 Profile 則是用戶端保存的多份設定檔。以 mihomo 為例，可以在一份本機設定中引用多個提供者，分開管理節點來源與本機規則，但仍須正確設定策略群組對提供者的引用。

提供者更新通常只會更新其提供的節點，不等於重新下載整份主要設定。提供者 URL 也必須回傳目前實作支援的格式，不能認定任何「訂閱連結」都能直接填入。若還使用 rule-providers，規則集合下載與主要設定更新也需要分開排查。

一般使用情境可以先維護一份穩定的訂閱，再加入明確的本機覆寫。只有確實需要分開管理節點來源、規則集合與更新週期時，才考慮使用提供者結構，避免同時維護多份重複規則，反而難以追查最終設定的來源。

切換設定後發生異常，從四個層面排查

來源層：確認更新的是目標 Profile，回應內容是設定而非網頁；檢查訂閱是否失效，避免不斷重複匯入同一個錯誤網址。
載入層：確認核心是否接受新設定。若遇到縮排錯誤、策略不存在或欄位不相容，請先修正載入問題，不要直接歸因於節點逾時。
入口層：確認 7890 或自訂連接埠正在監聽，並檢查系統代理與終端機是否指向同一個入口；若使用 TUN，還要另外檢查權限、路由與 DNS 接管狀態。
分流層：確認執行模式為 rule，檢查新連線命中的規則與策略群組選擇，再判斷問題是否出在遠端節點或服務端。

匯入三份訂閱後，節點會自動合併嗎？

通常不會。多數用戶端一次只會啟用一份主要設定，其他訂閱只會留在清單中。若確實需要合併，必須使用用戶端明確支援的合併功能，或在相容的核心中透過提供者管理節點；不能只因清單中有三項就認定已完成合併。

切換 Profile 時會自動切換 TUN 嗎？

不一定。TUN 可能由用戶端的全域開關管理，也可能由設定與覆寫共同決定，並且涉及系統權限。請檢查用戶端執行狀態與最終設定，不能只看匯入檔案中是否有 tun 欄位。

備份一份 YAML 就能完整移轉嗎？

不一定。主要設定可能會引用本機規則檔、提供者快取、憑證路徑或用戶端覆寫；訂閱 URL 和介面中的策略選擇也可能分開儲存。移轉前請列出這些相依項目，匯入新裝置後驗證連接埠、規則與新連線，並妥善保管含有憑證的檔案。

管理多組設定的關鍵，是分別記錄「來源更新」、「本機修改」與「執行時選擇」。保留一份已確認可用的設定，只更新指定項目，並在每次切換後驗證最終規則與新連線，通常比反覆刪除再重新匯入更容易找出問題。