Clash 訂閱格式比較：Base64 節點連結、YAML 與 sing-box JSON 互轉指南

訂閱格式：先分清節點清單與完整設定

「訂閱連結」指的是取得內容的入口，不是檔案格式。同一個網址可能因請求參數、標頭或伺服器設定而傳回不同內容。要判斷能否匯入 Clash 用戶端，應檢查實際回應內容，而不是只看網址是否以 .yaml 結尾。

常見輸入包括逐行排列的節點分享連結、將整份連結清單以 Base64 編碼的文字，以及包含節點與路由設定的完整設定檔。Base64 是編碼方式，不是加密，也不是代理協定。知道解碼方式的人就能還原伺服器位址與認證資料，因此編碼後的訂閱同樣需要妥善保密。

內容類型	常見結構	通常包含	無法據此推定
節點連結清單	`ss://`、`vmess://`、`vless://` 等，每行一筆	節點位址、認證資料與部分傳輸參數	已設定策略群組、DNS 與分流規則
Base64 訂閱	整份清單編碼後的文字	通常與解碼後的連結清單相同	某個用戶端能直接辨識所有協定
Clash YAML	`proxies`、`proxy-groups`、`rules`	節點、策略群組、規則及可選的 DNS 等設定	所有 Clash 系列核心都支援所有欄位
sing-box JSON	`inbounds`、`outbounds`、`route`	入站、出站、路由及可選的 DNS 等設定	與 Clash YAML 的欄位完全一一對應

辨識內容：檢查回應，再解碼 Base64

先排除登入頁面與錯誤頁面

將訂閱下載到本機後，先用文字編輯器檢查檔案開頭。如果看到 <!DOCTYPE html>、登入表單或存取受限提示，取得的就是網頁，不是設定檔。HTTP 狀態碼為 200 也不代表內容正確；訂閱到期、請求遭攔截或帳號需要驗證時，都可能傳回 HTML。

確認訂閱來自帳號管理頁面中對應的用戶端入口，並檢查有效期限。
檢查重新導向後的實際內容，避免將錯誤頁面送交轉換器。
如果內容已有 proxies: 或 JSON 物件，先依其結構判斷用途，不要重複進行 Base64 解碼。
只有在內容確實是編碼文字時，才在本機解碼；請勿將含有權杖的內容貼到公開的線上解碼網站。

本機解碼範例

以下使用 Python 3 標準程式庫讀取本機的 subscription.txt，支援常見的標準與 URL 安全 Base64 字元集，並補上末尾填充。這段程式只處理編碼層，不會解析節點協定。請在個人終端機執行；輸出內容可能包含密碼，不應貼入客服單或公開記錄。

from pathlib import Path
import base64

raw = Path("subscription.txt").read_text(encoding="utf-8").strip()
compact = "".join(raw.split())
compact += "=" * (-len(compact) % 4)
decoded = base64.b64decode(compact, altchars=b"-_", validate=True)
print(decoded.decode("utf-8"))

解碼失敗不一定代表訂閱損毀，也可能是原始內容並未編碼。成功取得 UTF-8 文字後，再確認內容是否為逐行排列的節點連結。整份清單解碼完成，不表示每條連結內部也要再整份解碼：例如 Shadowsocks 的使用者資訊和某些 VMess 分享格式各有自己的編碼規則，應交由各自的協定解析器處理。

轉換原理：解析節點，再產生目標設定

訂閱轉換不是把 YAML 的冒號換成 JSON 的大括號。轉換器通常會先解析來源格式，擷取協定、位址、連接埠、認證資料與傳輸參數，建立內部節點模型，再依目標核心支援的欄位輸出。策略群組、規則、DNS 與入站設定通常要透過另一份範本補上。

因此，「轉換成功」只表示已產生輸出，不代表節點協定可用，也不代表來源設定的行為都完整保留下來。從完整 YAML 匯出節點連結時，節點以外的策略群組、規則提供者、DNS 分流與 TUN 設定通常無法寫回連結；再用這些連結產生 JSON，遺失的資訊也不會自動恢復。

常見轉換方向與限制

Base64 → Clash YAML：先解碼並解析連結，再產生 proxies，最後補上所需的策略群組與規則。
Clash YAML → Base64：通常只會匯出可轉成分享連結的節點，再將連結清單編碼；這不能當作設定備份。
Clash YAML → sing-box JSON：需要對應節點欄位，並依目標版本重新整理路由與 DNS。
sing-box JSON → Clash YAML：必須確認出站類型與規則動作是否有對應實作；自訂路由邏輯可能只能手動重建。

原版 Clash 與 Clash Meta（現稱 mihomo）的功能範圍不同。使用較新協定的設定，應明確選擇支援該協定的目標核心；單純將副檔名改成 .yaml，不會讓舊核心支援 VLESS、Reality 或其他新增功能。圖形化用戶端也可能搭載不同版本的核心，應以實際執行中的核心版本為準。

欄位對照：以 Shadowsocks 節點為例

以下兩份設定描述的是同一個示範用 Shadowsocks 出口：伺服器連接埠為 8388，本機混合代理連接埠為 7890。網域使用保留的 .invalid 後綴，密碼為示範值；設定僅供理解欄位用途，無法直接連線。兩份設定都未啟用 TUN 或系統代理。

mihomo YAML：節點、選擇群組與預設規則

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies:
  - name: 範例節點
    type: ss
    server: node.example.invalid
    port: 8388
    cipher: aes-128-gcm
    password: "demo-only-password"

proxy-groups:
  - name: 出口選擇
    type: select
    proxies:
      - 範例節點
      - DIRECT

rules:
  - MATCH,出口選擇

sing-box JSON：入站、出站與最終路由

{
  "log": {
    "level": "info"
  },
  "inbounds": [
    {
      "type": "mixed",
      "tag": "mixed-in",
      "listen": "127.0.0.1",
      "listen_port": 7890
    }
  ],
  "outbounds": [
    {
      "type": "shadowsocks",
      "tag": "範例節點",
      "server": "node.example.invalid",
      "server_port": 8388,
      "method": "aes-128-gcm",
      "password": "demo-only-password"
    },
    {
      "type": "direct",
      "tag": "直連"
    },
    {
      "type": "selector",
      "tag": "出口選擇",
      "outbounds": ["範例節點", "直連"],
      "default": "範例節點"
    }
  ],
  "route": {
    "final": "出口選擇"
  }
}

這裡的 cipher 對應 method，節點伺服器連接埠 port 對應 server_port，節點名稱則會成為供其他設定引用的 tag。此 JSON 範例以明確的 direct 出站表示 Clash 內建的 DIRECT。實際使用仍須依 sing-box 版本驗證，尤其是 DNS、TUN 與路由動作等持續演進的設定。

兩個程式無法同時占用本機相同的 7890 監聽連接埠。進行對照測試時，先停止其中一個，或將另一份設定改為 7891，並同步調整測試工具的代理位址。否則「連接埠已被占用」很容易被誤認為訂閱轉換失敗。

轉換參數：分別確認目標、篩選條件與範本

轉換服務沒有統一的參數標準。部分以 subconverter 為基礎的部署會接受 target、url、include、exclude、config 等參數，但即使名稱相同，實際意義也不一定相同。請先閱讀服務部署方的說明，不要直接套用其他服務的轉換網址。

參數類別	確認項目	常見結果
目標類型	是否明確支援所用的 mihomo 或 sing-box 版本	目標選錯會捨棄不支援的協定或欄位
來源訂閱網址	巢狀 URL 是否依介面要求編碼	來源網址中的 `&` 被視為外層參數分隔符
節點篩選	包含與排除條件是否使用正規表示式	篩選後節點數變成零，策略群組引用失效
設定範本	是否會覆寫 DNS、規則、群組名稱或監聽連接埠	節點沒有變，但流量路徑與解析行為改變
重新命名與排序	是否保留唯一名稱，並同步更新引用	節點名稱重複或引用失效，導致載入錯誤

巢狀 URL 應交由 URL 編碼工具處理成單一參數值，不要憑直覺只替換空格。也不要反覆編碼整個產生結果，否則來源網址中的 % 可能繼續變成 %25。轉換器回傳空清單時，先暫時移除篩選條件，再檢查目標相容性。

轉換後檢查：先通過語法檢查，再驗證實際行為

第一步：使用目標核心檢查設定

JSON 語法正確不代表 sing-box 設定有效，YAML 能解析也不代表核心支援其中的欄位。可在已安裝對應命令列程式的環境中執行以下檢查；執行檔名稱與路徑請以實際安裝情況為準。

mihomo -t -f converted.yaml
sing-box check -c converted.json

先處理未知欄位、缺少出站、策略群組引用不存在等錯誤，再啟動代理。如果圖形化用戶端會合併或覆寫設定，也要檢查用戶端最後產生的執行設定：匯入檔案通過檢查，不代表覆寫後仍然有效。

第二步：逐項檢查容易遺失的連線參數

認證與連接埠：核對伺服器網域、連接埠、密碼或 UUID，避免把本機的 7890 誤當成伺服器連接埠。
TLS：確認是否啟用，並核對伺服器名稱與憑證驗證。不要以停用憑證驗證來掩蓋 SNI 或伺服器名稱對應錯誤。
傳輸層：逐一核對 WebSocket 路徑、Host 請求標頭、gRPC 服務名稱等，不要只保留協定名稱。
Reality 與指紋：確認目標實作支援公鑰、短 ID、伺服器名稱與用戶端指紋，且欄位值都正確寫入。
UDP：確認協定、節點伺服器端與目標設定都支援所需的 UDP 行為；瀏覽網頁成功一次，並不能證明 UDP 可用。

第三步：確認分流與 DNS

Clash 的 rules 會依序比對，末尾的 MATCH 是常見的預設規則。sing-box 的路由規則、動作與 route.final 各有自己的結構，不能逐行照搬。請確認規則指定的目標確實存在，並檢查代理伺服器網域的解析是否依賴尚未建立的代理，以免解析與連線互相等待。

DNS 的 fake-ip、網域解析策略、規則集格式與下載路徑也不應直接照搬。Clash 的 rule-providers 與 sing-box 規則集不是相同的檔案格式；能讀取文字清單，不代表能直接共用二進位規則集。TUN 還涉及介面、路由與系統權限，並非節點連結能完整表達的內容。

常見問題：匯入、更新與格式選擇

為什麼轉換後有節點，卻無法連線？

先確認不是示範網域、訂閱過期或連接埠衝突，再查看記錄中的錯誤層級。網域解析失敗應檢查 DNS；TCP 連線失敗應檢查位址、連接埠與本機網路；TLS 交握失敗則應檢查系統時間、伺服器名稱與憑證。反覆切換 Base64 與 YAML，通常無法修復這些連線層問題。

為什麼訂閱更新後，本機修改不見了？

遠端設定更新通常會取代下載的內容。需要長期保留的 DNS、規則或策略群組調整，應使用用戶端支援的獨立覆寫或合併機制，並確認訂閱更新後仍會套用。轉換產生的靜態檔案也不會自動更新；若要持續同步，必須保留可重新取得的來源入口與可重複執行的轉換流程。

該選哪種格式？

只使用 mihomo：優先選擇服務提供者明確標示適用於 mihomo 的 YAML，並確認它是完整設定還是節點提供者。
只使用 sing-box：優先選擇適用於目前核心版本的 JSON，避免透過其他完整設定反覆轉換。
多種核心共用節點：保留同一個可信任的節點來源，為各核心分別維護規則與 DNS 範本，不要勉強共用同一份主設定。
只有 Base64 連結清單：在可信任的環境中解碼與轉換，記錄輸入及輸出的節點數，以及略過的協定，再進行載入測試。

可靠的轉換結果應同時符合三項條件：節點參數沒有遺漏、目標設定通過核心檢查，且實際流量依預期規則處理。保留原始訂閱入口與上一份可用設定，有助於在範本或核心升級後更快找出差異。欄位說明可參閱 YAML 手冊，基礎概念則可查看概念速查。