Clash 訂閱格式總覽：YAML、Base64 分享連結與 sing-box JSON 如何互轉

先判斷拿到的是哪一種訂閱

先說結論：Clash 或 Mihomo 通常需要 YAML 設定，sing-box 使用 JSON 設定，而一串看似亂碼的訂閱內容，往往只是經過 Base64 編碼的分享連結集合。三者表達的資訊有所重疊，但不能只改副檔名就互相轉換。

訂閱連結只是取得內容的網址，不等於內容格式。伺服器可以在同一個以 https:// 開頭的網址中，依據用戶端參數回傳 Clash YAML、通用分享連結或 sing-box JSON。判斷時應查看回應本文，而不是只看網址副檔名。

用開頭幾個字元快速辨識

看到的內容	大致格式	下一步
`proxies:`、`proxy-groups:`	Clash 或 Mihomo YAML	直接匯入相容的用戶端，並檢查設定欄位
`dm1lc3M6Ly8`、連續的英數字元與等號	Base64 編碼文字	先解碼，再確認是否為多行分享連結
`ss://`、`trojan://`、`vless://`	單筆或多筆 URI 分享連結	交由轉換器產生目標設定
`{"log":`、`"outbounds"`	sing-box JSON	使用 sing-box 驗證，不要直接匯入 Clash
網頁 HTML、登入提示或錯誤說明	訂閱請求失敗	檢查網址、有效期限與請求參數

先以文字方式讀取，不要直接連按兩下執行

可以使用瀏覽器開發人員工具的「網路」面板查看回應，也可以將內容儲存為純文字。命令列使用者可使用 curl，並限制輸出檔名，避免終端機被大量內容刷滿。

curl -L --max-time 20 "https://sub.example.net/api/demo-token" -o subscription.txt
head -n 8 subscription.txt

-L 用於跟隨重新導向，--max-time 20 會將整個請求限制在 20 秒內。若檔案第一行出現 <!doctype html>，取得的是網頁而非訂閱設定，應先處理登入、網址失效或閘道攔截問題。

YAML、Base64 與 sing-box JSON 的結構差異

格式轉換的難點不在語法，而在資料模型。節點位址、連接埠與驗證資訊相對容易對應；策略群組、規則集、DNS 行為、TUN 路由與指令碼擴充，則可能只存在於某一種核心中。轉換器能改寫結構，卻無法自動理解每條規則的實際意圖。

Clash 與 Mihomo YAML

YAML 設定通常同時容納節點、策略群組與分流規則。Mihomo 是延續 Clash 設定生態的開源代理核心，支援較多協定與擴充欄位。以下是一個最小化範例：

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

proxies:
  - name: HK-01
    type: ss
    server: edge.example.net
    port: 8388
    cipher: aes-128-gcm
    password: demo-pass

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

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - MATCH,PROXY

mixed-port: 7890 表示 HTTP 與 SOCKS 請求共用 7890 連接埠。proxy-groups 定義可在用戶端中選擇的策略，rules 會由上而下比對流量。只有節點清單而沒有策略群組與規則時，部分用戶端可以自動補全，其他用戶端則會提示設定無法使用。

Base64 分享連結集合

Base64 不是代理協定，也不是完整的設定格式，只是將位元組編碼成方便傳輸的文字。常見訂閱會先串接多行 ss://、trojan://、vmess:// 或 vless:// 連結，再對整體進行一次 Base64 編碼。

ss://[email protected]:8388#HK-01
trojan://[email protected]:443?security=tls#SG-01

這類內容通常只包含節點參數與顯示名稱，不含 Clash 的完整規則。轉換為 YAML 時，轉換工具往往會依照範本補上 proxy-groups、rules 與 DNS 設定，因此相同節點套用不同範本後，最終行為可能完全不同。

sing-box JSON

sing-box 使用 JSON 描述入站、出站、路由與 DNS。以 sing-box 1.12 的設定結構為例，節點通常放在 outbounds 陣列中，選擇器也是一種出站物件：

{
  "log": {
    "level": "info"
  },
  "outbounds": [
    {
      "type": "shadowsocks",
      "tag": "hk-01",
      "server": "edge.example.net",
      "server_port": 8388,
      "method": "aes-128-gcm",
      "password": "demo-pass"
    },
    {
      "type": "selector",
      "tag": "proxy",
      "outbounds": [
        "hk-01"
      ]
    }
  ],
  "route": {
    "rules": [
      {
        "action": "route",
        "domain_suffix": [
          "example.org"
        ],
        "outbound": "proxy"
      }
    ],
    "final": "proxy"
  }
}

Clash 的 proxy-groups 與 sing-box 的 selector、urltest 可以近似對應，但欄位名稱與執行模型不同。Clash 的 MATCH 通常對應 sing-box 路由中的最終出站，而不是簡單複製成一條同名規則。

先解碼 Base64，再決定轉換目標

不要看到長字串就直接交給轉換器。先在本機解碼並檢查前幾行，可以確認內容是否完整，也能避免將錯誤頁面、壓縮資料或二次編碼內容誤判為節點訂閱。

Windows PowerShell 解碼

$raw = (Get-Content .\subscription.txt -Raw).Trim()
$bytes = [Convert]::FromBase64String($raw)
[Text.Encoding]::UTF8.GetString($bytes) |
  Set-Content .\decoded.txt -Encoding utf8
Get-Content .\decoded.txt -TotalCount 8

若 FromBase64String 回報格式錯誤，先檢查文字中是否混入空格、網頁標籤或 URL 安全型字元。URL 安全型 Base64 可能使用連字號與底線取代加號和斜線，且省略結尾的等號，需要使用支援此變體的工具處理。

Linux 與 macOS 解碼

# GNU/Linux
base64 -d subscription.txt > decoded.txt

# macOS
base64 -D subscription.txt > decoded.txt

sed -n '1,8p' decoded.txt

若解碼結果仍是一整段 Base64，可能存在二次編碼，但也可能是 VMess 連結內部的 JSON 編碼。此時應先觀察前綴：整份訂閱若是二次編碼，可以繼續解碼；vmess:// 後面的部分則屬於單一節點，不應將整行前綴一併交給一般 Base64 命令。

使用開源轉換工具產生 Clash YAML

當來源是 URI 清單或 Base64 訂閱，而目標用戶端執行 Mihomo 時，可以使用支援 Clash 輸出的開源訂閱轉換器。常見實作會提供 /sub 介面，接收來源網址、目標類型與規則範本，再回傳 YAML。

轉換前確認三個參數

目標類型：選擇 Clash，或明確標示 Mihomo、Clash Meta 的輸出。舊版 Clash 目標可能會移除較新的協定欄位。
來源網址：必須進行 URL 編碼，尤其是網址本身含有 ?、& 或等號時。
規則範本：節點轉換與規則產生是兩件事。第一次測試宜使用簡單範本，確認節點可以連線後，再加入遠端規則集。

假設本機轉換服務監聽 127.0.0.1:25500，將來源網址編碼後，可以以下列形式請求 Clash 輸出：

curl "http://127.0.0.1:25500/sub?target=clash&url=https%3A%2F%2Fsub.example.net%2Fapi%2Fdemo-token" \
  -o converted.yaml

不同專案與分支支援的 target 名稱並不一致。部分版本支援 clash，部分擴充版本還提供 Mihomo 或 sing-box 目標。應查看目前建置的目標清單，不要憑介面名稱猜測。若工具不具備 sing-box 輸出能力，應改用配有相應轉接器的實作，而不是直接將 YAML 改成 .json。

匯入前進行語法檢查

Mihomo 可以在命令列中檢查設定。假設可執行檔名稱為 mihomo，設定檔為目前目錄中的 converted.yaml：

mihomo -t -f ./converted.yaml

測試通過只代表設定可以解析，不表示所有節點都能連線。接著應啟動用戶端，進入「訂閱」或「設定」頁面載入檔案，再到「代理」頁面檢查策略群組中是否出現節點。最後開啟「設定」→「系統代理」，確認 HTTP 與 SOCKS 使用的連接埠與設定一致，例如都指向混合連接埠 7890。

本機自託管轉換服務的穩妥流程

訂閱網址通常包含存取憑證。需要頻繁轉換時，適合將開源轉換程式執行在本機或受控伺服器中，讓來源網址只在自己的裝置與訂閱伺服器之間傳遞。自託管也方便固定版本與規則範本，減少同一訂閱在不同日期產生不同結果。

本機執行時的基本設定

從專案發布紀錄取得與作業系統、CPU 架構相符的建置版本，例如 Windows x64、Linux amd64 或 macOS arm64。
將程式與設定檔放入獨立目錄，首次啟動時只監聽 127.0.0.1，不要直接繫結至公網網卡。
確認監聽連接埠，例如 25500，再使用瀏覽器或 curl 存取本機介面。
將規則範本儲存在本機，並記錄轉換程式版本、範本版本與輸出時間。
先使用一個節點測試，確認欄位對應正確後，再處理完整訂閱。

如果轉換服務必須放在區域網路伺服器上，應限制來源網址，並在反向代理層加入存取控制。轉換介面通常允許呼叫者提交任意訂閱網址；缺乏限制時，不僅會暴露訂閱內容，也可能讓伺服器代替他人請求內部網路位址。

固定輸入與輸出，方便復原

建議保留三份檔案：原始回應 source.txt、轉換輸出 converted.yaml 或 config.json，以及記錄版本與參數的 conversion-notes.txt。例如記錄監聽連接埠 25500、目標 clash、範本檔名與轉換日期。下次節點數量異常時，可以快速比較是來源變更、範本變更，還是工具升級造成的。

從 Clash YAML 轉換至 sing-box JSON 時如何對應

YAML 轉 JSON 不是單純的語法轉換。通用 YAML 轉 JSON 工具只能將縮排結構改成大括號結構，無法將 Clash 的 proxies 轉成 sing-box 的 outbounds，也無法理解策略群組與路由規則。必須使用了解兩種代理設定模型的轉換器。

主要欄位對應關係

Clash / Mihomo	sing-box	轉換注意事項
`proxies[].name`	`outbounds[].tag`	tag 必須唯一，名稱重複時要重新命名
`server`、`port`	`server`、`server_port`	連接埠欄位名稱不同
`proxy-groups` 的 select	`selector` outbound	成員名稱要改為對應的 tag
`url-test`	`urltest` outbound	測試位址、間隔與容差需重新核對
`rules`	`route.rules`	規則類型與最終出站不能機械式複製
`dns`	`dns` 與路由的配合	解析器標籤、分流條件與快取行為不同
`tun`	`inbounds` 中的 tun	介面位址、自動路由與嚴格路由需重新設定

協定欄位也可能存在差異。例如 TLS 的伺服器名稱、ALPN、Reality 參數、WebSocket 路徑與請求標頭，在兩套設定中的巢狀位置不同。轉換後若節點顯示存在但握手失敗，應優先比對這些欄位，而不是反覆更換本機連接埠。

規則無法完整對應時的處理順序

先只轉換一個節點，並將最終路由設為該節點，驗證協定參數。
加入一個手動選擇器，確認節點 tag 與選擇器成員一致。
加入區域網路與常用直連規則，確認本機裝置存取不受影響。
再匯入網域、IP 與規則集，觀察日誌中實際命中的規則。
最後啟用 TUN 與複雜的 DNS 分流，避免同時排查多個變數。

轉換後必須複核的十個欄位

轉換完成後不要立即覆蓋正在使用的設定。先另存檔案並逐項檢查。以下項目比「檔案能否匯入」更重要。

節點數量：來源有 36 個節點，輸出不應只剩 3 個。數量減少時，檢查協定是否被目標格式或轉換器過濾。
節點名稱：名稱必須唯一。名稱重複可能導致策略群組只引用其中一個節點。
伺服器與連接埠：確認 server 沒有被寫成訂閱伺服器網址，並核對 443、8443、8388 等實際連接埠。
驗證資訊：檢查密碼、UUID、金鑰及其大小寫，留意 URL 解碼是否將加號誤處理為空格。
TLS 參數：核對伺服器名稱、是否略過憑證驗證、ALPN 與 Reality 公鑰等欄位。
傳輸參數：WebSocket 路徑應保留開頭的斜線，gRPC service name 與 HTTP Host 不能互換。
策略群組成員：手動選擇、自動測速與故障轉移群組中必須存在有效節點，不能只剩群組名稱。
規則順序：規則會依序比對。區域網路直連通常應放在最終兜底規則之前。
DNS 行為：檢查監聽位址、上游伺服器、代理解析與直連解析的分工，避免發生解析迴圈。
本機連接埠：設定改為 7891 後，Windows 11 的「設定」→「網路和網際網路」→「代理」也要同步修改，舊的 7890 不會自動跟隨。

用最短路徑驗證結果

先關閉 TUN，只啟用系統代理與一個手動節點。造訪出口 IP 查詢頁面，再使用命令列透過混合連接埠請求一個 HTTPS 位址：

curl -x http://127.0.0.1:7890 --connect-timeout 8 https://example.com/

若回應正常，再測試規則模式、自動測速與 TUN。自動測速顯示 80 毫秒，只代表探測位址的往返速度較快，不等於所有網站都能穩定存取。實際驗證還要觀察 DNS、TLS 握手與下載過程。

常見問題

把 YAML 副檔名改成 JSON，sing-box 能讀取嗎？

不能。副檔名不會改變內部資料模型。即使先用通用工具將 YAML 語法轉成 JSON，內容仍是 Clash 的 proxies、proxy-groups 與 rules，sing-box 不會自動將它們解釋為出站與路由。

為什麼 Base64 解碼後只有節點，沒有規則？

通用 URI 訂閱主要負責傳遞節點參數，本身通常不含 Clash 策略群組與分流規則。產生 YAML 時需要選擇規則範本，或在轉換結果中自行維護策略群組與規則。

轉換後的訂閱還能自動更新嗎？

取決於匯入方式。本機匯出的靜態檔案不會自動更新；用戶端若儲存的是轉換介面網址，則可以依更新間隔重新請求。應保留原始網址，並確認轉換服務能長期使用。

Mihomo 設定可以直接用於舊版 Clash 嗎？

基礎欄位可能相容，但 Mihomo 擴充協定、規則集、DNS 與 TUN 欄位不一定能被舊核心辨識。目標用戶端使用舊核心時，應選擇相應的輸出類型，並透過該核心自己的設定檢查命令進行驗證。

轉換後延遲全部顯示逾時，應先查什麼？

先檢查測速位址是否可存取，再確認策略群組確實包含節點。若手動連線也失敗，請比較伺服器、連接埠、TLS 伺服器名稱與傳輸路徑；若手動連線正常，通常是測速 URL、間隔或並行設定的問題。

格式選擇建議

目標是 Mihomo 用戶端時，優先使用伺服器直接提供的 Clash 或 Mihomo YAML；目標是 sing-box 時，優先取得針對目前 sing-box 設定結構產生的 JSON。只有來源不提供目標格式時，才加入轉換層。

Base64 URI 訂閱適合作為通用節點來源，但不負責完整分流。長期使用時，應將節點轉換與規則範本分開管理：節點依訂閱更新，規則則由自行選定的設定維護。發生問題時，便能明確判斷是節點參數變更，還是路由與 DNS 設定變更。

最後只需記住一個簡單原則：先驗證單一節點，再加入策略群組；先驗證系統代理，再開啟 TUN；先確認語法，再檢查網路。格式轉換涉及的變數越少，找出錯誤就越快。