選型對比 閱讀時間約 8 分鐘

Clash 訂閱格式解析:YAML、Base64 與通用格式互轉教學

解析常見訂閱格式的結構差異與客戶端相容狀況,說明何時需要格式轉換、轉換的基本原理,以及自建轉換服務的注意事項。

訂閱連結背後究竟是什麼

一條訂閱連結本質上是一個能被客戶端定期請求的 HTTP(S) 位址,伺服器回傳的內容才是真正的設定資料。不同廠商、不同面板產生的訂閱內容格式並不統一,常見的有三類:Clash 專用的 YAML 結構、以 Base64 編碼打包的通用節點列表,以及部分客戶端自訂的 JSON 或純文字格式。客戶端拉取訂閱後會先判斷回傳內容的類型,再依對應的解析規則把節點資訊、分流規則寫入本機設定,這一步失敗往往就是訂閱「匯入了卻用不了」的根源。

判斷格式類型不能只看連結後綴,很多訂閱位址並不帶 .yaml 之類的標記,真正起作用的是回應標頭的 Content-Type 與回應內容本身。客戶端解析器通常會先嘗試以 YAML 解析,失敗後再嘗試 Base64 解碼,兩者都不符合才會回報格式錯誤,這也是為什麼同一條訂閱在不同客戶端裡表現不一——各家解析器的容錯順序與支援範圍並不完全相同。

YAML 格式:Clash 原生設定結構

Clash 與 Clash Meta(mihomo 核心)原生識別的設定就是 YAML 文字,頂層通常包含 proxies(節點列表)、proxy-groups(策略群組)、rules(分流規則)等欄位。這種格式的優勢在於資訊完整、可讀性高,策略群組的分組邏輯、規則的比對順序都能直接呈現在文字裡,進階使用者可以直接開啟設定檔進行局部修改。

proxies:
  - name: "hk-01"
    type: ss
    server: example.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"

proxy-groups:
  - name: "自動選擇"
    type: url-test
    proxies: ["hk-01"]
    url: "http://www.gstatic.com/generate_204"
    interval: 300

rules:
  - DOMAIN-SUFFIX,github.com,自動選擇
  - MATCH,DIRECT

值得注意的是,YAML 對縮排與冒號後的空格相當敏感,手動編輯時哪怕多一個空格或漏一個冒號都會導致整份設定解析失敗。若訂閱商提供的是 YAML 直連結,通常不需要使用者手動處理,客戶端會整段拉取並覆寫或合併到本機設定,只有自建節點、手動拼接規則時才需要留意語法細節。

Base64 與通用訂閱格式的相容邏輯

Base64 格式最初是為了相容早期客戶端與線上分享場景而流行起來的:伺服器把每個節點資訊拼成一條 協定://參數 形式的連結(例如 ss://、vmess://、trojan:// 開頭),再把所有連結逐行拼接後整體做 Base64 編碼,輸出成一段沒有換行的字串。客戶端拉取後先做 Base64 解碼,還原出一行一個節點的文字,再逐行解析協定類型與參數,最終產生內部可用的節點列表。

這種格式的好處是通用性強,幾乎所有主流客戶端(不限於 Clash 系)都認得這套編碼規則,同一條訂閱可以同時餵給不同軟體使用,適合面板同時對接多種客戶端的場景。但它的侷限也很明顯:Base64 通用格式裡不含策略群組、分流規則這類結構化資訊,客戶端拿到節點後只能按自己內建的預設分組邏輯處理,規則的精細程度天生弱於 YAML 原生訂閱。部分客戶端在匯入通用格式後,規則集合是本機預置的靜態範本,更新訂閱只會替換節點,不會改變分流邏輯。

格式類型典型內容規則資訊相容範圍
YAML(Clash 原生)節點+策略群組+規則完整,可自訂Clash / Clash Meta 系客戶端
Base64 通用僅節點列表依賴客戶端本機範本絕大多數主流客戶端
自訂 JSON因面板而異部分包含分組邏輯特定面板配套客戶端

什麼時候需要做格式轉換

大多數情況下使用者不需要手動轉換,直接把訂閱連結貼進客戶端的訂閱管理介面即可,客戶端會自動識別格式並完成解析。真正需要轉換的場景集中在以下幾種:

  • 面板只提供通用 Base64 訂閱,但使用者希望在 Clash 裡使用自訂的分流規則與多層策略群組,這時需要把節點資訊轉換成 YAML 結構並補齊 rules 欄位。
  • 手上已有一批零散的協定連結(ss://、vmess:// 等),需要合併成一條能被客戶端識別的訂閱位址,方便統一管理與自動更新。
  • 從其他客戶端遷移到 Clash 系客戶端,原訂閱是專有格式,需要轉換為 YAML 才能保留原有的分組習慣。

轉換的基本原理並不複雜:先解析原始訂閱還原出結構化的節點參數(伺服器位址、埠號、加密方式、密碼或金鑰等),再依目標格式的語法重新組裝。對 YAML 目標格式而言,還需要額外產生策略群組與規則,這部分邏輯通常由轉換腳本按預設範本填入,而不是從原訂閱裡「提取」出來的,因為通用格式本身就不攜帶這些資訊。

注意

轉換後的訂閱本質上是一份新產生的設定,節點參數是否準確取決於轉換腳本對各協定欄位的解析是否完整。遇到部分節點轉換後無法連線,先檢查轉換環節是否遺漏了某個必要參數,再排查節點本身是否有效。

自建轉換服務的注意事項

有能力與需求的使用者可以自行部署開源的訂閱轉換服務,把 Base64 通用訂閱轉成帶自訂規則的 YAML 設定,再產生新的訂閱連結供客戶端拉取。自建轉換服務時有幾點值得留意:

  1. 規則範本要按需維護。轉換服務產生的策略群組與分流規則來自本機範本檔案,範本過時會導致新增的網域分類無法命中,需要定期更新維護。
  2. 轉換環節要控管存取權限。轉換服務通常需要經手原始訂閱內容,若部署在公開可存取的位址上,建議加上存取密碼或限制來源,避免訂閱資訊被無關方取得。
  3. 輸出訂閱的更新頻率要與原訂閱對齊。轉換服務一般是被動觸發或定時拉取原訂閱再產生新連結,若定時任務間隔設得太長,客戶端拿到的節點資訊會落後於面板端的實際變化。
  4. 協定欄位的解析要涵蓋全面。不同協定(Shadowsocks、VMess、Trojan、Hysteria 等)的參數結構差異頗大,轉換腳本若只涵蓋常見欄位,遇到帶插件參數或特殊傳輸層設定的節點就容易解析出錯。

對一般使用者而言,如果客戶端本身已能正常識別訂閱格式,就不需要額外引入轉換環節;轉換更多是面板營運方或有特定規則需求的進階使用者才會用到的手段,日常使用建議先確認客戶端與訂閱格式是否本身就相容,再考慮是否需要轉換。

下載Clash