Clash 訂閱格式科普:YAML、Base64 節點列表與通用格式的差異及轉換方法

訂閱連結背後到底是什麼

一條訂閱連結本質上只是一個 HTTP/HTTPS 地址,用戶端定時請求這個地址,拿到一份文字內容,再按某種約定的格式把文字解析成節點列表和規則。問題在於,「某種約定的格式」並不是唯一的。不同代理生態在各自發展過程中,各自定義了自己的文字結構,於是同一個「訂閱」概念下,實際流通的至少有三類主流格式:Clash 系的 YAML 設定、v2ray/Shadowsocks 系的 Base64 節點列表、以及部分面板軟體輸出的專有 JSON 格式。用戶端能不能"認得"這條連結,取決於它是否實作了對應格式的解析器。

這也是為什麼同一條訂閱連結,在 Clash 用戶端裡能正常導入,換到另一款基於不同協定堆疊的用戶端裡卻提示格式錯誤或者直接空列表——不是連結壞了,是兩邊說的不是同一種"語言"。

Clash YAML 設定:結構化、可讀、承載能力最強

Clash 與 Clash Meta(核心 mihomo)使用的訂閱格式是標準 YAML 文字,一份完整設定通常包含幾個頂層欄位:

port: 7890
socks-port: 7891
mode: rule
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,google.com,自動選擇
  - MATCH,DIRECT

可以看到,YAML 格式不僅描述了節點(proxies),還描述了節點如何分組(proxy-groups)、以及流量按什麼規則(rules)分發到哪個分組。這是它區別於其他格式的關鍵:一份 YAML 訂閱是一整套「可執行的策略」,而不只是一串地址列表。也正因為資訊量大,YAML 格式對欄位拼寫、縮排層級要求嚴格,少一個空格或者把 tab 混進縮排裡,都可能導致整份設定解析失敗。

注意:YAML 對縮排極度敏感,同一層級的欄位前面的空格數量必須完全一致,禁止用 Tab 鍵縮排。手動編輯設定檔時,建議用支援 YAML 語法高亮的編輯器,肉眼很難發現少一個空格的問題。

Base64 節點列表:輕量,但只是"位址清單"

另一類常見格式來自 Shadowsocks、V2Ray、Trojan、VLESS 等協定各自的用戶端生態。這類訂閱打開後往往是一整段沒有換行、看起來毫無規律的字串,例如以 c3M6Ly8... 開頭。這其實是把多條節點連結(每條形如 ss://…、vmess://…、trojan://…)用換行拼接後,再整體做一次 Base64 編碼,目的是方便在二維碼、純文字環境裡傳輸,避免特殊字元被轉義破壞。

解碼之後,每一行大致是這樣的結構(以 Shadowsocks 為例):

ss://[email protected]:443#HK-01
vmess://eyJ2IjoiMiIsInBzIjoiSEstMDIiLCJhZGQiOiJleGFtcGxlLmNvbSJ9
trojan://[email protected]:443?sni=example.com#HK-03

這類格式的資訊密度比 YAML 低得多:它只描述"有哪些節點、地址是什麼、用什麼加密",不攜帶分組策略,也不攜帶分流規則。用戶端拿到這份列表後,規則怎麼定、節點怎麼分組,完全由用戶端自己內建的預設策略決定。這就解釋了一個常見困惑:同一條 Base64 訂閱,在兩款用戶端裡導入後,節點數量一樣,但代理模式的分組結構、預設走向卻完全不同——因為分組規則從來不是訂閱內容的一部分,是用戶端自己補上的。

為什麼有的連結導入後沒有節點或者直接報錯

結合上面兩種格式的差異,訂閱導入失敗基本可以歸納為幾類原因:

格式不匹配。把一條純 Base64 節點列表當成 Clash YAML 硬塞進去,用戶端按 YAML 解析器去讀一段亂碼字串,自然直接報格式錯誤;反過來,把 YAML 設定檔內容當作 Base64 去解碼,也會得到無意義的亂碼。
協定欄位不被支援。YAML 裡 type 欄位寫的協定類型(比如某些較新的傳輸層擴充參數),如果用戶端核心版本較舊、還沒實作對應協定解析器,該條節點會被跳過甚至整份設定解析失敗,報錯訊息通常會指出哪一行、哪個欄位。
User-Agent 攔截。部分訂閱伺服器會根據請求的 User-Agent 回傳不同內容,給"疑似非官方用戶端"的請求回傳空內容或錯誤頁面,導入後表現為節點數為 0。
編碼或換行問題。手動複製貼上 Base64 內容時,如果不小心帶上了額外的換行符、空格,或者複製不完整,解碼後的結果會出現截斷,導致部分節點缺失或整體解析失敗。
連結本身已過期。訂閱服務商端的地址失效、流量耗盡被限制回傳內容,這類問題用戶端本身無法解決,需要聯繫訂閱提供方確認。

排查思路建議按順序來:先確認訂閱連結能否在瀏覽器裡正常打開並顯示內容,再確認回傳內容的開頭特徵(YAML 一般以 port: 或 proxies: 開頭,Base64 列表通常是一整段無空格字元),最後再檢查用戶端本身的日誌頁,大多數解析錯誤都會給出具體報錯行號。

格式之間怎麼互轉

如果手上的訂閱格式和用戶端要求的格式不一致,常見做法是使用轉換工具在中間做一次"翻譯",而不是手動改寫。目前社群廣泛使用的是 subconverter 一類的開源轉換服務,原理是:輸入原始訂閱連結,輸出目標格式(Clash YAML、通用 Base64 列表等)的新連結,用戶端直接訂閱這個轉換後的新地址即可,後續更新也會自動帶過去。

常見的兩種轉換方向

從 Base64 節點列表轉 Clash YAML:轉換服務會把每條 ss:///vmess:///trojan:// 連結解析出協定參數,填入 proxies 欄位,再根據目標用戶端類型補上一套預設的 proxy-groups 和 rules(部分服務允許指定規則範本)。
從 Clash YAML 轉通用 Base64 列表:轉換服務只保留 proxies 部分的節點資訊,重新拼裝成對應協定的連結格式並做 Base64 編碼,分組與規則資訊會在這一步遺失,因為目標格式本身不支援描述規則。

注意:從結構化格式轉成節點列表格式是單向資訊損耗——分流規則、分組邏輯不會被保留。如果只是臨時在另一款用戶端上應急使用,這樣做沒問題;但如果長期依賴這條轉換後的連結,建議直接找訂閱服務商索取原生對應格式的地址,而不是長期依賴二次轉換。

互轉時的安全與穩定性注意事項

轉換服務本質上是一個中間代理,原始訂閱內容會先經過轉換伺服器再到達用戶端,這裡有幾點需要留意:

優先選擇自架或可信的轉換後端。公共轉換伺服器能看到經過它的訂閱原始內容,如果訂閱裡包含帳號相關的敏感參數,盡量選擇開源、可自行部署的轉換服務,或者只用訂閱服務商官方提供的轉換介面。
轉換後核對節點數量。轉換過程中個別不被識別的協定參數可能被靜默丟棄,建議比對轉換前後節點數量是否一致,數量差異較大時檢查轉換日誌或改用其他轉換規則範本。
規則範本要匹配用戶端版本。不同的規則範本對應不同的分組習慣(比如是否單獨區分流媒體分組、是否內建某類地區分組),轉換時選擇的範本要和自己用戶端的使用習慣對上,否則會出現節點分組與預期不符的情況。
轉換連結同樣要按更新週期刷新。轉換服務通常是即時拉取原始訂閱再轉換回傳,原訂閱到期或者更換後,轉換連結會跟著失效,需要同步更新。

導入前的三步自檢

不確定一條訂閱連結是什麼格式時,可以按下面順序快速判斷,免得反覆嘗試導入報錯:

在瀏覽器地址欄直接打開訂閱連結,看回傳內容的開頭字元——出現 port、proxies、mixed-port 等欄位基本可判定是 Clash YAML;一整段無換行字元可判定是 Base64 節點列表。
確認目前使用的用戶端核心類型(Clash Meta / mihomo 核心通常相容性更全面,支援的協定類型更多),核心版本較舊時優先更新用戶端再導入。
如果格式確實不匹配,再考慮走轉換工具,並按上一節的安全建議選擇轉換後端。

把這三步走完之後,絕大多數"訂閱導入失敗""節點列表為空"的問題都能定位到具體環節,而不需要反覆試錯。