Clash 設定檔（Profile）是什麼：結構解析與多設定切換管理方法

Profile 不是訂閱網址，而是核心實際讀取的執行設定

在 Clash、Clash Meta 或 mihomo 用戶端中，Profile 通常譯為「設定」或「設定檔」。它最終是一份 YAML 文件，內容不只有節點，還會定義監聽連接埠、DNS、代理群組、分流規則、TUN 參數與控制介面。核心啟動時讀取的是這份設定，而不是瀏覽器中的訂閱 URL。

訂閱網址比較像設定來源。用戶端會向訂閱 URL 發出請求，下載伺服器回傳的內容，再將結果儲存為本機 Profile。之後即使暫時離線，只要本機檔案仍在且節點憑證有效，用戶端通常仍能載入這份設定。點選「更新訂閱」時，用戶端會重新下載，並覆寫或重建對應的本機內容。

一份完整設定通常包含哪些內容

最小可執行結構會因核心版本與用戶端封裝而異，但常見欄位可分成六個層次：

• port、socks-port、mixed-port：本機代理監聽連接埠。
• proxies 或 proxy-providers：具體節點或遠端節點集合。
• proxy-groups：手動選擇、自動測速、故障轉移等策略群組。
• rules 或 rule-providers：網域、IP、程序與規則集的比對順序。
• dns：DNS 監聽、上游伺服器、Fake-IP 或 Redir-Host 行為。
• tun、sniffer、external-controller：系統流量接管、網域嗅探與控制介面。

以下是一份用來理解層級的精簡範例。連接埠 7890 作為 HTTP 與 SOCKS 混合入口，9090 作為外部控制介面。範例省略真實憑證，不應直接作為可連線設定使用。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

proxies:
  - name: Tokyo-A
    type: ss
    server: 203.0.113.10
    port: 443
    cipher: aes-128-gcm
    password: example-password

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - Tokyo-A
      - DIRECT

  - name: AUTO
    type: url-test
    proxies:
      - Tokyo-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

三大核心區段：proxies、proxy-groups、rules

理解 Profile 時，先不用從數百行 DNS 與規則集看起。掌握三個核心區段即可：proxies 提供出口，proxy-groups 組織出口，rules 決定每條連線交給哪個群組。三者形成一條由底層到上層的引用鏈。

proxies：節點本體與連線參數

proxies 是靜態節點陣列。每個項目至少包含名稱、協定、伺服器位址、連接埠與驗證資訊。不同協定還會加入不同欄位，例如 Shadowsocks 的加密方式、Trojan 的密碼與 TLS 參數、VMess 的 UUID，以及 VLESS 的流量控制與傳輸設定。

節點名稱必須能在目前設定中被辨識。代理群組會透過名稱引用節點，因此重新命名節點時，務必同步檢查 proxy-groups。如果群組仍使用舊名稱，設定驗證可能直接失敗，也可能在介面中出現空群組或無法使用的成員。

proxies:
  - name: HK-01
    type: trojan
    server: hk01.example.net
    port: 443
    password: change-me
    sni: hk01.example.net
    udp: true

大型訂閱通常不會把所有節點手動寫入主檔案，而是使用 proxy-providers。Provider 可以從遠端擷取節點集合，並依指定時間更新。它只負責「節點來源」，不會自動決定這些節點要用於哪些網站。

proxy-groups：將節點轉化為可執行策略

proxy-groups 是使用者在用戶端「代理」頁面中實際操作的物件。常見類型有四種：

群組可以引用節點，也可以引用另一個群組。常見做法是建立一個總群組 PROXY，再加入 HK-AUTO、JP-AUTO、Fallback 與 DIRECT。規則只引用總群組或業務群組，底層節點更新時就不必逐條修改規則。

proxy-groups:
  - name: Streaming
    type: select
    proxies:
      - HK-AUTO
      - JP-AUTO
      - PROXY

  - name: HK-AUTO
    type: url-test
    use:
      - provider-main
    filter: "(?i)港|HK|Hong Kong"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 100

rules：由上到下，比對後立即停止

rules 是有順序的比對清單。請求會從第一條開始檢查，比對成功後便將連線交給指定策略，不再繼續往下。精確規則應放在寬泛規則之前，最後以 MATCH 作為兜底。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - PROCESS-NAME,git.exe,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Fallback

在這段設定中，api.example.com 會直接連線。其他 example.com 子網域則經由代理。Windows 上由 git.exe 建立且能被核心辨識的連線會交給 PROXY。區域網路位址直接連線，其餘中國大陸 IP 直接連線，最後未比對到的流量交給 Fallback。

Profile 與訂閱更新：哪些內容會被覆寫

直接編輯由訂閱產生的 YAML，短期內可能有效，但下次更新時卻可能全部消失。原因很簡單：用戶端會把遠端回應視為該 Profile 的權威版本，更新時重新寫入節點、策略群組與規則。手動加入的 PROCESS-NAME、DNS 上游或自訂群組，如果沒有獨立的覆寫機制，就會被遠端內容取代。

三種來源的行為差異

1. 匯入本機檔案：從磁碟載入 YAML，通常不會自動存取遠端。適合完全自行維護的設定。
2. 匯入訂閱 URL：依用戶端設定的週期向遠端發出請求。常見更新間隔為 24 小時，也可以手動觸發。
3. 拆分 Provider：主設定保留 DNS、群組與規則，只讓 proxy-providers 更新節點。適合需要長期維護規則結構的使用者。

以常見圖形化用戶端為例，匯入路徑通常是「設定」→「新增」→「從 URL 匯入」，更新功能位於對應設定卡片的「更新」按鈕。連接埠則常在「設定」→「參數設定」→「混合連接埠」中調整。不同用戶端可能將 Profile 稱為「設定」、「訂閱」或「設定管理」，按鈕位置也可能不同，但底層關係不變。

mihomo 的 Provider 結構可以將遠端節點快取到本機檔案。以下的 interval: 86400 表示每 86400 秒，也就是每 24 小時檢查一次。健康檢查每 600 秒執行一次：

proxy-providers:
  provider-main:
    type: http
    url: https://subscription.example.net/clash
    path: ./providers/provider-main.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

如果用戶端支援覆寫、擴充腳本或 Merge 設定，建議優先將本機 DNS、規則與策略群組放入覆寫層。遠端只負責節點，個人邏輯保留在本機。如此一來，更新 80 個節點時，就不會順帶覆蓋為開發環境撰寫的直連規則。

多個代理服務、多種用途的設定如何命名與並存

設定一多，最先失控的通常不是 YAML，而是命名。清單中出現「新設定」、「訂閱 2」、「測試副本最終版」等名稱，幾週後便很難判斷哪個正在使用、哪個可以刪除。命名應直接表達來源、用途與更新時間。

建議命名格式

[來源]-[用途]-[更新方式]-[日期]

A站-日常-自動-20260625
B站-串流媒體-自動-20260625
本機-開發分流-手動-20260625
緊急-基本直連-手動-20260625

日期不必每次節點更新都修改，更適合用來記錄設定結構最後一次人工調整的時間。自動訂閱的更新時間交給用戶端記錄，否則每天重新命名只會製造雜訊。

按來源拆分，還是按用途拆分

剛開始使用時，每個來源保留一份 Profile 最省事。規則需求穩定後，再遷移至「一份主設定加上多個 Provider」。不建議一開始就把所有來源、數十個業務群組與上萬條規則塞進同一個檔案，任何縮排錯誤都會擴大排查範圍。

保留一份緊急設定

緊急設定不需要複雜。保留一個可用節點、一個 select 群組、幾條基本規則，並關閉非必要的 TUN 與複雜 DNS。主設定更新失敗、規則集網址無法連線或 TUN 驅動程式異常時，可以切換至緊急設定，先恢復基本連線再進行排查。

緊急設定應使用本機 YAML，不要依賴每次啟動都下載遠端規則集。每月手動載入一次，確認設定能通過驗證、節點仍可連線，且 7890 連接埠未被其他程式佔用。

切換 Profile 時，用戶端內部發生了什麼

切換 Profile 不只是更換節點清單。用戶端通常會停止或重新載入目前的核心，將新的 YAML 交給核心驗證，接著重新建立監聽連接埠、DNS、TUN 網卡與策略狀態。設定越複雜，重新載入涉及的系統元件就越多。

舊連線不一定會自動遷移

在切換前已建立的 TCP 連線可能會中斷，也可能維持到逾時，具體取決於用戶端的重新載入方式。新連線會依照新規則處理。正在下載大型檔案、執行 Git 推送或維持 SSH 工作階段時，不要任意切換 Profile。

一次可重現的切換檢查可以這樣進行：先在連線面板確認活動連線數，例如 23 條；停止下載工作；切換設定；等待核心狀態恢復為「執行中」；再開啟測試網域，檢查新連線命中的規則。在常見桌面環境中，簡單設定可於 1 至 3 秒內完成重新載入；啟用 TUN、遠端規則集與大量 Provider 時，可能需要更久。

策略選擇可能會被記住，也可能被重設

部分用戶端會依策略群組名稱保存上次的選擇。例如兩個 Profile 都有名為 PROXY 的群組，切換後用戶端可能會嘗試恢復上次選取的節點。但如果新設定中沒有同名節點，就會退回該群組的第一個可用成員。

因此，多個設定共用相同策略語意時，可以統一使用 PROXY、Streaming、Fallback 等群組名稱。不同語意不要硬套相同名稱，否則介面看似保留了選擇，實際出口邏輯卻已經改變。

切換 TUN 設定時要額外檢查

TUN 模式會接管更多系統流量。兩個 Profile 如果分別設定不同的 stack、DNS 劫持或路由排除項目，切換時可能需要重建虛擬網卡與路由表。切換後應檢查：

• TUN 狀態是否重新啟用，而不只是保留系統代理。
• 區域網路位址，例如 192.168.1.1，是否仍可直接連線。
• DNS 請求是否交由新設定的監聽連接埠處理，例如 0.0.0.0:1053。
• 需要排除的程序或網段是否仍在 route-exclude-address 中。
• 瀏覽器、命令列與不讀取系統代理的軟體是否都依預期進行分流。

一套可執行的設定管理流程

管理 Profile 不需要複雜工具。關鍵是將匯入、驗證、切換與回復分開處理，不要在目前唯一可用的設定上直接試錯。

第一步：複製後再修改

修改 DNS、TUN 或規則前，先複製目前設定並加上日期。保留原設定不動。若用戶端沒有複製功能，就匯出 YAML 並儲存至獨立資料夾。修改版本先命名為「測試」，驗證完成後再取代主要設定。

第二步：先進行語法驗證

YAML 使用空格表示層級，Tab、錯位縮排與缺少引號都可能導致載入失敗。尤其要檢查含有冒號的名稱、正規表示式與 URL。若核心錯誤訊息出現具體行號，先查看該行上方的清單縮排，因為錯誤位置經常是解析器最終無法繼續的位置，不一定是問題起點。

# 容易出錯：群組名稱含冒號但沒有引號
- name: Work: Git

# 更穩妥
- name: "Work: Git"

第三步：依固定樣本驗證分流

準備四類固定樣本：一個中國大陸網域、一個需要代理的網域、一個區域網路位址，以及一個指定程序。開啟用戶端連線日誌，逐項確認規則類型、命中策略與最終節點。不要只用瀏覽器查 IP，因為瀏覽器快取、HTTP/3 與既有連線都可能干擾判斷。

1. 中國大陸網域應命中 DIRECT 或預期的中國大陸策略。
2. 代理網域應命中業務群組，而不是直接落到最後的 MATCH。
3. 192.168.0.0/16 等私有網段應維持直接連線。
4. 指定程序規則應在對應程式建立新連線後出現。
5. DNS 日誌不應持續出現逾時或循環查詢。

第四步：記錄回復點

確認目前穩定設定的檔名、混合連接埠、TUN 開關與主要策略選擇。測試設定異常時，依「設定」→「穩定設定」切回，再到「設定」→「參數設定」確認 7890 等連接埠已恢復。若核心沒有自動重新啟動，手動執行一次「停止」再「啟動」。

常見問題：匯入成功但設定無法使用

設定清單存在，代理群組卻是空的

先確認 proxies 中是否有節點，或 proxy-providers 是否下載成功。再檢查群組中的 proxies 名稱與 Provider 的 use 名稱是否完全一致。名稱區分大小寫，額外空格也會造成引用失敗。

更新後自訂規則消失

這是直接修改訂閱成品的典型結果。將自訂內容移至用戶端覆寫層，或建立本機主設定，透過 Provider 引入遠端節點。若用戶端不支援覆寫，就保留本機副本並手動合併，不要再把訂閱快取檔案當作長期編輯入口。

切換設定後瀏覽器仍使用舊節點

先開啟新的無痕視窗或完全關閉瀏覽器，排除連線重用。再查看連線面板是否產生新連線。如果新連線仍使用舊節點，請檢查同名策略群組是否恢復了歷史選擇，以及規則是否實際引用了另一個群組。啟用 TUN 時，還要確認虛擬網卡已依新設定重新載入。

規則已加入，卻始終命中 MATCH

檢查規則順序、網域類型與 DNS 行為。DOMAIN 只會比對完整網域，DOMAIN-SUFFIX 才會涵蓋子網域。IP 規則需要連線目標取得對應 IP；使用 no-resolve 時，不會為了比對主動觸發 DNS。程序規則還取決於平台與核心是否能取得程序資訊。

結論：將 Profile 視為可版本管理的執行設定

Profile 的核心不在於「安裝了多少節點」，而在於將入口、出口、策略與比對順序組織成一份核心可執行的設定。proxies 提供出口，proxy-groups 組合策略，rules 分配連線；DNS 與 TUN 則決定網域及系統流量如何進入這條鏈路。

多個設定並存時，使用易讀的命名，分清自動訂閱與本機設定，並保留一份緊急 Profile。更新後檢查節點、策略群組與規則命中；切換前停止關鍵連線，切換後驗證連接埠、DNS 與 TUN。如此即使訂閱變動或規則損壞，也能快速回到可運作的狀態。