Clash 訂閱格式詳解:YAML 設定、Base64 連結與通用訂閱互轉方法

三種常見訂閱格式的本質區別

把一條訂閱連結丟進瀏覽器打開,回傳的內容形態並不統一。多數排障問題的起點,其實是沒先分清回傳的到底是哪種格式,就直接假設用戶端「應該認得」。目前流通的訂閱內容大致分三類,處理邏輯完全不同。

• Clash YAML 設定:回應本身就是一份完整的 YAML 文件,包含 proxies、proxy-groups、rules 等欄位,可以直接被 Clash / Clash Meta / mihomo 核心解析並生效,不需要任何轉換步驟。
• Base64 節點清單:回應是一整段 Base64 字串,解碼後是若干行以 vmess://、ss://、trojan:// 等協定前綴開頭的節點連結。這類格式常見於 V2Ray/V2RayN 生態,Clash 核心無法直接識別整段回應,必須先解碼再逐條轉換為 proxies 條目。
• 協定專用分享連結的裸文本合集:不經 Base64 包裝,直接把節點連結逐行列出回傳,常見於個人架設的小型面板。處理方式與 Base64 清單類似,只是省去了解碼這一步。

判斷方法很直接:用瀏覽器或 curl 打開訂閱連結,看回傳內容第一行。如果是 port:、mixed-port:、proxies: 這類 YAML 鍵值對,就是 Clash 原生設定;如果是一長串沒有換行、全是字母數字加等號結尾的字元,大概率是 Base64;如果每行都以協定名加 :// 開頭,則是裸文本節點清單。

Clash YAML 設定的關鍵欄位

能被 Clash 核心直接使用的訂閱,骨架大致如下:

port: 7890
socks-port: 7891
mode: rule
log-level: info

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

proxy-groups:
  - name: "auto"
    type: url-test
    proxies:
      - hk-01
    url: "http://www.gstatic.com/generate_204"
    interval: 300

rules:
  - DOMAIN-SUFFIX,google.com,auto
  - GEOIP,CN,DIRECT
  - MATCH,auto

其中 proxies 描述節點本身的連線參數,proxy-groups 把節點組織成策略組(自動測速、手動選擇、負載平衡等),rules 決定流量按什麼條件分配到哪個策略組。三段缺一不可,如果訂閱回傳的 YAML 只有 proxies 而沒有後兩段,多數用戶端會自動補一套預設策略組和規則,但具體行為因用戶端而異,建議匯入後打開設定檢視器確認。

如果使用的是 Clash Meta(mihomo)核心,還可能出現 proxies 裡帶 tfo、smux、reality-opts 等擴充欄位,這些是原版 Clash 不識別的新協定參數,匯入原版核心會直接報錯或跳過對應節點,這也是判斷「要不要換核心」的一個直接訊號。

Base64 節點清單的解碼與轉換原理

Base64 格式的訂閱本質上只是「把一堆分享連結打包成一段文字」,方便用戶端一次性拉取更新,它並不是加密,只是編碼。解碼之後,常見節點連結大致是這樣的結構:

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

逐條轉換的思路是固定的:

1. 先按 URL 參數拆出協定類型(ss / vmess / trojan / hysteria2 等)。
2. 把使用者資訊段(通常也是 Base64 編碼,如 ss:// 的使用者資訊部分)再解碼一次,拿到加密方式與密碼。
3. 把伺服器位址、埠、傳輸層參數(ws、grpc、TLS 相關欄位)映射成 Clash YAML 裡 proxies 條目對應的欄位名。
4. 把節點名(# 後面的部分,通常經過 URL 編碼)解碼還原成可讀名稱。

手動做這件事對單個節點沒問題,但訂閱通常包含幾十上百個節點,逐條手改基本不現實,實際操作中幾乎都依賴訂閱轉換服務完成批量轉換,下一節具體說明。

訂閱互轉的兩條常見路徑

把 Base64/裸文本訂閱轉換成 Clash 能識別的 YAML,常見做法分兩類,各有取捨。

路徑一:用戶端內建轉換

部分 Android 用戶端在「新增設定」或「匯入訂閱」環節內建了格式偵測邏輯:貼上連結後用戶端先嘗試按 Clash YAML 解析,失敗則自動按 Base64 解碼再逐條轉換生成本機設定。這條路徑不依賴第三方服務,資料全程在本機處理,是隱私角度最乾淨的方案,但轉換能力取決於用戶端本身對協定欄位的支援程度,遇到較新的傳輸層參數(例如某些 hysteria2 混淆參數)可能轉換不完整或直接丟棄對應節點。

路徑二:訂閱轉換服務中轉

另一種做法是把原始訂閱連結交給一個轉換服務,由伺服端完成解碼與格式重寫,再把生成的 Clash YAML 連結交給用戶端訂閱。這類服務通常支援自訂參數,常見的有:

• target:目標格式,填 clash 或 clashr。
• url:原始訂閱位址,多個訂閱用 | 分隔可以合併處理。
• config:遠端規則範本位址,決定生成的 proxy-groups 和 rules 結構,不填則走轉換服務的預設範本。
• emoji / udp / tfo:布林參數,控制節點名前是否加國旗表情、是否強制開啟 UDP 轉發與 TCP Fast Open 標記。

這條路徑的優勢是轉換能力更強、範本可重複使用,適合需要統一多個訂閱來源命名規則、合併去重的場景;代價是原始訂閱連結(包含帳號身分資訊)會經過第三方伺服器,存在隱私暴露面,選擇時要留意服務是否公開聲明日誌政策,更謹慎的做法是自建開源轉換服務,把中轉環節控制在自己手裡。

轉換後常見的失效場景與排查

訂閱轉換成功匯入,不代表節點一定能正常連線。以下幾種情況在實際使用中出現頻率較高。

節點數量對不上

轉換後節點數量比原訂閱少,通常是轉換服務或用戶端不支援某個協定欄位導致整條節點被跳過,而不是報錯中斷。排查方法是先看原始 Base64 解碼後的節點總數,再對比生成的 YAML 裡 proxies 條目數,如果確實少了,檢查缺失節點的協定類型是否偏冷門(例如某些實驗性傳輸層組合),換一個轉換範本或更新到支援該協定的最新核心版本往往能解決。

策略組裡看不到新節點

如果使用了遠端規則範本(config 參數指定的範本),策略組的節點篩選條件是按節點名關鍵字比對寫死的,新節點名稱如果不符合範本裡的關鍵字規則(比如範本只篩「HK|SG|JP」開頭的節點),就不會被自動歸入對應策略組。這種情況需要檢查範本裡的篩選正規表達式,或者乾脆去掉遠端範本,讓轉換服務用預設的「全部節點入一個自動測速組」策略。

轉換後 TLS/SNI 參數遺失

部分協定(尤其是 Trojan 和 VMess 的 WebSocket+TLS 組合)對 SNI 和 skip-cert-verify 欄位比較敏感,轉換服務如果沒有正確解析原始連結裡的 sni 或 allowInsecure 參數,生成的節點會連線逾時或握手失敗。這種情況建議手動打開生成的 YAML,對照原始分享連結的參數,補全或修正 servername 與 skip-cert-verify 欄位。

更新週期設定不當導致訂閱過期

轉換生成的訂閱連結本質上是「即時代理請求」,每次用戶端刷新訂閱時,轉換服務都會重新拉取原始訂閱並重新轉換一遍。如果原始訂閱本身設有更新頻率限制(常見的是幾小時一次),用戶端刷新過於頻繁會被原始面板判定異常請求而拒絕回應,進而導致轉換服務回傳空節點清單。用戶端裡的訂閱刷新間隔建議設定在 6~12 小時,避免手動頻繁點擊刷新。

選擇格式與轉換方式的實用建議

• 如果服務商直接提供 Clash 專用訂閱連結,優先使用,跳過所有轉換環節,減少出錯機率。
• 只有 Base64/裸文本訂閱時,先嘗試用戶端內建轉換,轉換失敗或節點缺失明顯時才考慮第三方轉換服務。
• 使用第三方轉換服務時,盡量選擇開源且可自行部署的專案,把原始訂閱憑證留在自己控制的伺服器上處理。
• 轉換完成後,先用 url-test 策略組做一次全量測速,確認節點數量和延遲正常,再切換到日常使用的規則模式。
• 規則範本與節點命名規則最好保持穩定,減少因服務商修改節點名稱格式導致策略組比對失效的情況。

訂閱格式的轉換看起來是個格式轉換的小問題,但背後牽涉的是節點資訊在多方之間的流轉路徑。弄清楚每一步資料經過了誰的伺服器、以什麼形式暴露,比單純讓「連結能用」更值得花時間確認。