2026-05-08 訂閱管理 預計閱讀 7 分鐘

Clash 訂閱格式詳解:YAML 配置、Base64 連結與格式互轉方法

Clash 生態裡流傳的訂閱連結看起來五花八門,本質上只分三類:完整 YAML 配置、Base64 編碼的節點列表、以及各協議自帶的分享連結聚合。搞清楚它們的結構差異,才能在換客戶端或換訂閱轉換工具時不丟欄位。

訂閱格式為什麼會不一樣

Clash 最早只認一種格式:一份完整的 YAML 配置檔案,裡面同時包含節點資訊(proxies)、策略組(proxy-groups)和分流規則(rules)。這份檔案既是節點清單,也是行為說明書,客戶端下載後可以直接載入運行。

但節點提供方並不總想維護一份完整規則集——大部分訂閱服務商更傾向於只發布節點本身,把規則組織的工作留給使用者或客戶端自帶的預設。這就衍生出了另外兩種更輕量的格式:Base64 編碼的節點列表和通用分享連結聚合。三種格式服務的場景不同,沒有絕對的「更好」,但混用時容易出現欄位丟失或客戶端讀不懂的問題。

完整 YAML 配置:欄位結構與適用場景

YAML 格式的訂閱本質上就是一份可以直接跑起來的 config.yaml,mihomo(Clash Meta 內核)在原有欄位基礎上擴展了不少新語法,但頂層結構基本保持一致:

config.yaml(節選)
mixed-port: 7890
mode: rule
log-level: info
dns:
  enable: true
  nameserver:
    - 223.5.5.5
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,自動選擇
  - GEOIP,CN,DIRECT
  - MATCH,自動選擇

這種格式的優勢是「開箱即用」:規則、策略組、DNS 策略全部由訂閱方維護,使用者匯入後不需要額外配置。缺點也很明顯——一旦客戶端要合併多個訂閱,或者想在原有規則基礎上加自訂分流,處理起來會比純節點列表麻煩一些,因為要做欄位級的合併而不是簡單拼接。

另外要注意,mihomo 內核新增的欄位(比如 smart 策略組類型、sniffer 域名嗅探配置)在原版 Clash 內核裡會被直接忽略或報錯,所以下載 YAML 訂閱前最好確認客戶端用的是哪種內核。

Base64 節點列表與通用分享連結的區別

如果訂閱連結返回的內容不是可讀的 YAML,而是一長串看不出規律的字元,大概率是 Base64 編碼的節點列表。這類訂閱每一行對應一個節點,格式通常是 協議://編碼後的連接參數,常見協議前綴有 ss://、vmess://、trojan://、ssr:// 等,整份訂閱再對這些行統一做一次 Base64 編碼。

解碼後的節點列表(節選)
ss://[email protected]:443#hk-01
vmess://eyJ2IjoiMiIsInBzIjoic2ctMDIi...
trojan://[email protected]:443?sni=example.net#sg-02

這種格式只描述「節點是什麼」,不包含任何分流規則或策略組資訊。客戶端訂閱解析器負責把每一行還原成節點物件,再套用客戶端本地或訂閱轉換服務提供的規則範本。它的好處是通用性強,幾乎所有支援代理協議的客戶端(不限於 Clash)都能解析;缺點是脫離了轉換工具,單純把這類連結丟進不支援自動轉換的 Clash 客戶端,大概率什麼都載入不出來,因為 Clash 原生只認 YAML。

所謂「通用分享連結聚合」,其實就是上面這種 Base64 節點列表的另一種叫法,常見於機場服務商的「訂閱連結」頁面,和純 YAML 訂閱在 URL 層面往往看不出區別,只能靠內容判斷。

客戶端之間遷移:互轉方法與工具選擇

換客戶端或者換裝置時,最常見的訴求是把 Base64 節點列表轉換成一份完整可用的 YAML 配置,或者反過來提取 YAML 裡的節點資訊用在其他軟體上。常見思路有三種:

  1. 客戶端自帶轉換:多數 Clash 客戶端(包括支援 mihomo 內核的版本)在添加訂閱時會自動識別 Base64 節點列表,內部轉換成 YAML 結構並套用預設規則範本,使用者不需要手動處理,這是最省心的方式。
  2. 訂閱轉換服務:把原始訂閱連結和一份規則範本一起提交給轉換服務,由伺服端拉取節點、套用規則、拼裝出完整 YAML,再返回一個新的訂閱位址。這種方式適合需要自訂策略組、想合併多個訂閱來源的場景。
  3. 本機腳本轉換:對節點數量不多、想完全自主控制規則的使用者,也可以手動解碼 Base64 內容,把還原出的節點參數逐個填進 YAML 的 proxies 欄位,規則和策略組自己編寫。這種方式最繁瑣,但不依賴任何第三方服務。

選擇哪種方式,主要看訂閱來源是否穩定、規則是否需要頻繁調整。如果只是臨時切換客戶端測試,優先用客戶端自帶的自動識別;如果打算長期維護一份跨客戶端通用的訂閱,訂閱轉換服務更省心。

轉換中常見的欄位丟失與規避方法

格式互轉最容易出問題的地方,往往不是節點本身連不上,而是一些「看起來無所謂」的欄位被轉換工具默默丟棄了。以下幾類欄位尤其容易在互轉中消失:

  • TLS 相關參數:比如 skip-cert-verify、sni、alpn,部分簡化版轉換工具預設不解析這些欄位,導致原本正常的節點轉換後握手失敗。
  • 傳輸層擴展:VMess/Trojan 節點常帶的 ws-opts、grpc-opts 等傳輸配置,如果轉換工具只按最基礎的協議範本解析,這部分會被整段忽略。
  • 策略組引用關係:如果原訂閱的規則裡引用了某個自訂策略組名稱,轉換後節點名稱或分組名稱發生變化,規則會匹配不到對應的組,進而全部落到預設策略。
  • DNS 與 TUN 相關配置:純節點列表本身不帶這些欄位,轉換服務補全時用的是自己的預設範本,和使用者原本習慣的 DNS 策略可能不一致,需要轉換後手動核對。

互轉之後先不要直接刪除舊訂閱。建議先在新客戶端裡試跑幾個小時,確認延遲測速、規則分流、TUN 模式(如果用到)都正常,再清理舊的訂閱記錄,避免轉換有遺漏時無法回退。

另外,不同訂閱轉換服務對協議的支援程度也不一樣,尤其是較新的協議或混淆參數,建議轉換後打開生成的 YAML 檔案,抽查幾個節點的欄位是否完整,而不是只看節點數量對不對。

三種格式對照小結

格式內容範圍典型場景直接匯入 Clash
完整 YAML 配置節點 + 策略組 + 規則訂閱方統一維護規則支援
Base64 節點列表僅節點參數機場/多協議聚合訂閱需客戶端自動轉換
通用分享連結單條或多條節點參數手動添加單個節點需轉換或手動填寫

整體來看,只要弄清楚訂閱內容到底屬於哪一類,再選擇匹配的匯入或轉換方式,大部分「訂閱匯入後沒有節點」或者「規則不生效」的問題都能提前避免。格式互轉不是玄學,核心就是確認欄位有沒有被完整保留下來。

下載Clash