Clash Profile 設定檔是什麼?訂閱連結、本機設定與多設定檔切換管理
了解 Profile 與訂閱的差異、遠端設定和本機 YAML 的用途、更新間隔,以及如何在用戶端管理多份設定檔並依情境切換。
Profile、訂閱連結與執行設定
在 Clash 類用戶端中,Profile 通常指可儲存、更新並啟用的設定檔。介面上可能稱為「設定」、「訂閱」或「Profiles」。它不是單一節點,也不是獨立的代理協定。對 mihomo 核心而言,實際運作的是用戶端最後載入的設定內容,包括節點、策略群組、規則、DNS 和監聽連接埠等設定。
訂閱連結是取得遠端內容的網址。用戶端會連線至該網址,將回應內容儲存為本機設定檔,再進行檢查與載入。因此,連結、已下載的檔案,以及核心目前執行的設定,是三個不同層次。介面新增訂閱項目,不代表它已啟用;檔案下載成功,也不代表目前的核心能接受其中所有欄位。
| 項目 | 儲存內容 | 主要用途 |
|---|---|---|
| 訂閱連結 | 遠端網址,通常包含存取憑證 | 重新取得服務端發布的設定 |
| 遠端 Profile | 已下載的設定檔及更新相關資訊 | 保留來源,視需要或依排程更新 |
| 本機 Profile | 手動建立或匯入的 YAML 檔案 | 自行維護節點、規則與設定結構 |
| 執行設定 | 用戶端處理後交給核心的設定 | 決定目前連線如何解析及傳送流量 |
完整設定檔與節點訂閱的差異
並非所有標示為「訂閱」的回應都能直接當作完整 Profile 使用。完整的 mihomo 設定可以包含 proxies、proxy-groups、rules 等欄位;只有節點的資源則可能供 proxy-providers 使用。其他格式的節點清單,則需要用戶端明確支援匯入或轉換功能。不能只看副檔名判斷是否相容。
遠端設定與本機 YAML 的維護範圍
遠端設定:主要內容由來源維護
遠端 Profile 適合持續接收節點變更和服務端規則調整。常見操作流程為「設定」→「新增」或「匯入」→「URL」,貼上來源提供的相容連結,下載完成後再選取啟用。各用戶端的選單名稱不盡相同,請以目前版本的介面為準,並確認項目的來源類型與啟用狀態。
直接編輯遠端設定的下載副本,可能在更新時被覆蓋。下次更新可能重新產生節點、策略群組和規則,導致手動新增的網域規則消失。若要長期保留修改,優先使用用戶端提供的覆寫、合併或指令碼功能;這些功能屬於用戶端層級,並非所有 mihomo 用戶端的實作都相同。
本機設定:由檔案維護者負責
本機 YAML 適合測試規則、離線備份或固定使用情境。即使檔案最初來自某個訂閱,也不會自動持續更新。若檔案內使用遠端 provider,對應資源仍可依自身設定更新;這和整份本機 Profile 被遠端取代是兩回事。
以下是用來了解結構的直連設定。它沒有遠端節點,不能用來連接代理服務。範例監聽 7890 混合連接埠,允許 HTTP 與 SOCKS 用戶端連線,並透過規則將流量交給可選取的策略群組。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies: []
proxy-groups:
- name: 日常出站
type: select
proxies:
- DIRECT
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,日常出站
proxies用來儲存內嵌節點;範例是空清單,因此沒有可用的代理節點。proxy-groups會將出站項目整理成策略群組。規則引用的群組名稱必須確實存在,而且名稱必須完全一致。rules會由上而下比對。前面的網域規則優先比對,最後一條MATCH則處理其餘流量。mode: rule表示使用規則模式,但不會自動替作業系統啟用系統代理或 TUN。
區分來源檔案與有效設定
部分用戶端會以介面設定接管連接埠、DNS 或 TUN,再將這些值合併至 Profile。此時來源檔案即使寫著 mixed-port: 7890,實際執行時仍可能採用介面中的其他連接埠。遇到設定不一致時,請查看用戶端的「執行設定」、「有效設定」或相關記錄,而不是一再修改來源檔案。
訂閱更新間隔與資源重新整理
整份遠端 Profile 的定時下載,通常由用戶端負責。proxy-providers 和 rule-providers 的資源更新,則可由 mihomo 依各自的 interval 執行。這是兩種不同的計時機制,更新其中一項不代表另一項也會同步變更。
| 更新層級 | 設定位置 | 間隔說明 |
|---|---|---|
| 遠端 Profile | 用戶端的訂閱項目設定 | 介面可能以分鐘或小時為單位,請確認單位 |
| HTTP 代理 provider | 對應的 proxy-providers 項目 | interval 通常以秒為單位,3600 秒為 1 小時 |
| HTTP 規則 provider | 對應的 rule-providers 項目 | interval 以秒為單位,86400 秒為 24 小時 |
依來源更新頻率設定
- 先在「設定」→ 對應的訂閱項目 →「編輯」或「設定」中,確認更新功能是否已啟用,以及時間單位。
- 若來源沒有特別要求,可先將遠端 Profile 的更新間隔設為 24 小時,再依節點變動頻率調整。這是管理建議,並非核心預設值。
- 手動更新一次,查看完成時間和錯誤訊息,再確認設定是否已重新載入。
- 裝置進入睡眠後,不要假設排程工作仍會持續執行。網路恢復後請查看最後更新時間,必要時手動重新整理。
不要用每分鐘重新抓取來處理連線故障。頻繁請求可能觸發來源站的流量限制,也無法修正密碼錯誤、DNS 故障或規則比對錯誤。更新操作是為了確認「設定內容是否過期」;連線記錄則用來查明「這次連線經過哪裡」。
更新成功,但節點沒有變化
先確認更新的是目前啟用的項目,而不是清單中名稱相近的另一份設定。接著檢查節點來自內嵌清單還是 provider:若節點位於 provider 中,重新下載 Profile 可能只會取得相同的 provider 定義。也要區分檔案下載成功與核心重新載入成功;若用戶端繼續使用舊設定,網路可能仍正常,但新內容其實尚未生效。
覆寫規則與訂閱更新並行管理
讓來源維護遠端節點,並將本機分流需求保留在覆寫層,是較容易長期維護的做法。例如,若工作服務網域需要直連,而其他流量繼續使用訂閱策略,只需維護相關規則,不必複製整份遠端節點清單。
- 確認用戶端支援將合併設定套用至單一 Profile,還是所有 Profile 共用全域覆寫。
- 確認規則的插入位置。若規則加在既有的
MATCH之後,就不會有機會比對。 - 檢查合併策略:清單是整份取代、加在前面還是加在後面,取決於用戶端的實作,不能假設 YAML 合併會自動串接規則。
- 重新載入後檢查有效設定,確認規則順序及引用的策略群組名稱。
例如,DOMAIN-SUFFIX,example.com,DIRECT 表示該網域及其子網域直連。若要將某類連線導向訂閱中的策略群組,必須使用訂閱內實際存在的群組名稱。來源變更策略群組名稱後,覆寫中的舊名稱也必須一併修改,否則設定檢查可能會失敗。
管理多份設定檔並依情境切換
儲存多份 Profile,不代表能同時啟用多份設定。多數桌面用戶端在同一個核心執行個體中,只會載入一份最終設定。切換 Profile 通常會重新載入規則、節點和策略群組,但不保證已建立的連線會立即切換;實際行為取決於用戶端和核心。
依用途命名,別用節點數量命名
- 日常-遠端:供穩定使用,依來源的更新策略維護。
- 工作-本機規則:保留明確的內部服務存取需求,並記錄所需的 DNS 與路由條件。
- 測試-本機副本:用來修改規則及測試新欄位,不直接覆寫日常設定。
備份檔案可命名為 daily-2026-09-09.yaml。日期方便還原舊版,但不要將訂閱權杖寫入檔名。每份設定也應記錄來源、更新方式和覆寫範圍;這些備註比記住「清單中的第三項」更可靠。
切換後的五項檢查
- 確認啟用狀態:選取目標 Profile,等待用戶端載入完成,並確認沒有出現設定錯誤。
- 確認策略群組選擇:同名策略群組可能會沿用先前的選擇;若有
profile.store-selected等持久化設定,尤其需要確認。 - 確認監聽連接埠:若應用程式手動使用
127.0.0.1:7890,新設定必須提供對應的連線入口,或同步修改應用程式設定。 - 確認接管方式:檢查系統代理、TUN 和 DNS 狀態。切換 Profile 不代表作業系統的網路設定一定會同步切換。
- 測試新連線:重新發出目標連線要求,並在連線記錄中查看命中的規則與出站路徑。必要時先中斷相關舊連線,再進行測試。
工作網路若使用專用 VPN,也要檢查 TUN 路由是否與內部 DNS 衝突。不要只以「可以連上網際網路」作為切換成功的判準;內部網域是否能正確解析、檔案服務是否能直接連線,也都是相應情境的驗收項目。
常見問題與復原步驟
匯入後出現 YAML 解析錯誤
檢查縮排是否使用空格、是否混入 Tab,以及冒號後是否缺少必要空格。也請查看下載內容的開頭:若出現 <html>、登入提示或到期說明,代表連結回傳的並非預期設定。不要把網頁錯誤內容當成 YAML 繼續修改。
提示找不到策略群組或節點
檢查 proxy-groups、proxies 和 provider 之間的引用關係。規則中的目標名稱必須能對應至現有出站項目。建議先撤銷最近新增的覆寫,再載入原始設定,以確認問題是來自訂閱還是本機修改。
更新後無法載入,但舊設定仍可使用
保留舊設定,不要先刪除所有 Profile。查看記錄中第一則與載入失敗相關的錯誤,並記下目前的用戶端與 mihomo 核心版本;GUI 版本和核心版本並不相同。若核心不支援新欄位,可依維護說明更新至相容版本,或還原先前可用的設定。
更新連線逾時或回傳存取錯誤
HTTP 401、403 通常需要檢查憑證、權限或服務端限制;429 則表示請求頻率受到限制。若連線逾時,請檢查網路、DNS,以及用戶端抓取訂閱時使用直連還是代理。不要假設更新請求一定會經過目前選取的節點。
若現有節點已失效,而下載訂閱又必須經由該節點,更新就可能陷入循環依賴。可在用戶端允許的範圍內,暫時改用能連上來源站的更新方式;取得新設定後再恢復原有設定。處理時不必反覆清空訂閱清單。
備份與日常管理清單
- 至少保留一份最近確認可用的設定,以及與其搭配的覆寫內容。
- 分別為遠端 Profile 和本機測試檔案命名,避免更新時覆蓋手動設定的規則。
- 匯出的檔案可能包含節點密碼、訂閱網址和控制介面憑證,請當作敏感檔案妥善保存。
- 移轉至其他裝置時,重新檢查連接埠占用、檔案路徑、TUN 權限和系統代理設定,不要只複製 YAML。
- 每次重大調整後,記錄啟用的 Profile、策略群組選擇和測試目標,方便重現問題與還原設定。
管理 Profile 的關鍵,是將來源、修改內容和執行狀態分開:訂閱負責提供遠端內容,本機檔案或覆寫負責保留情境需求,有效設定與連線記錄則用來確認實際行為。建立這三個層次的界線後,就能依固定步驟檢查更新和多設定檔切換,不必反覆重新安裝來排查問題。