Clash 訂閱格式解析:YAML、Base64 與訂閱轉換的正確用法

訂閱連結究竟是什麼

訂閱連結是一個能被用戶端定時抓取的 HTTP/HTTPS 位址,請求後回傳的內容裡包含一批節點資訊,有時還附帶分流規則。用戶端拿到這份內容後,依照約定的格式解析出節點列表,寫入本機設定,交給代理引擎呼叫。理解訂閱這件事的關鍵在於分清兩層內容:一層是「節點怎麼描述」,另一層是「整份設定怎麼組織」。前者決定了單條連結的寫法,後者決定了整個訂閱檔案的結構。很多人排查訂閱問題時只盯著連結本身,卻忽略了用戶端到底期望收到哪種結構,這是格式類故障裡最常見的認知偏差。

Clash 系用戶端(包括以 Mihomo 核心為基礎的分支)天生認得的是 YAML 結構化設定,而機場或自建者最初產生的往往是通用的節點分享連結,兩者需要一層轉換才能對接。這個轉換環節做得好不好,直接決定了訂閱更新是否順暢、規則是否完整、節點是否齊全。

三種主流格式拆解

Clash YAML 原生設定

這是 Clash 用戶端最直接認得的格式,一份完整檔案通常包含 proxies(節點列表)、proxy-groups(策略群組)、rules(分流規則),以及可選的 dns、tun 等欄位。每個節點以字典形式書寫,欄位名稱是固定的,例如:

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

YAML 對縮排極其敏感,一個空格錯位就會導致整份設定解析失敗,用戶端往往只顯示「設定無效」而不指出具體是哪一行,這也是訂閱轉換環節最容易出錯的地方之一。

通用 Base64 節點連結

這是機場普遍採用的分享格式,常見形式是以 ss://、vmess://、trojan:// 開頭的一行文字,協定頭後面接著一段 Base64 編碼的參數集合,解碼後能看到伺服器位址、埠號、加密方式等欄位。訂閱連結回傳的往往是一整批這類文字逐行拼接後再整體做一次 Base64 編碼,用戶端或轉換工具需要先做外層解碼,再逐行解析每條節點連結。這種格式的優點是跨用戶端通用性強,幾乎所有主流工具都認得;缺點是不含策略群組與規則資訊,只能描述節點本身。

用戶端私有格式

部分用戶端在 YAML 基礎上擴充了自己的欄位,例如分組的顯示樣式、圖示位址、特定的 DNS 寫法。這些擴充欄位對原生 Clash 核心是無害的冗餘資訊,但如果直接把 A 用戶端匯出的設定拿去給 B 用戶端使用,B 用戶端可能因為不認得某個私有欄位而報錯,或乾脆忽略掉導致功能缺失。這也是「同一份訂閱換個用戶端就出問題」的根源之一。

訂閱轉換服務的運作原理

訂閱轉換服務本質上是一層格式翻譯層,它先請求原始訂閱位址,取得 Base64 或其他格式的節點列表,逐條解碼出伺服器、埠號、協定、加密參數等資訊,再依照目標用戶端能識別的模板重新組裝成一份 YAML 設定,同時可以依預設規則集注入 proxy-groups 與 rules。整個過程可以概括為三步:抓取原始內容、解析節點欄位、依模板重新產生。

使用轉換服務時,實際填入用戶端的訂閱位址並不是機場提供的原始連結,而是轉換服務產生的一個新位址,格式類似「轉換服務網域 + 參數(包含原始訂閱位址、目標格式、規則模板)」。用戶端每次刷新訂閱,都會請求這個轉換位址,轉換服務再即時去請求機場的原始訂閱、進行轉換、把結果回傳給用戶端。這意味著轉換服務成了連線中的一個中間環節,一旦它出問題,訂閱刷新也會跟著失敗,這一點在排查故障時常常被忽略。

選擇規則模板時要注意版本是否匹配,一些模板是專為舊版 Clash 編寫的,裡面的欄位在新核心上可能已經被廢棄或改名,匯入後策略群組顯示異常卻不會直接報錯,容易讓人誤以為是訂閱本身的問題。

常見轉換失敗原因排查

訂閱轉換失敗大致可歸為四類原因,依出現頻率從高到低排列:

1. 原始訂閱位址本身無法連線。轉換服務需要先抓取原始內容才能進行轉換,如果機場連結已過期、被限流,或需要特定地區網路才能存取,轉換環節會直接失敗,錯誤訊息往往顯示「無法取得訂閱」而非格式問題。
2. 節點協定不被轉換服務支援。較新的協定類型如果轉換服務的模板庫還沒跟上,解析時會直接跳過這些節點,導致轉換後節點數量明顯少於原始訂閱。
3. 規則模板與目標核心版本不匹配。模板裡引用了新核心才有的欄位,舊版用戶端載入後要麼報錯要麼忽略該欄位,策略群組或分流規則表現異常。
4. 特殊字元轉義問題。節點備註名如果包含冒號、引號等 YAML 特殊字元,轉換環節沒有正確轉義,會破壞產生檔案的語法結構,導致後續所有欄位解析全部失敗。

排查時建議依序檢查:先直接存取原始訂閱位址確認能否正常開啟,再比對轉換後節點數量與機場後台顯示的節點數量是否一致,最後檢查產生的 YAML 裡是否有明顯的縮排錯亂或未轉義的特殊字元。多數問題在這三步之內就能定位到具體環節。

跨用戶端搬移訂閱的步驟

更換 Clash 用戶端時,直接沿用同一條訂閱位址通常是可行的,因為主流用戶端都相容標準 YAML 結構,但要留意私有欄位與預設策略群組命名的差異。建議依以下步驟操作:

• 先在新用戶端裡單獨新增訂閱,不要立即刪除舊用戶端的設定,保留一個可回退的對照組。
• 新增完成後手動觸發一次訂閱更新,檢查節點數量是否與原用戶端一致。
• 打開策略群組頁面,確認分組與規則集是否正常載入,尤其要注意自動測速分組能否正常選出節點。
• 如果發現某些自訂規則遺失,大機率是舊用戶端裡手動追加過本機規則,這部分內容不會隨訂閱同步,需要在新用戶端重新補上。
• 確認無誤後再關閉舊用戶端的系統代理或 TUN 模式,避免兩個用戶端同時搶佔網路出口造成衝突。

如果訂閱是透過轉換服務產生的,搬移時更建議直接把原始機場訂閱位址重新走一次轉換流程產生新位址,而不是把上一個用戶端產生的轉換結果直接複製過去,這樣才能確保新用戶端拿到的是針對自身版本適配過的規則模板。

小結

訂閱格式問題看似繁瑣,拆開來看其實只有三個環節:節點本身怎麼編碼、整份設定怎麼組織,以及中間是否經過轉換服務加工。遇到訂閱無法匯入或搬移後功能異常時,先判斷問題出在哪個環節,再對照本文的排查順序逐條核實,大多數格式類故障都能在幾分鐘內定位並解決。