Profile：可載入的設定檔
在 Clash 用戶端中，Profile 通常指一份可選取、更新或編輯的設定檔。除了設定內容，也可能包含名稱、來源網址、更新週期等管理資訊。設定內容通常採用 YAML 格式，決定監聽連接埠、節點、策略群組、分流規則和 DNS 等行為；名稱與更新週期則可能儲存在用戶端自己的資料庫，而非寫入 YAML。
因此，Profile 不等於單一節點，也不等於訂閱帳號。一份 Profile 可以包含數十個節點和多個策略群組；同一個訂閱連結每次取得的內容也可能不同。用戶端儲存的是對應來源的設定記錄，核心執行時讀取的則是載入、合併或覆寫後的設定。
先區分三個層次
- 設定來源：遠端訂閱網址、本機檔案，或用戶端提供的編輯功能。
- 設定內容：YAML 中的
proxies、proxy-groups、rules等欄位。 - 執行狀態：目前選取的策略、代理模式、已建立的連線，以及系統代理開關。
切換 Profile 主要是變更目前載入的設定，不代表所有執行狀態都會恢復預設值。有些 Clash 用戶端會記住策略群組的選擇，也有些會透過覆寫保留連接埠或 TUN 設定。確認實際效果時，應同時檢查目前的設定名稱與執行中的設定，而不只是看設定清單中哪一項反白。
訂閱設定與本機設定的差異
訂閱設定是從遠端網址取得，適合接收節點、策略群組或規則的後續更新；本機設定則從裝置上的檔案匯入，內容由使用者自行管理。兩者都可能是完整的 YAML 設定檔，差異主要在來源與維護方式，而非副檔名。
| 項目 | 訂閱設定 | 本機設定 |
|---|---|---|
| 匯入方式 | 貼上遠端設定網址 | 匯入或拖曳 YAML 檔案 |
| 更新方式 | 手動或定期取得遠端內容 | 編輯後重新載入，或重新匯入檔案 |
| 適用內容 | 需要隨來源更新的節點與規則 | 固定規則、測試設定與自行管理的方案 |
| 主要風險 | 來源失效、回應錯誤、更新時覆蓋修改 | 語法錯誤、欄位不相容、節點資訊失效 |
訂閱連結不一定會提供完整設定
有些連結會回傳完整的 Clash YAML，有些只提供節點清單，也有些使用其他訂閱格式。只有節點清單時，無法確保能直接作為完整的 Profile 使用。匯入前應確認來源提供的格式；不要只因網址中出現「clash」就認定相容。
此外，proxy-providers 是在設定檔中定義的節點提供者，與用戶端清單中的訂閱 Profile 不同。本機 Profile 可以引用遠端 provider；遠端 Profile 也可以同時包含內建節點與 provider。此時，「更新整份設定」和「更新提供者資源」是兩個獨立操作。
YAML 欄位與最小測試設定
先了解設定結構，再調整個別參數。不同核心版本支援的欄位可能不同；Clash Meta 現稱為 mihomo，不能預設所有舊版 Clash 核心都支援 mihomo 的擴充欄位。以下範例僅用來測試 YAML 載入與本機監聽，所有流量都會直連，不包含代理節點。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxy-groups:
- name: Route
type: select
proxies:
- DIRECT
rules:
- MATCH,Routemixed-port: 7890：在同一個連接埠提供 HTTP 與 SOCKS 代理入口。7890 是本例指定的值，並非所有用戶端的固定連接埠。allow-lan: false：不允許區域網路裝置存取。若要共用代理，請另外檢查監聽位址與防火牆設定。mode: rule：依規則處理連線。用戶端介面中的模式選項可能會覆寫這個值。proxy-groups：定義名為 Route 的選擇群組，本例只有 DIRECT 一個選項。MATCH,Route：作為最後一條兜底規則，將先前未符合規則的連線交給 Route 處理。
使用核心檢查語法
將範例儲存為 profile-test.yaml。若已安裝 mihomo 命令列核心，請在檔案所在目錄執行：
mihomo -v
mihomo -t -f ./profile-test.yaml第一個指令會顯示實際核心版本，第二個指令則測試設定。在 Windows 上可使用 .\mihomo.exe -t -f .\profile-test.yaml，實際執行檔名稱以安裝內容為準。測試成功只表示核心接受這份設定，並不代表遠端節點可連線，也不代表系統流量已經經過代理。
YAML 縮排使用空格，不要使用 Tab。策略群組引用的名稱必須與節點或其他策略群組名稱一致；若規則寫成 DOMAIN-SUFFIX,example.com,Route，Route 就必須存在。測試若回報行號，請先檢查該行附近的縮排、冒號與清單符號，再確認欄位是否相容。
匯入、命名與更新週期
匯入訂閱設定的步驟
- 開啟 Clash 用戶端的設定管理頁面，選擇遠端匯入或新增訂閱。入口名稱可能是「設定」、「Profiles」或「訂閱」，請以實際用戶端為準。
- 貼上來源提供的完整網址。保留查詢參數，不要手動刪除權杖；並確認回傳格式受目前使用的核心支援。
- 等待取得完成，確認節點、策略群組與規則都已載入，再選擇啟用這份設定。
- 查看記錄檔中的載入結果。如果介面只顯示「下載成功」，還要確認後續載入設定時沒有發生錯誤。
名稱標示來源與用途
建議使用 A來源-日常-遠端、B來源-備用-遠端、本機-規則測試-20260729 這類名稱。來源可辨別維護方，用途可標示切換目的，日期則方便識別測試快照。不要把訂閱權杖或密碼寫進名稱，也不要只取名為「設定1」、「設定2」。
訂閱 Profile 可以沿用固定名稱，最近更新時間交由用戶端記錄；本機測試設定則適合加上日期。測試完成後，請另存穩定版本為 本機-日常-穩定，避免長期面對多個日期副本，難以判斷該啟用哪一份。
確認更新週期的單位
日常訂閱可以先設定每 24 小時更新一次，這是管理上的建議，並非協定要求。如果用戶端以分鐘為單位，24 小時等於 1440；如果以秒為單位，則是 86400。不要將同一個數字直接套用到不同用戶端，也不要為了排查連線問題而把更新週期縮短到每分鐘一次。
設定中的 proxy-providers 或 rule-providers 若使用 interval，單位通常是秒，請依目前核心的文件確認。用戶端的 Profile 更新週期與 provider 的 interval 管理的是不同資源，兩者不能互相取代。
切換多個設定檔並驗證連線
常見的 Clash 用戶端通常一次只會啟用一份主要 Profile。設定清單中儲存十份設定記錄，不代表十份規則會同時生效。有些用戶端支援合併、覆寫或腳本處理，但這些都屬於明確設定的功能，不能因為「多選幾份訂閱」就推斷其執行方式。
切換前記錄四項狀態
- 主要設定：目前的 Profile 名稱，以及是否有本機覆寫。
- 代理模式：規則、全域或直連，避免將模式變更誤認為設定問題。
- 入口連接埠：例如目前的混合連接埠是否仍為 7890，以及外部應用程式是否使用相同連接埠。
- 流量接管方式：系統代理與 TUN 的開關狀態，以及系統所需的權限。
- 點選目標 Profile，等待用戶端完成載入。載入期間不要連續選取多份設定。
- 開啟策略群組，確認選項存在且符合用途。如果原本的節點名稱已不在清單中，請重新選取有效節點。
- 送出新的連線要求，並在連線清單中查看符合的規則與最終策略，不要只依賴延遲測試。
- 如果結果異常，請切回上一份已知可用的設定，再逐項比較差異。
切換後，既有的長連線可能仍沿用舊的連線路徑；瀏覽器、下載工具與訊息應用程式也可能重複使用原有連線。驗證時請建立新的連線，必要時關閉目標應用程式的舊連線。有些用戶端提供關閉連線的功能，但執行後會中斷進行中的傳輸，請先確認沒有重要的下載或工作階段。
使用指定連接埠驗證入口
如果目前的混合連接埠確實是 7890，可以使用以下指令，強制 curl 經由本機 HTTP 代理入口連線，不依賴系統代理設定：
curl --proxy http://127.0.0.1:7890 --head https://example.com這個指令用來確認要求能否透過該入口完成，不能單獨證明使用了遠端代理節點。還要在連線記錄中確認最終策略；如果規則符合 DIRECT，要求就會直接連線。如果實際連接埠是 7897，必須將指令中的連接埠一併改為 7897。
TUN 模式是在系統層接管流量，並不是 Profile 的另一種說法。切換到新設定後，即使 TUN 仍然開啟，DNS、路由與分流結果也可能改變。先在未開啟 TUN 的情況下測試指定的代理連接埠，再檢查 TUN 接管，通常更容易分辨是設定問題還是系統權限問題。
管理更新覆蓋與本機修改
直接修改遠端訂閱下載的 YAML，下一次更新時可能會覆蓋修改內容。若要長期維護連接埠、規則或 DNS，應優先使用 Clash 用戶端明確提供的覆寫、合併或擴充功能；若沒有這些功能，可以複製一份改成本機設定管理，但後續也要自行同步節點。
依內容劃分維護責任
| 內容 | 建議維護位置 | 更新後檢查項目 |
|---|---|---|
| 節點位址與驗證資訊 | 可信任的訂閱來源或節點提供者 | 確認節點仍存在，且驗證資訊有效 |
| 本機監聽連接埠 | 用戶端設定或明確的覆寫層 | 確認執行中的連接埠與應用程式代理位址一致 |
| 個人網域規則 | 本機規則擴充或自行管理的設定 | 確認規則順序與策略名稱正確 |
| DNS 與 TUN | 選定明確的管理位置 | 確認執行值、系統權限與路由設定相符 |
規則順序尤其重要：一般規則通常由上往下比對。如果把新的網域規則放在 MATCH 之後，就不會依預期處理這些連線。覆寫清單時，也要確認用戶端是取代整份清單，還是插入清單開頭或結尾；不同實作方式不可直接套用。
修改前先儲存一份已知可用的設定，並記錄用戶端名稱、核心版本與覆寫內容。每次只調整一類設定，例如先改規則，再改 DNS。這樣更新後若發生問題，就能復原特定變更，不必重設整個用戶端。
常見問題與整理清單
訂閱更新成功，為什麼節點沒有變化？
可能是來源內容沒有變動，也可能是節點來自獨立的 provider，需要另外更新該提供者。還要確認更新的是目前啟用的 Profile，而非清單中的備用設定。用戶端顯示的更新時間，不代表節點一定有更新。
設定匯入成功，為什麼無法連線？
匯入、解析、載入與實際連線是不同階段。請依序檢查記錄檔是否顯示載入成功、策略群組是否選取有效節點、7890 等實際連接埠是否正在監聽，以及應用程式是否透過系統代理或 TUN 接管流量。節點延遲測試成功，也不代表所有網站都會符合相同策略。
可以合併兩份訂閱嗎？
可以使用支援的設定合併機制或自行管理的 provider 組織節點，但不能直接把兩個 YAML 檔案接在一起。同名頂層欄位、重複的節點名稱、策略群組參照與規則順序都需要處理。入門時保留兩份獨立 Profile，依用途切換，會更容易驗證與復原。
移轉到另一台裝置時需要複製哪些內容？
除了設定檔，也要記下訂閱來源、更新週期與本機覆寫。移轉後重新確認連接埠、系統代理與 TUN 權限；桌面平台的路徑、網路介面名稱與路由設定，不應直接套用到手機。複製檔案前，請先確認儲存位置與傳輸方式適合存放帳號憑證。
- 保留一份日常設定、一份備用設定與一份測試設定，並及時清理確認不再使用的副本。
- 遠端設定記錄來源與更新週期；本機設定記錄修改日期與用途。
- 更新後檢查載入結果；切換後檢查新連線符合的規則與最終策略。
- 修改前先備份；遇到問題時，先切回已知可用的設定，再找出具體差異。
管理 Profile 的重點在於區分來源、內容與執行狀態。將遠端更新與本機修改分開，並在每次切換後驗證連線，才能在節點變更、用戶端升級或裝置移轉時，讓設定有跡可循，也能隨時復原。