Clash 訂閱連結格式解析：YAML、Base64 與 URI 節點互轉教學

訂閱連結、編碼與設定格式的差異

訂閱連結是取得內容的網址，YAML 是描述設定的資料格式，Base64 是編碼方式，而 URI 節點則是單一代理伺服器的分享格式。這四個概念並不屬於同一層級。以 https:// 開頭的訂閱網址，回傳內容可能是完整 YAML，也可能是經 Base64 編碼的多行節點連結。

判斷能否匯入 Clash，重點不在連結副檔名是否為 .yaml，而在回應本文的結構，以及用戶端核心能否解析。有些服務會依據請求中的 User-Agent 回傳不同內容，因此在瀏覽器開啟的結果，不一定等同用戶端更新訂閱時收到的內容。

Clash YAML：完整設定檔與節點清單

YAML 透過鍵值與縮排呈現結構。以下是用來說明欄位關係的最精簡設定：本機混合代理連接埠為 7890，代理伺服器連接埠為 8388，兩者用途不同。範例中的網域名稱與密碼僅供展示語法，無法用來連線代理服務。

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

proxies:
  - name: "範例 SS"
    type: ss
    server: node.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "test"
    udp: true

proxy-groups:
  - name: "出口選擇"
    type: select
    proxies:
      - "範例 SS"
      - DIRECT

rules:
  - MATCH,出口選擇

三個核心欄位的用途

• proxies 定義連線參數，包括協定、伺服器、連接埠及驗證資訊。
• proxy-groups 定義節點的選擇方式。範例中的 select 可手動選擇「範例 SS」或 DIRECT。
• rules 決定連線要交由哪個策略處理。這裡的 MATCH,出口選擇 是最後的兜底規則，並非依地區或網域細分的規則集。

只有 proxies 的 YAML 並不等於完整設定檔，適合作為節點提供者的資料檔案。即使某些用戶端允許直接匯入，也不能因此認定它已具備完整的流量分流策略。自動補齊、合併設定與覆寫等功能屬於用戶端行為，請分別確認。

YAML 解析失敗時，先檢查縮排與字串

縮排請使用空格，不要混用 Tab。節點名稱建議加上引號，尤其是包含冒號、井字號等符號時。密碼也建議加上引號，避免某些文字被解讀為數字或布林值。修改後，請同時檢查結構是否合法，以及核心是否支援：YAML 能成功解析，不代表目前使用的核心支援所有代理欄位。

Base64 與 URI：解碼後再辨識協定

常見的 Base64 訂閱會先將多個 URI 逐行串接，再整體編碼。轉換時需要先還原文字，接著逐行辨識協定。也有服務會直接回傳未編碼的 URI 清單，因此不能一律對訂閱內容進行解碼。

以 Shadowsocks 分享連結為例

以下採用常見的 SIP002 格式：驗證區段以 Base64 編碼，伺服器與連接埠則保留在外層。驗證區段 YWVzLTEyOC1nY206dGVzdA== 解碼後為 aes-128-gcm:test。

ss://[email protected]:8388#demo

• ss:// 指定 Shadowsocks 協定。
• 驗證區段對應的加密方式為 aes-128-gcm，密碼為 test。
• node.example.com:8388 代表伺服器位址與服務連接埠。
• #demo 是顯示名稱，不是伺服器密碼，也不會以 HTTP 請求片段的形式傳送給訂閱伺服器。

舊式 SS 分享連結可能會將伺服器位址也放進編碼區段；含外掛程式的連結還可能帶有 plugin 參數。不能只依固定的 @ 位置拆解所有格式。Trojan、VMess、VLESS 的分享格式也各不相同，例如常見 VMess 分享連結的編碼本文是 JSON，而不是 SS 格式的驗證字串。

中文名稱與編碼格式變體

節點名稱常使用百分比編碼，例如 URI 片段中的 %E9%A6%99%E6%B8%AF 代表「香港」。百分比解碼與 Base64 解碼是兩種不同操作，處理順序應依據個別協定決定。Base64 也可能使用 URL 安全字元 -、_，或省略結尾的 =；解析器需要辨識這些格式，不能因為缺少等號就判定連結損毀。

訂閱轉換：解析、欄位對應與產生規則

轉換器通常會先取得原始訂閱，再將節點解析為內部資料結構，最後輸出目標格式。產生完整 Clash 設定檔時，也可能套用範本加入策略群組、DNS 與規則。因此，「將 Base64 轉成 YAML」並非只替換文字外殼，而是進行欄位對應與設定檔產生。

1. 取得來源內容：檢查 HTTP 狀態碼與本文，排除登入頁面、過期通知、流量限制頁面或驗證碼頁面。
2. 辨識輸入格式：區分完整 YAML、提供者 YAML、純文字 URI 清單與編碼訂閱。
3. 解析節點：擷取協定、位址、連接埠、驗證資訊，以及 TLS、傳輸等參數。
4. 選擇目標格式：依據實際使用的核心支援欄位輸出，不能只看用戶端名稱是否包含 Clash。
5. 套用範本：產生策略群組與規則，並檢查節點名稱和群組名稱之間的引用關係。

如何理解常用轉換參數

以下以常見的 subconverter 風格介面為例。這些參數並非統一的業界標準，不同實作與版本可能採用不同預設值；使用前請先查閱所部署服務的文件。

假設本機已部署轉換服務，並在 127.0.0.1:25500 監聽，以下示範參數的巢狀編碼方式。此位址僅用來說明介面，不代表安裝用戶端後會自動提供轉換服務。

http://127.0.0.1:25500/sub?target=clash&url=https%3A%2F%2Fsubscription.example.com%2Ffeed%3Ftoken%3Ddemo&list=false&emoji=false&udp=true

內層位址原本為 https://subscription.example.com/feed?token=demo。如果來源位址還有 &type=all，其中的和號也必須編碼為 %26，否則轉換服務會將它視為自己的參數。請勿將整個外層位址再次完整編碼後，直接當成訂閱位址使用。

互轉限制：節點可以匯出，分流設定未必保得住

URI 通常只包含單一節點，完整 YAML 則可包含規則、策略群組、DNS、TUN 與節點提供者定義。將完整 YAML 匯出為 URI 清單時，這些全域設定通常無法表達。之後再把 URI 轉回 YAML，產生的是新範本建立的設定檔，而非原始設定檔的完整還原。

新協定需要核心與轉換器同時支援

原版 Clash、Clash Meta 與 mihomo 支援的協定和欄位範圍各有不同。以 Hysteria2 為例，來源節點存在，不代表面向舊版核心的轉換目標也能保留該節點。實際上必須同時符合三項條件：轉換器能辨識輸入協定、輸出器能呈現對應欄位，以及執行中的核心能載入並使用這些欄位。

• TLS 參數：確認 SNI、憑證驗證設定與 ALPN，不要為了成功匯入而任意關閉憑證驗證。
• 傳輸參數：保留 WebSocket 路徑與請求標頭；遺失路徑可能導致節點顯示正常，卻無法完成交握。
• 擴充功能：請逐項確認多路複用、指紋、Reality 等設定，不要假設同名欄位在所有核心中的意義都相同。
• 名稱引用：重新命名後，也必須同步更新策略群組中的引用；重複的節點名稱可能造成驗證失敗，或讓選擇結果不如預期。

如果原服務已提供符合目前 mihomo 核心的 YAML，建議優先直接使用。只有在輸入格式不相容、需要集中管理範本或合併多個來源時，才加入轉換流程，以減少欄位遺失的風險。

轉換後檢查：從成功匯入到實際連線

成功匯入只代表設定通過某個階段的解析。建議保留原始設定，將轉換結果另存為新檔案，再依照以下順序驗證，避免直接取代後失去可用的復原方式。

1. 檢查節點數量：例如來源訂閱有 12 個節點，輸出卻只剩 8 個，應檢查篩選條件、協定支援或解析記錄，而不是直接開始使用。
2. 檢查關鍵欄位：至少挑選一個節點，比對伺服器、連接埠、協定、驗證資訊與 TLS 參數；不能只確認名稱相同。
3. 檢查核心設定：若已安裝 mihomo 命令列程式，可執行以下測試命令；可執行檔名稱與路徑請以本機安裝狀況為準。
4. 檢查策略群組：確認群組中包含目標節點，且最終規則引用的是實際存在的策略，而非被範本意外改成 DIRECT。
5. 檢查實際連線：先測試節點，再從連線清單檢查目標網域、符合的規則與最終路徑；單次延遲測試無法證明所有網站與 UDP 應用程式都能正常使用。

mihomo -t -f converted.yaml

這個命令用於測試設定，不能證明遠端伺服器一定連得上。如果設定引用外部提供者或規則資源，測試過程也可能載入這些資源。錯誤訊息指出不支援欄位時，先確認核心功能；出現未知代理名稱時，檢查策略群組與規則引用；出現 YAML 解析錯誤時，先處理縮排、引號與清單結構。

「成功匯入卻無法連線」的排查順序

• 所有節點都連線失敗：先檢查網路、訂閱是否過期，以及轉換結果是否套用了錯誤範本。
• 只有某一種協定失敗：優先檢查該協定的核心支援、傳輸參數與轉換器版本。
• 節點測試成功但網頁無法使用：檢查規則命中情況、DNS 解析，以及程式是否透過代理入口連線。
• 瀏覽器可用但遊戲無法使用：進一步排查 UDP、應用程式的代理方式與 TUN 接管狀況，單靠修改訂閱編碼無法解決。

訂閱隱私、更新網址與常見問題

轉換一次後，節點會自動更新嗎？

匯入本機 YAML 檔案通常只是匯入當下的快照，不會自動連回原訂閱取得新節點。匯入轉換後的遠端網址時，用戶端只會在更新期間再次要求該網址；是否即時取得來源訂閱，還要看轉換服務的快取策略。請記下來源網址、目標格式與範本設定，之後才能分辨是來源內容未更新，還是轉換快取尚未重新整理。

為什麼用瀏覽器開啟後只看到一長串亂碼？

如果本文大多由字母、數字和少量編碼符號組成，可能是 Base64；請先在本機解碼，再確認內容。如果本文以 HTML 標籤開頭，或顯示登入、額度、存取限制等提示，就不是有效的節點設定。不要繼續轉換錯誤頁面，也不要單憑「HTTP 200」就認定訂閱有效。

把訂閱網址傳給別人協助排錯，適合嗎？

不建議直接傳送完整網址。可以提供移除驗證資訊後的協定名稱、錯誤文字與設定片段。如果權杖已公開，請在服務端重設訂閱網址；只從本機刪除記錄，無法讓舊權杖失效。重新設定後，也要更新用戶端與轉換服務中儲存的來源網址。

實際選擇可分成三個步驟：先辨識回應本文，再確認目標核心，最後檢查轉換後的欄位與連線結果。編碼處理的是文字表示方式，轉換處理的是格式對應，規則範本決定流量的去向；分開處理這三件事，排查問題會更清楚。