Clash 設定檔 Profile 入門：訂閱連結、本機設定與多設定切換

Profile 與訂閱的關係

Clash 用戶端中的 Profile，通常是指一份可供選取並載入的設定檔。來源可能是遠端訂閱，也可能是電腦上的 YAML 檔案。除了設定內容，設定檔也可能記錄來源網址、更新時間與更新週期等用戶端資訊。核心實際讀取的是用戶端處理後的設定，而不是介面上的設定卡片本身。

了解這一點，就能分清三種常被混為一談的操作：匯入是將設定加入清單；更新是重新取得設定內容；啟用則是將某份設定交由核心執行。匯入成功不代表已啟用，下載成功也不代表核心能接受新內容。

特別要分清整份訂閱與 proxy-providers。前者可能同時定義連接埠、DNS、群組與規則；後者主要提供節點，再由主設定中的策略群組透過 use 引用。rule-providers 則提供規則集，不負責提供代理節點。

如何匯入訂閱連結

先確認取得的格式

同一個服務可能提供多種訂閱格式。適用於其他代理軟體的節點清單，不一定能直接當作 Clash 的完整 YAML 設定使用。優先選擇服務方明確標示的 Clash 或 mihomo 格式；若內容包含 VLESS、Hysteria2 等協定，也要確認用戶端實際使用的核心支援這些協定，不能只看應用程式名稱是否有 Clash。

1. 在用戶端找到「設定」或「Profiles」頁面，使用其中的連結匯入功能。不同用戶端的按鈕名稱可能是「新增」、「匯入」或「加入」，請以目前介面為準。
2. 貼上完整網址，前後不要留空格，也不要加上引號或聊天軟體附帶的標點。替設定檔取個容易辨識用途的名稱，例如「家用網路」或「出差備用」。
3. 匯入完成後，先檢查更新時間，再手動選取這份設定。查看記錄中是否出現解析失敗、未知欄位或策略群組引用錯誤。
4. 開啟代理群組，確認節點清單存在，再測試一個確定會經過該群組的新連線。此時先不要同時修改 DNS 和 TUN，以免混淆問題來源。

匯入失敗時先檢查回應內容

如果錯誤訊息提到 YAML，回應內容卻以 <html> 開頭，下載到的可能是登入頁面或錯誤頁面。HTTP 401、403 常與授權失效或存取限制有關；429 通常表示請求頻率受到限制。遇到這些情況，請先確認訂閱來源，不要反覆按下更新，也不要為了避開錯誤而任意關閉 TLS 憑證驗證。

本機設定與最小範例

本機 Profile 適合需要固定規則、離線保留設定，或想先了解欄位用途的情況。建立一份 UTF-8 編碼的 profile-local.yaml，使用空格縮排，請勿使用 Tab。以下是用來理解結構的最小設定：監聽本機 7890 連接埠，只有一個直連選項，不包含遠端代理節點。

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

proxy-groups:
  - name: 手動選擇
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手動選擇

• mixed-port: 7890 提供 HTTP 與 SOCKS 代理連線埠；此處的連接埠號碼僅為範例，不代表每個用戶端都使用 7890。
• allow-lan: false 不會開放給區域網路中的其他裝置使用。初次設定時保留此值，可減少額外的網路曝露。
• mode: rule 使用規則模式；最後的 MATCH 會接住前面未匹配的連線。
• 手動選擇 是策略群組名稱，規則引用時必須完全一致。本例最後選擇 DIRECT，因此流量仍會直接連線。

將檔案作為本機設定匯入後，用戶端仍可能覆寫監聽連接埠、執行模式或 DNS。需要排查時，應同時檢查原始檔案、用戶端設定與執行中設定，而不只是查看 YAML。核心欄位與相容性請參閱核心設定參考。

若系統已安裝可執行的 mihomo，可在檔案所在目錄執行以下語法測試。測試成功只表示設定通過該核心的載入檢查，不代表節點連線正常，也不代表桌面系統代理已啟用。

mihomo -t -f ./profile-local.yaml

如何設定自動更新間隔

若日常使用的節點不常變動，可先將 Profile 自動更新設為每 24 小時一次；若服務經常調整節點，可依服務方建議改為每 6 小時一次。這只是設定起點，不是實測效能結論。提高更新頻率不會降低既有節點的延遲，反而可能觸發伺服器的流量限制。

先確認單位，再輸入數值

• 若用戶端介面以「分鐘」為單位，24 小時應填 1440；以「小時」為單位則填 24。
• mihomo 的 HTTP 代理提供者中，interval: 86400 代表 86400 秒，也就是 24 小時；此欄位不是 GUI 的 Profile 更新週期。
• 提供者中的健康檢查週期 health-check.interval 是檢查節點狀態的頻率，並非重新下載訂閱的頻率。
• 不要預設 0 一定代表停用。不同用戶端的設定方式可能不同，請優先使用明確標示的自動更新開關。

電腦進入睡眠、用戶端關閉或網路無法使用時，更新工作可能無法如期執行。網路恢復後，先查看「上次成功更新」的時間；修改訂閱網址後，再手動更新一次確認結果。不要只因自動更新開關已開啟，就認定檔案內容已是最新。

多設定切換時的檢查順序

多數桌面用戶端一次只會啟用一份主要 Profile。清單中儲存三份設定，不代表三個服務商的節點會同時載入同一個策略群組。切換設定檔時，新的規則、DNS 與策略群組可能會一併生效；系統代理、TUN 權限等通常由用戶端管理，不一定會隨設定檔同步切換。

1. 記錄原有狀態：記下目前的設定名稱、執行模式、選取的節點，以及系統代理和 TUN 的開關狀態。
2. 選取新設定檔：確認介面顯示此設定為啟用狀態，並檢查核心記錄是否有載入失敗；若載入失敗，用戶端可能會繼續使用舊設定。
3. 檢查策略群組：用戶端可能會記住同名群組的選擇，但新設定中可能沒有舊節點，因此不要假設仍選取原本的節點。
4. 確認連線埠：若應用程式手動設定為 127.0.0.1:7890，但新執行設定實際監聽 7897，就必須統一兩端設定。
5. 建立新連線：關閉後重新開啟測試頁面或相關應用程式連線，查看連線記錄中的規則與出口。既有的 TCP 長連線不一定會在切換後立即重建。

若遇到「切換後瀏覽器可以使用，終端機卻不行」，請先檢查終端機環境變數，而不是立刻更換訂閱。在 Linux 下執行以下指令可查看常見的代理變數；輸出內容可能包含內部網址，分享記錄前請先自行處理敏感資訊。

printenv http_proxy https_proxy all_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY

系統代理主要影響會遵循其設定的應用程式；TUN 則透過虛擬網路介面接管更多連線，並需要相應服務或權限。切換 Profile 無法取代 TUN 授權。兩者的適用範圍請參照TUN 模式說明逐項檢查。

合併設定時要處理哪些衝突

若確實需要在同一份設定中使用多個來源，建議採用主設定搭配 proxy-providers，或使用用戶端明確支援的合併功能。不要將兩份完整 YAML 檔案直接首尾相接：重複的頂層鍵可能會遭解析器拒絕，也可能造成覆寫，結果不等於節點與規則自動合併。

規則順序比規則數量更重要

規則通常依照由上而下的順序比對。若將自訂規則加在 MATCH,DIRECT 之後，連線已被兜底規則接住，後續規則就不會如預期生效。若用戶端提供「前置規則」和「後置規則」兩種方式，請確認規則最後產生的位置，而不只是看編輯器顯示儲存成功。

此外，一般完整訂閱不一定能直接作為 proxy-providers 的資源使用；提供者需要採用核心支援的節點資源格式。合併工具處理陣列時，也可能整段取代而非追加。每次只新增一個來源，載入測試通過後再檢查執行設定中的節點數量、策略群組引用與規則末尾，比一次貼上多份內容更容易找出問題。

備份、還原與常見問題

備份不能只保留訂閱網址

訂閱網址可用來重新下載遠端內容，卻無法完整還原自訂規則、用戶端覆寫與策略選擇。建議在首次設定可用時，以及每次大幅修改規則前，各保留一份備份並以日期區分。另留一份確認可用的本機設定，還原時會更有把握。

• 設定檔：保存本機 YAML、可用的遠端設定快照，以及來源名稱與更新時間。
• 自訂層：保存覆寫檔案、合併指令碼與自行維護的規則資源，不要只複製執行時產生的檔案。
• 用戶端設定：記錄監聽連接埠、系統代理、TUN 與更新週期；優先使用用戶端正式提供的匯出功能。
• 保護隱私：備份可能包含節點密碼、訂閱權杖或控制介面金鑰，請存放在存取受限的資料夾中；同步至其他裝置時，請使用具備保護措施的儲存方式。

為什麼更新後規則又恢復原狀？

最常見的原因是直接修改了遠端檔案本身。請將修改移至用戶端的獨立覆寫層，再確認產生的設定是否保留規則。不要長期直接編輯暫存的執行檔案，它可能在重新啟動、切換或更新時再次產生。

為什麼本機設定不會自動更新？

從本機匯入通常只有檔案內容，沒有遠端來源。部分用戶端會複製檔案，而非持續讀取原始路徑，因此即使修改磁碟上的原始檔案，也不一定會立即生效。請確認用戶端是否支援檔案關聯；若不支援，請重新匯入或使用用戶端的編輯功能，再重新載入。

還原舊設定後仍無法連線，該怎麼辦？

先確認核心已成功載入舊設定檔，再檢查訂閱是否過期、系統時間是否正確，以及連接埠是否被占用。還原設定無法恢復伺服器端已刪除的節點，也無法自動補上系統權限。依照「載入設定 → 連線埠 → 規則匹配 → 節點連線」的順序排查，通常比同時切換多個開關更有效。其他訂閱問題請參閱訂閱常見問題。