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

Profile 是一套可切換的執行設定

在 Clash 用戶端中，Profile 通常指一份可交由核心讀取的設定檔。一般採用 YAML 格式，內容可以包含監聽埠、代理節點、策略群組、分流規則、DNS 設定、代理提供器與規則提供器。用戶端選取某個 Profile 後，會解析這份檔案，並將有效設定交給 Clash 或 mihomo 核心。

Profile 並不是單一節點的同義詞。節點只是設定中的連線項目；策略群組負責組織多個節點或其他策略；規則則依照網域、IP、程序等條件，將請求交給相應的策略群組。切換節點通常只會變更某個策略群組目前選取的成員；切換 Profile 則可能同時變更節點清單、規則順序、DNS 模式、連接埠與 TUN 參數，影響範圍更大。

不同用戶端對 Profile 的稱呼可能略有差異，例如「設定」、「訂閱」、「設定檔」或「Profiles」。介面名稱雖然不同，核心關係基本一致：用戶端儲存設定來源，核心讀取目前設定，使用者再透過策略群組調整具體出口。

設定來源決定更新方式

常見的 Profile 來源有三類：透過訂閱網址匯入、從本機 YAML 檔案匯入，以及在用戶端中建立或複製後自行維護。來源不同，後續的更新行為也不同。建立多設定檔架構前，應先確認每份設定是由遠端維護還是由本機維護。

透過訂閱網址匯入

訂閱網址提供的是遠端設定內容。用戶端通常會儲存該網址，並允許手動重新整理或依設定的間隔更新。重新整理時，用戶端會再次請求遠端內容，再以新內容取代對應的快取版本。是否保留本機修改取決於用戶端實作，因此不應直接在會被重新整理覆蓋的遠端設定上長期修改規則。

訂閱網址可能包含帳戶識別資訊，應按照敏感憑證管理。不要將網址寫入公開截圖、公開程式碼儲存庫、共用文件或問題記錄。需要在另一台裝置匯入時，優先透過可信管道傳遞，並在不再使用的裝置中刪除對應設定。

匯入本機 YAML 檔案

本機檔案適合測試、自建規則與離線備份。部分用戶端會將檔案內容複製到自身的設定目錄，之後修改原始檔案並不會自動同步；另一些用戶端則可能直接引用指定路徑。匯入後可修改一個容易辨識的描述欄位或規則，再重新載入，以確認用戶端實際讀取的是副本還是原始路徑。

手動建立或複製設定

複製現有 Profile 後再進行調整，適合保留穩定版本並測試新規則。例如從「日常穩定」複製出「DNS 測試」，只修改 DNS 與相關規則。測試通過後，再決定是否將變更合併至長期使用的設定。如此可避免在唯一可用的設定上反覆編輯。

切換 Profile 後依層級確認是否生效

在介面中點選 Profile，只代表用戶端準備使用該設定。是否真正生效，還要檢查設定解析、核心執行與系統流量入口三個層級。較穩妥的切換順序是：儲存目前工作、選取目標 Profile、等待解析完成、確認策略群組狀態，再檢查系統代理或 TUN。

1. 選取目標設定：在 Profile 清單中點選要使用的項目，確認目前標記已移至目標設定。
2. 檢查載入結果：查看用戶端是否顯示 YAML 語法、欄位相容性、連接埠衝突或代理提供器下載失敗等提示。
3. 檢查策略群組：確認關鍵策略群組存在，並查看目前節點是否仍可使用。不同設定中的同名策略群組，也可能包含完全不同的節點。
4. 確認執行模式：檢查 Rule、Global 或 Direct 模式。一般日常分流使用 Rule；Global 會將大部分請求交給全域策略；Direct 則會直接連線。
5. 確認流量入口：瀏覽器等遵循系統代理的程式，需要系統代理處於正確狀態；不讀取系統代理的程式，通常需要 TUN 或應用程式自身的代理設定。
6. 執行存取檢查：分別測試直連目標、代理目標與 DNS 解析，避免只依節點延遲判斷設定是否完整生效。

切換至監聽連接埠不同的 Profile 時，系統代理中儲存的連接埠也必須相符。例如舊設定使用 mixed-port: 7890，新設定改為 mixed-port: 7897，但系統仍指向舊連接埠，應用程式就可能無法連線。部分用戶端會自動同步系統代理連接埠，但仍建議在切換後核對一次。

mixed-port: 7890
mode: rule
allow-lan: false

dns:
  enable: true
  ipv6: false
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

這段範例只展示設定層級，不構成完整的 Profile。實際設定還需要符合所用核心版本、節點通訊協定、規則結構與本機網路環境。YAML 使用空格表示層級，Tab 字元、縮排錯位或重複欄位都可能導致載入失敗。

多設定檔管理應依用途、來源與狀態命名

設定數量增加後，最常見的問題不是檔案遺失，而是無法判斷哪一份正在使用、哪一份可以更新。只使用「設定 1」、「新設定」、「最終版」之類的名稱，很難在故障時快速回復。建議名稱至少包含用途與來源，必要時再加上狀態或日期。

日常使用通常不需要儲存大量重複副本。保留一份主要使用的遠端設定、一份經過驗證的本機穩定備份，以及少量依情境區分的測試設定，已足以應付大多數切換與回復需求。副本過多會造成策略群組選取、更新時間與訂閱來源混淆。

區分系統代理設定與 TUN 設定

系統代理主要影響遵循作業系統代理設定的應用程式，結構相對直接。TUN 模式會建立虛擬網路介面並接管更廣泛的流量，還涉及路由、DNS 劫持、介面自動偵測與權限。若經常在兩種模式之間切換，可以分別維護 Profile，避免每次手動修改多項參數。

使用 mihomo 核心時，TUN 設定可能包含 stack、auto-route、auto-detect-interface 與 DNS 劫持等欄位。欄位支援情況與核心版本、作業系統及用戶端權限有關。將適用於某個平台的 TUN 區段直接複製到另一個平台，可能造成介面選取錯誤、區域網路存取異常或 DNS 路徑變更。

保留一個經過驗證的回復點

穩定備份應來自實際執行正常的設定，而不是剛下載但尚未使用的檔案。備份時記錄匯出日期、核心類型與適用情境。發生訂閱內容異常、規則提供器無法連線或新版本欄位不相容時，可以先切回穩定設定恢復連線，再個別檢查更新內容。

訂閱更新與本機修改需要分層處理

遠端訂閱的優勢是節點、策略群組與規則可以由來源方集中更新，但這也表示重新整理可能覆蓋直接寫入該 Profile 的修改。要讓更新與自訂內容都能維護，必須將「遠端產生的內容」與「本機個人化內容」分開。

方案一：使用用戶端覆寫功能

部分用戶端支援覆寫、混入或腳本處理。遠端設定下載後，這些功能會再追加或修改指定欄位。例如統一調整連接埠、啟用區域網路存取、補充規則或替換 DNS 設定。覆寫語法並非所有 Clash 用戶端通用的標準，遷移至其他用戶端前應先匯出並檢查格式。

方案二：使用 proxy-providers 與 rule-providers

mihomo 支援透過代理提供器與規則提供器，將外部內容拆分管理。主設定負責連接埠、DNS、策略群組與規則順序，提供器則依 URL 或檔案路徑載入節點與規則集。如此可只更新外部資料，而不必替換整份主設定。

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

proxy-groups:
  - name: PROXY
    type: select
    use:
      - remote-nodes

範例網址使用無法解析的保留網域，僅用於展示結構。實際使用時，需要填入合法來源，並確認回傳內容符合代理提供器格式。完整訂閱設定與 provider 檔案的結構不一定相同，不能只將任意訂閱網址放入 proxy-providers，就假定它能夠解析。

方案三：維護完整本機設定

需要精確控制規則順序、DNS 連線路徑與 TUN 行為時，可以維護完整的本機 YAML，並手動更新節點部分。這種方式的控制範圍更明確，但維護成本也更高。每次修改後都應先執行設定檢查，再切換為目前的 Profile；不要讓未經驗證的檔案直接取代穩定版本。

匯入失敗與切換異常的檢查流程

Profile 問題可以依「取得來源—檔案解析—核心執行—系統接管—規則命中」的順序檢查。按層級定位比反覆刪除並重新匯入更有效，也能保留錯誤現場。

訂閱匯入後清單為空

• 確認訂閱網址仍然有效，並檢查用戶端是否顯示 HTTP 狀態或逾時資訊。
• 確認回傳內容是 Clash 可讀取的 YAML，而不是登入頁面、錯誤提示或其他用戶端專用格式。
• 檢查系統時間。憑證驗證、訂閱有效期限與遠端請求都可能受到明顯錯誤的系統時間影響。
• 如果目前網路本身無法存取訂閱來源，可以先使用既有的穩定 Profile 建立連線，再執行更新。

設定可以匯入，但無法切換

• 查看記錄中的具體欄位與行號，重點檢查 YAML 縮排、陣列格式與重複鍵。
• 確認設定使用的欄位受到目前核心支援。為 mihomo 撰寫的擴充欄位不一定能被舊版 Clash 核心接受。
• 檢查監聽連接埠是否已被其他程式或另一個核心執行個體佔用。
• 檢查規則引用的策略群組是否存在，名稱的大小寫與字元必須完全一致。
• 檢查外部 provider 檔案是否成功下載、路徑是否可寫入，以及內容格式是否符合對應類型。

切換成功，但存取路徑沒有變化

• 確認用戶端介面中的目前 Profile 標記已變更，並檢查核心是否完成重新載入。
• 確認系統代理位址與新 Profile 的監聽連接埠一致。
• 確認目前執行模式不是 Direct，並檢查目標請求最終命中了哪條規則。
• 使用 TUN 時檢查虛擬介面、路由與權限狀態；關閉 TUN 後殘留的系統代理，也需要另外核對。
• 瀏覽器或應用程式可能會沿用既有連線。切換後可以關閉相關連線或重新啟動應用程式，再進行測試。

建立可重複的日常設定流程

一套可維護的流程可以濃縮為六個步驟：匯入、命名、檢查、啟用、測試、備份。首次匯入時記錄來源與用途；載入前檢查語法與相容性；啟用後分別驗證策略群組、DNS、規則命中與流量入口；確認穩定後再建立本機回復版本。

更新遠端設定時，不應只看節點數量是否變化。還要檢查關鍵策略群組名稱、規則順序、DNS 模式與監聽連接埠，因為這些項目會直接影響用戶端原有的選擇與系統設定。若更新後出現異常，先回復至已驗證的 Profile，再比較兩份設定的結構差異。

對於經常移動辦公或切換網路環境的裝置，可以依情境保留設定，例如「家庭系統代理」、「行動網路 TUN」、「開發環境本機規則」。每份設定只負責清楚的用途，並盡量共用一致的命名規則。如此在網路變更時，操作目標是切換已驗證的情境，而不是臨時修改大量欄位。

Profile 管理的重點不是累積更多檔案，而是讓每份設定的來源、更新方式、適用情境與回復關係都能清楚判斷。只要將遠端訂閱與本機修改分層、將節點選取與整套設定切換區分開，再依固定順序核驗生效狀態，多設定檔的使用就能保持清晰。