選型參考 預計閱讀 12 分鐘

Clash 訂閱格式解析：base64、YAML 與通用格式的差異及轉換方式

比較 Clash YAML 訂閱、base64 分享連結與通用訂閱格式的結構差異，說明各用戶端的相容性，以及使用轉換工具時需注意的欄位遺失問題。

先分清編碼、連結與設定檔

「Clash 訂閱」並不是單一格式。伺服器回傳的內容可能是一整份 Clash YAML，也可能是由多條分享連結組成的文字，再套上一層 base64 編碼。三者看起來都能透過同一個 URL 匯入，但用戶端收到回應後，採用的是不同的解析路徑。

最容易混淆的是 base64。它只是將位元組轉換為可列印字元的編碼方式，不會定義節點有哪些欄位，也不會決定用戶端支援哪些協定。將一組 ss://、trojan:// 或 vmess:// 連結逐行排列，再對整段文字進行 base64 編碼，通常就稱為「base64 訂閱」。解碼後，真正有意義的仍是每一條分享連結。

Clash YAML 則是一份具有階層結構的設定檔。除了節點之外，還能攜帶策略群組、分流規則、DNS、監聽連接埠、規則集合與 TUN 參數。通用訂閱通常只負責傳遞節點，策略如何組合、流量如何分流，則交由用戶端範本或轉換器補足。

形式 典型開頭或結構 可表達的內容 主要用途
Clash YAML proxies:、proxy-groups: 節點、策略群組、規則、DNS、TUN 等 直接作為 Clash 或 mihomo 設定
明文分享連結 ss://、trojan:// 單一節點的連線參數 跨用戶端複製節點
base64 訂閱 連續的字母、數字與編碼符號 通常是編碼後的多條分享連結 以單一訂閱網址分發節點集合
供應商專用 JSON { 或用戶端定義的欄位 取決於伺服器與目標應用程式 特定用戶端或 API 串接

為什麼 Clash YAML 不只是節點清單

一份可直接執行的 Clash YAML 通常至少包含 proxies、proxy-groups 與 rules 三個部分。前者儲存節點參數，中間部分定義手動選擇、自動測速或故障轉移等策略，最後則決定連線要進入哪個策略群組。

mixed-port: 7890
allow-lan: false
mode: rule

proxies:
  - name: HK-Trojan-01
    type: trojan
    server: edge.example.net
    port: 443
    password: example-password
    sni: cdn.example.net

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - HK-Trojan-01
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

這段設定將混合代理連接埠設為 7890，並建立名為 PROXY 的手動選擇群組。實際訂閱中還可能出現 rule-providers、proxy-providers、dns、sniffer、tun 與持久化快取設定。這些內容都超出單條分享連結的表達範圍。

完整設定與代理供應商並不是同一回事

mihomo 設定支援透過 proxy-providers 引用遠端節點集合。主設定保留 DNS、規則與策略群組，遠端網址只負責更新節點。這種結構適合將「本機分流邏輯」與「遠端節點來源」分開管理。

proxy-providers:
  airport-a:
    type: http
    url: https://sub.example.net/token
    path: ./providers/airport-a.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

這裡的遠端內容通常是 provider YAML，頂層可能只有 proxies:，並不是一份能獨立啟動核心的完整設定。如果將 provider 檔案直接匯入只接受完整 Profile 的用戶端，常見結果是缺少連接埠、策略群組或規則，用戶端會回報設定驗證失敗。

YAML 對縮排與資料型別很敏感

  • 請使用空格縮排，不要混用 Tab 字元。
  • 連接埠 443 通常是數字，密碼、名稱與伺服器位址通常是字串。
  • 名稱包含冒號、井字號或前後空格時，建議使用引號。
  • true 與字串 "true" 的含義不同，不能任意互換。
  • 同名節點加入策略群組後可能產生歧義，轉換前應先為名稱去重。

如何組織 base64 訂閱與通用分享連結

通用訂閱常見的原始內容是每行一個 URI。各協定自行規定 URI 中的伺服器、連接埠、驗證資訊與擴充參數。例如 Shadowsocks 常見 ss://，Trojan 使用 trojan://，VMess 常見 vmess://，VLESS 使用 vless://。mihomo 還支援更多協定類型，但舊版 Clash 核心與不同圖形化用戶端的支援範圍並不一致。

ss://[email protected]:8388#SS-01
trojan://[email protected]:443?sni=cdn.example.net#Trojan-01
vless://[email protected]:443?type=ws&security=tls&host=cdn.example.net#VLESS-01

連結末尾的片段通常用作節點名稱，查詢參數則可能儲存 TLS、SNI、WebSocket 路徑、Host、傳輸方式或指紋參數。不同實作對參數命名與預設值的處理有所差異。某個用戶端能辨識 URI 前綴，不代表它一定能完整理解其中每個擴充欄位。

base64 解碼後可能還有第二層編碼

整份訂閱解碼後，VMess 連結內部可能還包含一段經 base64 編碼的 JSON；Shadowsocks 的使用者資訊也有多種 URI 表達方式。排查時應分層處理：先解碼訂閱正文，再逐行辨識協定，最後交由對應的協定解析器處理。直接對整段內容反覆解碼，容易破壞原始連結。

  1. 取得訂閱回應後，保留一份原始文字副本。
  2. 檢查開頭是否已出現 proxies:、協定 URI 或 JSON 結構。
  3. 只有在內容確實符合 base64 字元特徵時，才嘗試解碼。
  4. 解碼後依換行拆分，過濾空行，再逐條辨識協定。
  5. 檢查節點數量、名稱、連接埠與 TLS 參數是否完整。

用戶端相容性取決於核心與匯入入口

同一份訂閱在兩個用戶端中的表現不同，通常不是訂閱網址失效，而是核心協定支援、用戶端預處理邏輯與匯入入口不同。Clash for Windows 0.20.39 已停止維護，其 Profiles 頁面主要用於 Clash 設定；mihomo 用戶端通常能解析更廣泛的協定欄位，但圖形介面是否接受原始通用訂閱，仍取決於用戶端自身的訂閱模組。

完整 YAML 的匯入路徑

以 Clash for Windows 0.20.39 為例，常見流程是「Profiles」→ 在頂部輸入訂閱 URL →「Download」。匯入後應先確認設定卡片是否出現，再切換至「Proxies」確認策略群組與節點。若只看到節點，卻沒有預期規則，伺服器可能回傳的是經用戶端範本處理的節點集合，而非原始完整 YAML。

在採用 mihomo 核心的 2.x 圖形化用戶端中，入口通常是「訂閱」→「新增」→「URL」。名稱會因用戶端而異，但檢查邏輯一致：更新記錄是否回傳 HTTP 200、設定驗證是否通過、策略群組數量是否符合預期，以及核心是否成功重新載入。

連接埠號碼不屬於訂閱節點本身

7890、7891 與 9090 經常出現在 Clash 設定中，但作用各不相同。7890 常用作 HTTP 與 SOCKS 混合入口，7891 在部分舊設定中用於 SOCKS，9090 則常用於外部控制介面。通用分享連結描述的是遠端代理節點，不會替本機用戶端決定監聽連接埠。

因此，將通用訂閱轉換成 YAML 時，轉換器通常需要額外注入 mixed-port、策略群組與規則。即使兩次轉換得到的節點完全相同，也可能因範本不同而呈現不同的分流行為。

格式轉換實際做了哪些事

所謂「訂閱轉換」通常包含四個步驟：辨識輸入、解析節點、對應欄位、套用輸出範本。輸入可以是完整 YAML、provider YAML、base64 連結集合或明文 URI；輸出則可能是 Clash YAML、mihomo YAML，或另一種用戶端能讀取的訂閱文字。

通用訂閱轉換為 Clash YAML

這是最常見的流程。轉換器會將每條分享連結解析為 proxies 項目，再依據範本建立策略群組與規則。至少要確認以下欄位：

  • 協定類型、伺服器位址、連接埠與驗證資訊。
  • 是否啟用 TLS，以及 SNI 或 servername 是否保留。
  • WebSocket、gRPC 等傳輸方式與路徑參數。
  • UDP 開關、略過憑證驗證設定與用戶端指紋參數。
  • 節點名稱編碼是否正常，重複名稱是否會自動加上後綴。
  • 產生目標是舊版 Clash 語法，還是 mihomo 擴充語法。

Clash YAML 轉換為通用訂閱

反向轉換一定會遺失設定層級的資訊。分享連結可以帶走節點連線參數，卻無法帶走 proxy-groups、rules、rule-providers、DNS、TUN、嗅探與監聽連接埠。再次匯入其他用戶端後，即使看到的節點數量一致，也不能據此判斷兩份設定等價。

完整 YAML 轉換為 provider YAML

這個步驟通常只會擷取 proxies，輸出一份供 proxy-providers 引用的檔案。原設定中的分流規則與策略群組不會自動加入主設定。主設定還需要透過 use: 將 provider 放入指定策略群組，否則即使節點已下載，介面中仍可能沒有可選項目。

proxy-groups:
  - name: AUTO
    type: url-test
    use:
      - airport-a
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

欄位遺失通常發生在這六個地方

一、協定擴充欄位沒有對應目標

來源格式可能包含用戶端指紋、Reality 公鑰、短 ID、ECH、壅塞控制或特定傳輸參數，而目標格式沒有等價欄位。轉換器可能忽略這些內容，也可能寫入目標用戶端不認識的擴充鍵。結果通常不會立即報錯，而是節點能顯示，連線卻逾時。

二、規則與策略群組被範本覆寫

從完整 YAML 轉換時，如果工具先擷取節點再套用範本，原本的 DIRECT、REJECT、故障轉移群組與規則順序都可能被替換。Clash 規則會依從上到下的順序比對，順序改變本身就會改變結果。例如將 GEOIP,CN,DIRECT 放在特定網域代理規則之前，可能讓目標連線提前直連。

三、節點名稱參與篩選

不少範本會依名稱使用正規表示式建立「香港」、「日本」、「低倍率」等策略群組。轉換後若名稱中的旗幟、空格或地區縮寫改變，篩選結果可能從 30 個節點降為 0 個。遷移前後應比較策略群組的實際成員，而不只是比較訂閱總數。

四、布林值與預設值發生變化

來源連結未寫入某個參數時，兩個用戶端可能採用不同的預設值。例如 UDP、TLS 驗證、SNI 推導與傳輸 Host 都可能依賴預設行為。轉換器明確寫入某個值後，連線行為反而可能與原用戶端不同。

五、DNS 與 TUN 完全留在舊設定

節點遷移成功不代表系統代理路徑也遷移成功。Fake-IP 位址池、DNS 上游、網域嗅探、路由排除項目與 TUN 自動路由都屬於本機設定，通用訂閱不會承載這些欄位。切換用戶端後，應重新檢查「設定」→「系統代理」、「設定」→「TUN 模式」及 DNS 設定，而不是沿用舊用戶端的狀態來判斷。

六、訂閱更新機制不同

完整 YAML 可以直接攜帶固定節點；provider 則有獨立的 interval 與快取路徑；圖形化用戶端還可能維護自己的更新時間。範例中的 interval: 3600 表示每 3,600 秒請求一次，而健康檢查的 interval: 600 表示每 600 秒測試一次，兩者不是同一項工作。

一套可供複查的遷移流程

格式轉換最穩妥的做法，不是「一鍵匯入後直接接管流量」，而是保留舊設定並分階段核對。以下流程適用於從通用訂閱遷移至 mihomo YAML，也適用於在兩個 Clash 圖形化用戶端之間更換設定。

  1. 記錄基準。記下原用戶端的節點總數、常用策略群組、系統代理連接埠、DNS 模式與 TUN 狀態。
  2. 判斷輸入格式。確認回傳的是完整 YAML、provider YAML、明文 URI 還是 base64 文字。
  3. 選擇目標。確認目標核心是舊版 Clash 還是 mihomo，避免產生目標核心不支援的欄位。
  4. 先轉換節點。核對伺服器、連接埠、協定、TLS、SNI、傳輸層與名稱，不要急著覆寫規則。
  5. 再套用範本。加入策略群組、規則、DNS 與監聽連接埠，確認引用名稱一致。
  6. 執行設定驗證。在用戶端重新載入前查看解析錯誤，重點檢查 YAML 縮排、重複鍵與不存在的策略群組。
  7. 進行小流量驗證。先關閉 TUN，只啟用系統代理；確認瀏覽器路徑後，再測試 DNS 與 TUN。
  8. 比較實際行為。分別測試直連網域、代理網域、遭拒絕網域與 UDP 情境，確認規則命中符合預期。

如果轉換後節點顯示正常但全部逾時，先擷取一個節點與來源連結比對，檢查連接埠、SNI、TLS 與傳輸路徑。如果只有部分網站異常，重點查看規則順序與 DNS。如果系統應用程式沒有經過代理，則檢查系統代理或 TUN，而不是繼續修改訂閱格式。

選擇格式時直接依使用目的判斷

  • 需要完整重現分流：優先使用與目標核心相容的完整 YAML，並保留規則、策略群組與 DNS。
  • 只想跨用戶端搬移節點：使用通用分享連結或 base64 訂閱，由目標用戶端重新負責策略。
  • 想長期維護本機規則：固定主設定，透過 proxy-providers 遠端更新節點。
  • 需要相容 mihomo 擴充協定：明確選擇 mihomo 作為轉換目標，避免退回舊版 Clash 欄位集合。
  • 來源格式不確定：先查看回應正文，再決定是否解碼或轉換，不要連續套用多個轉換器。

歸根究柢，base64 解決的是文字傳輸，分享連結描述的是單一節點，Clash YAML 管理的是整套代理行為。轉換可以搬移欄位，卻無法憑空保留目標格式無法表達的資訊。遷移前先分清這三個層次，就能大幅減少節點「匯入成功卻無法使用」、規則消失與 DNS 行為突變等問題。

安裝用戶端並驗證訂閱

先選擇對應平台，再依照教學匯入訂閱，檢查策略群組、系統代理與 DNS。

前往下載頁 查看教學
下載Clash