Clash YAML 訂閱與 Base64 節點連結：格式差異與轉換方式

先分清訂閱網址、回應格式與設定檔

訂閱網址只是取得內容的入口。以 https:// 開頭的連結，可能回傳完整的 Clash 設定，也可能回傳經 Base64 編碼的節點清單。網址中出現「clash」字樣，或檔名以 .yaml 結尾，都不能取代對回應內容的檢查。

有些服務會依據請求參數、用戶端識別資訊或帳戶設定，回傳不同格式。因此，同一個網址在瀏覽器與用戶端取得的內容可能不同。排查時應記錄實際匯入入口、回應本文類型及用戶端使用的核心，而不是反覆修改檔案副檔名。

格式	可辨識的結構	通常包含內容	匯入位置
完整 Clash YAML	`proxies:`、`proxy-groups:`、`rules:` 等欄位	節點、策略組、規則及其他設定	設定檔或遠端設定入口
節點提供者 YAML	主要是頂層的 `proxies:` 清單	供主設定引用的節點集合	`proxy-providers` 對應的資源
Base64 節點清單	解碼後通常每行一個 URI	節點連線參數，通常不含分流規則	支援此格式的訂閱入口或轉換工具
單一節點 URI	`ss://`、`trojan://` 等前綴	單一節點及其通訊協定參數	支援該通訊協定的節點匯入入口

Clash YAML：除了節點，還有策略組與規則

完整設定中的 proxies 用來定義連線參數，proxy-groups 定義選擇方式，rules 則決定流量的去向。轉換工具若只擷取節點，就會遺失後兩者。DNS、監聽埠與 TUN 設定也無法完整表達在單一節點 URI 中。

最精簡的結構範例

以下示範如何將常見的 Trojan 節點加入主設定。網域與密碼僅用於說明結構，無法實際連線。7890 是本機混合代理埠，443 是遠端節點埠，兩者不能互換。

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

proxies:
  - name: "demo-trojan"
    type: trojan
    server: edge.example.com
    port: 443
    password: "demo-password"
    sni: edge.example.com
    udp: true

proxy-groups:
  - name: "手動選擇"
    type: select
    proxies:
      - "demo-trojan"
      - DIRECT

rules:
  - MATCH,手動選擇

此處的 MATCH,手動選擇 是兜底規則，不代表依地區或網域分類的分流方案。策略組選擇 DIRECT 時，符合該組的連線會直接連線；選擇範例節點時，才會嘗試透過該節點建立連線。

name 是供引用的識別名稱。節點改名後，策略組中使用舊名稱的項目也必須同步修改。
server 是連線目標，sni 是 TLS 握手時使用的伺服器名稱；實際部署時，兩者不一定相同。
udp: true 允許該節點參與相應的 UDP 轉送，但不能據此推斷伺服器或目前的連線方式已支援所有 UDP 流量。

Base64：解碼只會還原文字，不會產生 Clash 欄位

Base64 是一種編碼方式，不是代理通訊協定，也不是加密。它可以將多行節點連結包裝成一段文字，但不會自動補上策略組、DNS 或規則。將 Base64 解碼後另存為 config.yaml，若內容仍是 URI 清單，Clash 設定解析器仍無法將它當成 YAML 主設定使用。

從兩層內容判斷

先檢查外層本文。若直接看到 proxies: 等結構，應先按 YAML 檢查，不要強行解碼。
若本文是一段疑似編碼的文字，請使用本機工具解碼，再確認結果是否為可讀文字。
若解碼後每行都以 ss:// 或 trojan:// 等開頭，通常是節點清單，還需要解析通訊協定並對應欄位。
若結果是 HTML 錯誤頁、登入提示或 JSON 錯誤訊息，應先處理訂閱存取問題，不能繼續當成節點轉換。

例如，aGVsbG8= 解碼後是 hello，這只能證明編碼內容可以還原，不能證明它是有效的訂閱。標準 Base64 常用 +、/ 與結尾的 =；URL 安全變體則使用 -、_，有些實作也會省略補位字元。解碼器必須依實際變體處理，不能任意替換節點原文。

還要區分外層訂閱編碼與節點內部編碼。例如，有些 Shadowsocks URI 的使用者資訊本身也採用 Base64。外層解碼得到 ss:// 後，仍須依照對應的 URI 規範解析，不能再機械式地解碼整條 URI。

單一節點 URI 轉成 YAML：逐項對應連線參數

以下 URI 描述的基本連線資訊與前面的 Trojan 範例相同。它不包含「手動選擇」策略組，也不包含 MATCH 規則。結尾片段用來表示節點名稱；若實際名稱含有空格、中文或特殊符號，匯出工具應依 URI 規範編碼。

trojan://[email protected]:443?security=tls&sni=edge.example.com#demo-trojan

URI 部分	對應的 YAML 欄位	檢查項目
`trojan://`	`type: trojan`	目標核心必須支援該通訊協定
`demo-password`	`password`	依規範處理百分比編碼，保留原始憑證的意義
`edge.example.com`	`server`	不要任意以 SNI 值取代連線位址
`:443`	`port: 443`	以整數表示，範圍為 1 至 65535
`sni=edge.example.com`	`sni`	確認符合伺服器憑證與部署需求
`#demo-trojan`	`name`	解碼名稱後，檢查重複項目與策略組引用

不同通訊協定不能套用同一份對應表

Shadowsocks 通常需要 cipher 與 password；VMess 常見 UUID、傳輸層與 TLS 參數；VLESS、Hysteria2 等則還須考量目標核心的支援範圍。原版 Clash 與 Clash Meta（mihomo）支援的通訊協定能力並不相同，轉換目標應明確指定核心，而不是只寫「Clash 通用」。

WebSocket 路徑、Host 要求標頭，以及 gRPC 服務名稱都屬於實際連線參數。以 WebSocket 為例，mihomo 設定常見 network: ws、ws-opts.path 與 ws-opts.headers.Host。若轉換時只保留伺服器、埠號與密碼，節點雖然會出現在清單中，仍可能無法完成握手。

互相轉換：先決定要保留節點，還是整份設定

將 Base64 或 URI 清單轉成 Clash YAML

備份來源。儲存訂閱原文與目前可用的設定。含有權杖的訂閱網址屬於敏感憑證，不要放進螢幕截圖、公開記錄或問題附件。
確認輸出目標。選擇工具實際提供的 Clash 或 mihomo 目標，並確認節點通訊協定在該目標的支援範圍內。
還原並解析節點。只有外層採用 Base64 編碼時才解碼；逐一辨識每條 URI 的通訊協定、位址、憑證、TLS 與傳輸參數。
決定輸出形式。若只要替換現有設定中的節點，請產生節點清單或提供者資源；若要獨立匯入，請產生包含策略組與規則的主設定。
檢查範本變更。轉換範本可能會加入 DNS、規則提供者或 TUN 欄位。請逐項檢查，不要把這些新增內容誤認為訂閱原始設定。

用戶端的「從連結匯入」不一定相容於所有回應格式。有些入口要求完整 YAML，有些允許匯入節點 URI，另一些則會呼叫額外的轉換服務。請依目前用戶端的入口說明操作；只修改連結名稱並不會改變回應本文。

將 Clash YAML 轉成 URI 或 Base64

從 proxies 擷取實際節點。若主設定只引用 proxy-providers，就必須取得對應的提供者資源，不能把提供者的 URL 當成節點位址。
依照各通訊協定的 URI 規範序列化連線參數。必須明確記錄目標用戶端不支援的欄位，不可默默捨棄。
每行放一條 URI。只有接收端要求 Base64 訂閱時，才依約定編碼整份清單。
在接收端重新匯入，核對節點數量與重要欄位，再測試連線。

這類反向轉換通常會遺失資訊。匯出節點 URI 時，proxy-groups、rules、dns、tun 與本機監聽埠不會一併轉移。即使節點可以連線，流量處理方式也可能與原設定不同，接收端仍須另外建立分流策略。

轉換後檢查：從語法到實際流量

「匯入成功」只表示某個入口接受了檔案，不代表所有欄位都已保留，也不代表所有連線都可用。建議依照以下順序驗證，先排除結構問題，再找出網路問題。

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

若已安裝 mihomo 命令列核心，可在設定所在目錄執行以下檢查。此命令會讀取並測試設定，不會啟動長時間執行的代理服務；若設定依賴相對路徑資源，請同時備妥相應檔案，並留意檢查輸出中的資源載入錯誤。

mihomo -t -f ./config.yaml

請特別檢查 YAML 縮排、重複的節點名稱、策略組引用及不支援的通訊協定欄位。密碼字串建議保留引號，避免 # 被視為註解，或某些值被解讀成其他 YAML 型別。請勿以定位字元代替縮排空格。

第二步：逐項比對，不要只看節點名稱

數量：原始清單有幾個項目，轉換後又有幾個；遭篩選或去重的項目應有明確原因。
連線：比對 server、port、憑證、加密方式與 TLS 參數。
傳輸：核對 WebSocket 路徑、Host、gRPC 服務名稱等通訊協定相關選項。
引用：確認策略組指向現有節點，規則指向現有群組；群組名稱的空格與大小寫也必須一致。
本機入口：本範例的應用程式應連線至本機的 127.0.0.1:7890，而不是遠端節點的 443 埠。

第三步：分別測試 TCP、DNS 與 UDP

先選定一個節點，使用明確設定代理的應用程式瀏覽 HTTPS 網頁，再查看連線記錄中的出口與錯誤訊息。延遲測試成功只代表該次測試請求當下完成，不表示影片、遊戲或所有目標網站都能使用。若網域解析失敗，請檢查 DNS 設定；若 TLS 握手錯誤，請核對 SNI、系統時間與憑證，不要直接關閉憑證驗證。

如果 HTTP 代理運作正常，但遊戲仍直接連線，問題可能出在流量接入方式。轉換節點格式不會自動啟用 TUN，也不會讓所有應用程式的流量自動經過代理。若需要全域接管或 UDP 轉送，請另外檢查 TUN、路由與用戶端權限；這些屬於執行設定，不是 Base64 編碼層的問題。

常見問題與格式選擇

為什麼轉換服務顯示成功，用戶端卻提示沒有可用節點？

先確認輸出本文是否真的包含 proxies 清單，再檢查節點是否被篩選規則全部移除、目標核心是否支援該通訊協定，以及策略組是否仍引用轉換前的舊名稱。HTTP 請求成功不代表轉換結果有效；回傳內容也可能只是服務錯誤說明。

把設定轉成 Base64 後，分流規則還會保留嗎？

任何文字都可以編碼成 Base64，並保留其位元組內容，但接收端必須知道如何解讀。常見的「Base64 訂閱」慣例是節點 URI 清單，而不是編碼後的完整 YAML。將整份 YAML 編碼，並不會讓只辨識 URI 清單的用戶端理解其中的分流規則。

轉換後還能自動更新嗎？

本機匯出的檔案是當下的快照，不會自動同步。遠端轉換網址能否更新，取決於它是否每次重新取得來源、如何快取，以及用戶端的更新行為。透過 proxy-providers 更新節點時，主設定中的策略組與規則仍由主設定管理。

訂閱轉換應在本機進行，還是使用線上服務？

優先使用訂閱提供方直接提供的目標格式，減少中間環節。若必須轉換，本機工具較容易控制憑證的流向。使用線上服務代表要將訂閱網址或節點參數提交給該服務；即使網址經過 Base64 編碼，接收方仍可還原，請先確認是否信任該服務。

選擇原則可歸納為兩點：若要一併遷移節點、策略組與分流規則，優先使用目標核心支援的完整 YAML；若只需交換節點，則使用接收端支援的 URI 或節點清單。更多欄位說明請參閱設定參考；用戶端選擇可查看選型指南。