Profile 不只是節點清單

Clash 用戶端中的 Profile，通常是指一份可由核心載入的設定。它可能來自訂閱網址，也可能是手動匯入的本機 config.yaml。一份可用的設定不只儲存伺服器位址，還會描述監聽連接埠、DNS 行為、代理節點、策略組、分流規則及 TUN 參數。切換 Profile，本質上就是讓用戶端重新載入整套執行狀態。

訂閱服務回傳的內容不一定是完整的 Clash YAML。有些連結會回傳 Base64 節點集合，需要透過訂閱轉換服務產生 Clash 格式；有些連結則直接回傳包含 proxies、proxy-groups 和 rules 的 YAML。成功匯入只代表文字內容已被用戶端接受，能否正常連線仍取決於欄位相容性、節點有效性及規則引用關係。

載入設定時會發生什麼

  1. 用戶端讀取 YAML，並檢查縮排、欄位類型及必要參數。
  2. Clash 或 mihomo 核心建立本機監聽連接埠，例如 HTTP 與 SOCKS 混合連接埠 7890。
  3. 核心建立節點與代理組，解析各組所引用的成員。
  4. 規則會由上至下交由比對器處理，規則集提供器則會按需下載遠端內容。
  5. 啟用 TUN 時，Android 用戶端會要求系統授權 VPN，並建立虛擬網路介面。

其中任何一步失敗，都可能出現「設定已匯入但無法啟動」。例如 YAML 縮排錯誤會在解析階段中止；策略組引用不存在的節點名稱，會在設定驗證階段報錯；遠端規則集無法連線，則可能只影響依賴該規則集的分流結果。

逐層解析 config.yaml 核心欄位

YAML 依靠縮排表示層級，通常使用兩個空格，不使用定位字元。以下是用於理解結構的精簡範例。伺服器位址、憑證與協定參數僅用來展示欄位位置，不應直接作為可連線設定使用。

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

proxies:
  - name: HK-A
    type: ss
    server: example.net
    port: 443
    cipher: aes-128-gcm
    password: example-password

proxy-groups:
  - name: 節點選擇
    type: select
    proxies:
      - HK-A
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,節點選擇
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

基本監聽與執行模式

mixed-port: 7890 表示在同一個連接埠接受 HTTP 與 SOCKS5 代理連線。桌面程式通常會將系統代理指向 127.0.0.1:7890。Android 用戶端多半透過 VpnService 或 TUN 接管流量，但混合連接埠仍可用於區域網路除錯或個別應用程式的手動設定。

  • mode: rule：依照 rules 由上至下比對，是日常使用最常見的模式。
  • mode: global：大部分流量交由全域策略組處理，不再依序判斷一般分流規則。
  • mode: direct：流量直接連線，適合暫時判斷故障是否來自代理鏈路。
  • allow-lan: false：不向區域網路裝置開放本機代理連接埠。需要共用時，也應同時檢查監聽位址與系統防火牆。
  • log-level: info：保留一般執行記錄。短時間除錯時可改為 debug，完成後再恢復。

proxies：實際出口節點

proxies 下的每個項目代表一個節點。不同協定需要不同欄位，例如 Shadowsocks 使用 cipher 與 password，Trojan 通常使用 password、TLS 伺服器名稱等參數。mihomo 也支援更多協定與擴充欄位，但這不代表所有舊版 Clash 核心都能識別。

name 是設定檔內部的引用鍵。策略組中填寫的名稱必須與節點名稱完全一致，包括空格、大小寫及符號。兩個節點若使用相同名稱，部分用戶端會拒絕載入，其他實作則可能覆蓋前一項，因此在產生訂閱時應確保名稱唯一。

proxy-groups：選擇與自動測試

策略組會將多個節點或其他策略組組合成可供規則引用的出口。常見類型包括手動選擇的 select、依測試結果選擇的 url-test、故障切換用的 fallback，以及負載分配用的 load-balance。

proxy-groups:
  - name: 自動選擇
    type: url-test
    proxies:
      - HK-A
      - SG-A
      - JP-A
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

這段設定每 600 秒執行一次測試。tolerance: 80 表示延遲差距不超過 80 ms 時，不必頻繁更換目前節點。縮短至 30 秒會增加網路請求與背景喚醒次數，行動裝置通常不需要持續高頻測試。

rules：由上至下首次比對

Clash 規則不是對每條連線執行所有判斷，而是依序尋找第一個符合的項目。更具體的網域規則應放在較寬泛的規則之前，末尾通常使用 MATCH 處理剩餘流量。若將 MATCH,DIRECT 放在第一行，後續代理規則便無法生效。

  • DOMAIN,api.example.com,節點選擇：只比對完整網域名稱。
  • DOMAIN-SUFFIX,example.com,節點選擇：比對主網域及其子網域。
  • IP-CIDR,192.168.0.0/16,DIRECT：比對指定的 IPv4 網段。
  • GEOIP,CN,DIRECT：依據 IP 地理位置資料庫進行比對。
  • MATCH,節點選擇：接收此前沒有符合任何規則的連線。

DNS、Fake-IP 與 TUN 參數如何相互作用

DNS 欄位決定網域如何解析，但不會單獨決定流量出口。網域經 DNS 模組處理後，連線仍需進入規則系統。啟用 fake-ip 時，本機 DNS 會回傳映射位址，核心再根據該映射還原網域並完成規則比對。如此可減少應用程式自行解析導致網域規則失效的問題。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: true
  dns-hijack:
    - any:53

198.18.0.0/16 是常見的 Fake-IP 映射範圍。看到應用程式連線至此網段，不代表它正在存取公網中的同名位址。mihomo 核心會維護網域與映射位址的對應關係，再將連線交由規則與目標節點處理。

何時需要使用 Fake-IP 過濾

區域網路裝置探索、部分遊戲平台，以及依賴真實區域網路位址的應用程式，可能不適合接收 Fake-IP。此時可在 fake-ip-filter 中加入精確網域或萬用字元規則。過濾範圍不宜直接擴大到所有常用網域，否則網域規則的完整性會降低，也可能再次暴露應用程式繞過代理 DNS 的問題。

TUN 設定不等於 Android 授權狀態

設定中的 tun.enable 只是核心參數。Android 是否允許建立 VPN 介面，取決於系統對 VpnService 的授權。首次啟動通常需要在系統連線要求中確認；若同一時間已有其他 VPN 應用程式執行，新介面可能無法建立。

不同 Android 用戶端對選單名稱的安排並不完全相同。常見路徑是「設定」→「參數設定」→「TUN 模式」，或在首頁服務卡片中直接啟用。修改 stack、路由排除項與 DNS 劫持設定後，應先停止服務再重新啟動，確保舊連線與路由表重新建立。

訂閱更新會覆蓋哪些內容

遠端 Profile 通常會儲存一個訂閱 URL。用戶端執行更新時，會從該位址重新下載內容，再替換對應設定的遠端快照。節點增刪、策略組成員與規則順序都可能隨新內容變更。直接編輯下載後的 YAML，下一次更新時通常會被覆蓋。

遠端內容、本機覆寫與執行設定

理解三層狀態有助於避免「明明修改了卻沒有生效」。第一層是訂閱伺服器回傳的原始設定；第二層是用戶端儲存的本機 Profile；第三層是經過覆寫、腳本或相容性轉換後交給核心的最終設定。介面顯示的內容可能屬於第二層，而日誌中的實際參數則來自第三層。

  1. 先記錄目前的 Profile 名稱與更新時間，例如 2026-07-30 09:40。
  2. 手動更新訂閱，確認回傳狀態正常，並檢查節點數量是否有變化。
  3. 開啟設定預覽，確認 proxy-groups 與 rules 是否仍引用有效名稱。
  4. 檢查「設定」→「參數設定」中的 DNS、路由與覆寫選項。
  5. 重新載入設定或重新啟動服務，再透過連線日誌確認實際命中的規則與策略組。

自動更新間隔應配合訂閱變動頻率設定。節點資訊每天只調整一次時，沒有必要每 15 分鐘下載一次。常見設定可從 1440 分鐘開始；需要臨時同步變更時，再執行手動更新。間隔過短只會增加背景請求與失敗重試。

適合保留在本機的變更

固定的區域網路直連規則、個人網域規則與裝置專用 DNS 參數，較適合放在覆寫層，而不是直接修改遠端檔案。若用戶端支援 Merge、Mixin 或覆寫功能，可將新增欄位與訂閱結果合併。合併前需要確認陣列的處理方式：有些實作會追加 rules，有些則會整體取代。

規則順序尤其敏感。個人直連規則若追加在末尾 MATCH 之後，將永遠不會命中。正確做法是將它插入寬泛規則與最終規則之前，並在日誌中檢查類似 DOMAIN-SUFFIX 或 IP-CIDR 的命中記錄。

多設定共存與切換管理

工作網路、家庭網路與測試環境可以分別儲存為不同 Profile。多設定的價值在於隔離規則與參數，而不是把所有節點堆在同一個檔案中。每份 Profile 都應使用容易識別的名稱，例如 Daily-Meta、Office-Direct 與 Lab-TUN，同時記錄來源與用途。

切換前檢查四類差異

  • 核心相容性：確認設定是否使用 mihomo 專屬欄位。舊版 Clash 核心遇到未知協定或規則集格式時，可能會載入失敗。
  • 連接埠占用：兩個本機服務若同時監聽 7890 或 DNS 連接埠 1053，後啟動的服務會出現繫結錯誤。
  • 模式狀態：部分用戶端會將 rule、global、direct 視為全域介面狀態，不一定會隨 Profile 一起切換。
  • 覆寫範圍：全域覆寫可能套用至所有 Profile，設定專屬覆寫則只會影響目前項目。

切換設定後，原有 TCP 連線可能繼續使用舊出口，直到連線關閉。驗證時應重新開啟應用程式或清除測試連線，再觀察新的日誌。只重新整理網頁不一定會觸發新連線，因為 HTTP/2 與 QUIC 都可能重複使用現有工作階段。

備份時應保存什麼

本機手寫設定應保留獨立副本，並記錄修改日期。遠端訂閱則應重點保存訂閱入口、覆寫規則與用戶端設定，不必把每次下載的暫存副本都當作主檔案。訂閱 URL 通常包含存取憑證，備份時應放在受控位置，不要貼到公開日誌、截圖或問題回報中。

從舊版用戶端遷移至 Clash Meta 或 mihomo 用戶端時，先匯入一份 Profile 進行驗證，再遷移其餘設定。重點檢查 proxy-providers、rule-providers、策略組篩選運算式與 TUN 欄位。能通過 YAML 解析不代表遠端提供器一定能下載，也不代表目前核心支援所有節點協定。

設定載入失敗的排查順序

設定問題適合分層排查。先判斷檔案能否解析，再判斷節點能否建立連線，最後確認規則是否將流量送往預期出口。跳過解析錯誤而反覆測試節點，通常無法得到有效結論。

第一層：YAML 與欄位驗證

  • 檢查冒號後是否有空格，例如 mode: rule。
  • 檢查清單項目 - 與父層欄位的縮排。
  • 包含冒號、井字號或特殊符號的名稱，可使用引號包住。
  • 檢查策略組、規則與提供器引用的名稱是否存在。
  • 查看用戶端日誌中的行號，優先修正第一個解析錯誤。

第二層：節點與網路連線能力

選擇單一節點執行延遲測試，只能說明測試 URL 的連線結果，不代表所有網站都能存取。可先將模式切換至 global 進行短時間驗證，再恢復為 rule。若全域模式可用而規則模式不可用，應檢查規則命中情況與策略組目前的選擇；若兩種模式都不可用，則繼續檢查節點參數、系統時間、DNS 與網路限制。

第三層：規則與最終出口

在日誌中找到目標網域對應的比對記錄，確認它命中了哪條規則、進入哪個策略組，以及最終選用了哪個節點。若日誌只顯示 IP 而沒有網域名稱，可檢查 DNS 是否由 Clash 接管，以及應用程式是否使用內建的加密 DNS。排查期間可將日誌等級調整為 debug，記錄完成後恢復為 info。

建立可維護 Profile 的使用習慣

設定管理的核心是區分來源與職責。訂閱負責提供節點與基礎策略，本機覆寫負責個人規則，用戶端設定則負責系統介面與應用程式行為。將三者混在同一個遠端檔案中，更新後很難判斷變更來源。

  1. 為每份 Profile 設定用途清楚的名稱，並保留來源說明。
  2. 更新前記錄目前可用的節點與策略組選擇，更新後比較關鍵欄位。
  3. 將個人規則放入可重複套用的覆寫層，並確認插入位置。
  4. 減少高頻自動測速與訂閱重新整理，行動裝置應優先控制背景喚醒。
  5. 切換 Profile 後重新建立測試連線，透過日誌驗證規則，而不是只看狀態圖示。
  6. 升級核心前檢查設定相容性，尤其是協定擴充、規則提供器與 TUN 參數。

當 Profile 被視為「節點、策略組、規則、DNS 與系統接管參數的完整快照」後，訂閱更新與多設定切換就會更容易理解。發生故障時，也能沿著設定解析、節點連線、DNS 處理、規則命中與系統路由逐層定位，而不是反覆刪除並重新匯入同一份檔案。