Clash 訂閱連結是什麼格式:Base64、YAML 與各用戶端訂閱格式互轉教學

訂閱連結是什麼:一個定時拉取的遠端清單

訂閱連結是一個普通的 HTTPS 位址。用戶端按固定間隔向這個位址發起 GET 請求,伺服端回傳一段文字,用戶端解析文字並刷新本機節點清單。整個機制與 RSS 閱讀器拉取 feed 沒有本質差異:位址只是通道,回傳內容的格式才是決定能不能用的關鍵。

三個基本事實先講清楚:

訂閱連結不是協定。它不決定流量怎麼走,只是一份會定期更新的節點清單的取件位址。
連結裡的 token 等同於帳號憑證。常見訂閱位址形如 https://example.com/api/v1/client/subscribe?token=xxxxxxxx,這串字元就是身分標識,誰拿到誰就能占用你的套餐流量。懷疑外流時,第一件事是去服務商後台重設訂閱連結。
同一位址可以回傳多種格式。伺服端按請求標頭裡的 User-Agent 或 URL 參數判斷用戶端類型,分別回傳 Base64 清單或 Clash YAML,這就是「一條連結適配多個用戶端」的常見實作方式。

Base64 訂閱:按行排列的節點分享連結

Base64 訂閱是 V2Ray 生態圈形成的通用交換格式。伺服端回傳一整段 Base64 文字,解碼後每行是一條節點分享連結,形如:

ss://[email protected]:8388#HK-01
vmess://eyJ2IjoiMiIsInBzIjoiSEstMDIifQ==
trojan://p%[email protected]:443?sni=cdn.example.com#HK-03

每行自帶完整連線參數:協定前綴、位址、埠、憑證、傳輸層與 TLS 參數,以及 # 號後的顯示名稱。常見前綴含義如下:

ss:// —— Shadowsocks,遵循 SIP002 規範,@ 之前是 method:password 的 Base64。
vmess:// —— VMess,整段是一個 JSON 物件的 Base64。
vless:// —— VLESS,參數走 query 字串。
trojan:// —— Trojan,密碼放在 userinfo 段。
hysteria2://(或 hy2://)、tuic:// —— 基於 QUIC 的協定,只有 mihomo 等新核心支援。

這種格式跨用戶端通用、逐節點獨立,單條連結可以單獨分享;缺點是不含策略組與分流規則,匯入後規則要用戶端自己補齊。另一個常見的坑:ssr://(ShadowsocksR)不在 Clash 與 mihomo 的支援範圍內,混入 SSR 節點的訂閱匯入後這部分會被直接捨棄,節點數量對不上時先查這一點。

Clash YAML:節點、策略組、規則三位一體

Clash 原生訂閱格式是一份完整的 YAML 設定檔,最少包含三個頂層欄位:

mixed-port: 7890
allow-lan: false
mode: rule
proxies:
  - name: "HK-01"
    type: ss
    server: 203.0.113.10
    port: 8388
    cipher: aes-256-gcm
    password: "password"
proxy-groups:
  - name: "自動選擇"
    type: url-test
    proxies: ["HK-01"]
    url: http://www.gstatic.com/generate_204
    interval: 300
rules:
  - GEOIP,CN,DIRECT
  - MATCH,自動選擇

proxies:節點清單,欄位與 Base64 分享連結一一對應,只是換成 YAML 寫法。
proxy-groups:策略組,常見類型有手動選擇 select、自動測速 url-test、負載平衡 load-balance、容錯移轉 fallback。
rules:分流規則,按網域、IP 段、GEOIP 等條件把流量分給直連、代理或拒絕。

拿到 YAML 訂閱等於拿到開箱即用的完整設定:節點、分組、規則一次到位。代價是格式與 Clash 系綁定,其他生態的用戶端讀不了。還要注意核心差異:mihomo(Clash Meta)支援 vless、hysteria2、tuic、wireguard 等節點類型,已停更的舊版 Clash 核心遇到不認識的類型會解析失敗或直接跳過該節點。

各用戶端可直接匯入的訂閱格式對照

下表按核心列出本站收錄用戶端可直接匯入的訂閱格式:

用戶端	核心	可直接匯入的訂閱格式
Clash Verge Rev	mihomo	Clash YAML、Base64 分享連結
Clash Plus	mihomo	Clash YAML、Base64 分享連結
FlClash	mihomo	Clash YAML、Base64 分享連結
ClashX Meta	mihomo	Clash YAML、Base64 分享連結
Clash for Android	Clash(停更)	Clash YAML
Clash for Windows	Clash Premium(停更)	Clash YAML
Surfboard	Surge 相容	Surge 格式設定

規律很簡單:mihomo 核心的用戶端兩種格式都吃,匯入 Base64 訂閱時會在本機把每條分享連結解析成 proxies 項目,再套一層預設策略組與規則;舊版 Clash 核心只認 YAML;Surfboard 走 Surge 設定體系,Clash 訂閱需要先轉換。所以選用戶端時如果訂閱只有 Base64 一種輸出,優先選 mihomo 核心的用戶端,可以省掉轉換這一步。

格式互轉的三種方法

方法一:訂閱轉換器(線上或自架)

訂閱轉換器是一個中間服務:你把原始訂閱位址交給它,它拉取節點清單,按你指定的目標格式重新組裝後回傳。轉換後的位址一般形如:

https://sub.example.com/sub?target=clash&url=原始訂閱位址的URL編碼&config=規則範本

target 參數決定輸出格式(clash、surge、quanx 等),config 參數指定外掛的規則範本。轉換器同時解決了兩個問題:格式不相容,以及 Base64 訂閱缺少規則的問題。

公開轉換站點的憑證風險

把訂閱位址交給第三方轉換器,等於把 token 明文交給對方伺服器,對方能看到你的全部節點與用量。敏感套餐建議自架轉換後端(subconverter 開源可自行部署),或改用支援直接匯入的 mihomo 用戶端,繞過中間環節。

方法二:用戶端內建解析

Clash Verge Rev、Clash Plus、FlClash 等 mihomo 用戶端在新增訂閱時直接貼上 Base64 訂閱位址即可,核心會自動識別內容類型並完成轉換,無需任何外部工具。這是目前最省事的方式,也是建議新手優先採用的做法。

方法三:手動解碼與改寫

排查問題或只需要個別節點時,可以手動處理。Base64 訂閱解碼只需要一條指令:

curl -s "訂閱位址" | base64 -d

解碼後逐行檢查節點連結,確認協定前綴是否在核心支援清單內。需要轉成 YAML 時,按上一節的 proxies 欄位格式逐條抄寫即可,節點數量少時手動方式反而比架設轉換器更快。

匯入失敗的排查順序

訂閱匯入報錯或節點為空時,按下面的順序逐項排除,命中率由高到低:

先用瀏覽器直接開啟訂閱位址。能回傳文字代表連結有效;回傳 401/403 是 token 失效,回傳 404 是路徑變更,都需要去服務商後台重新取得。
確認回傳內容的格式。瀏覽器裡看到一大段無空格密文是 Base64;看到 proxies、rules 等欄位是 YAML。格式與用戶端不匹配就走轉換。
檢查節點協定是否被核心支援。含 ssr:// 的訂閱在 Clash 系列裡這部分節點會被捨棄;含 hysteria2、tuic 的訂閱只有 mihomo 核心能識別。
檢查本機網路。訂閱位址本身被封鎖時,需要先有一次可用代理才能拉取,可在用戶端裡開啟「使用系統代理更新訂閱」之類的選項,或先手動匯入一個節點救急。
檢查 YAML 語法。手動編輯過的設定檔常見縮排錯誤、全角冒號、未轉義的特殊字元,用戶端日誌裡一般會給出錯誤行號。

訂閱連結的安全與日常維護

訂閱位址請視同密碼對待。不發到群組、不截圖外流、不提交到來路不明的線上轉換站。
外流後立即重設。服務商後台一般提供「重設訂閱連結」按鈕,重設後舊位址即刻失效,各用戶端裡的訂閱位址需要同步更新。
更新間隔不必太短。節點清單變化頻率低,用戶端預設的 24 小時或 12 小時就足夠;頻繁拉取只會增加伺服端負擔,部分服務商還會限制頻率。
多用戶端共用一條訂閱時留意格式。在 mihomo 用戶端與舊核心用戶端混用的情況,以伺服端能輸出 Clash YAML 為前提,否則舊核心那台需要單獨走轉換位址。

總結一下判斷邏輯:拿到訂閱位址先看回傳格式,Base64 走 mihomo 用戶端直接匯入或轉換器,Clash YAML 全系列 Clash 用戶端都吃得下,Surge 系用戶端單獨轉換。格式問題解決了,剩下的就是常規的分流規則與策略組調整,這部分可以對照本站設定教學逐項設定。