Clash 訂閱格式有哪些？Base64 連結、YAML 設定與通用訂閱的差異及轉換

一、訂閱網址、編碼與設定格式

「訂閱連結」首先是取得內容的入口，並非固定的檔案格式。同一個 HTTPS 網址可能依據請求參數或用戶端識別資訊，回傳不同內容：一組節點分享連結、一份 Clash YAML 設定，或其他用戶端專用設定。網址結尾有沒有 .yaml，都不足以判斷能否直接匯入。

判斷時要分清三個層次：網址負責取得內容，Base64 負責將位元組編碼成文字，設定格式則用來描述節點、策略群組與規則。Base64 不是加密，也不是代理協定；解碼訂閱只能還原原始文字，不會憑空產生分流規則。

二、Base64 節點連結能保留哪些資訊

典型的節點訂閱會先將多條分享連結逐行串接，再對整段文字進行 Base64 編碼。部分協定的分享連結內部也會使用 Base64，因此可能有外層訂閱編碼與內層協定編碼兩層結構。解碼一次後看到 vmess:// 或 ss://，不代表節點參數已全部展開。

分享連結常見欄位

• 連線身分：伺服器、連接埠、密碼或 UUID，以及協定所需的加密方式。
• 傳輸資訊：TLS、SNI、WebSocket 路徑與 Host、gRPC 服務名稱等；是否包含這些資訊，取決於協定與分享格式。
• 顯示資訊：節點備註通常放在 URI 片段中，並以百分比編碼儲存。

例如，兩個節點都連線至 443 連接埠，一個使用一般 TLS，另一個則還需要特定的 WebSocket 路徑。若轉換器只保留伺服器、連接埠和密碼，第二個節點可能會交握失敗。連接埠相同不代表連線參數相同，443 也不能單獨作為啟用 TLS 的依據。

節點分享連結通常不包含完整的 DNS 策略、規則順序、TUN 路由與自動策略群組。將這類訂閱轉成 Clash 設定時，轉換器往往會另外套用範本。因此，新設定中出現的「自動選擇」、「地區群組」可能來自範本，而非原始訂閱。

安全檢視內容

優先使用可信任用戶端的設定預覽，或以本機編輯器檢查回應內容。如需解碼，請使用本機工具，並避免將完整內容寫入公開的終端機記錄。解碼後取得的密碼、UUID 與訂閱權杖仍屬敏感資訊；回報問題時，只提供移除憑證後的結構與錯誤行號。

三、完整 YAML 與節點提供者的差異

YAML 是資料的表示方式，不代表檔案一定完整。Clash 系列設定通常以 proxies 定義節點、透過 proxy-groups 安排選擇方式，再用 rules 決定連線去向。以下範例說明三者的引用關係；範例網域和密碼不可用於實際連線。

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

proxies:
  - name: 範例節點
    type: trojan
    server: edge.example.com
    port: 443
    password: example-password
    sni: edge.example.com
    skip-cert-verify: false

proxy-groups:
  - name: 手動選擇
    type: select
    proxies:
      - 範例節點
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,手動選擇

這裡的 7890 是本機 HTTP/SOCKS 混合代理的監聽連接埠，不是遠端節點連接埠。最後一條 MATCH 會將先前未符合的連線交給「手動選擇」。若轉換時更改群組名稱，卻沒有同步修改規則引用，設定可能無法載入。

proxy-providers 需要搭配主設定

代理提供者將節點更新與主設定分開。mihomo 一般 YAML 提供者檔案的頂層通常是 proxies:；主設定會在 proxy-providers 中宣告該檔案，再由策略群組透過 use 引用。只有節點清單的檔案，不等於已具備規則與策略群組的主設定。

部分用戶端可以為純節點內容自動補上預設群組，但這是匯入器的功能，不能因此推論所有用戶端都支援。選擇遠端設定時，應先確認入口要求的是「完整設定」還是「節點提供者」。若要保留自訂規則，可考慮主設定搭配提供者，或使用用戶端支援的覆寫機制；不要一再手動修改會在訂閱更新時被覆蓋的檔案。

四、訂閱轉換時容易遺失的欄位

轉換通常會經過「解析來源內容 → 產生中介節點資料 → 輸出目標格式」等步驟。任何階段不認得的欄位，都可能遭到忽略、改名或替換成預設值。成功產生 YAML 只代表輸出了文字，不表示目標核心能依照原始參數連線。

Clash、Clash Premium 與 Clash Meta（現稱 mihomo）支援的欄位範圍並不完全相同。轉換器中的「Clash」目標也可能輸出相容於舊核心的格式；使用 mihomo 時，應選擇明確支援所需協定與欄位的輸出目標。不能只因檔名包含 Meta 就判定相容，也不宜單憑圖形用戶端版本推斷核心能力。

五、依序完成訂閱轉換與匯入

1. 優先選擇原生輸出。若服務商已提供適用於目前核心的 Clash 或 mihomo 設定，請先直接使用，減少中間解析步驟。正常的 YAML 不需要再套用一層轉換。
2. 確認下載內容。檢查回傳的是節點文字、YAML，還是登入頁面或錯誤頁面。HTTP 回應成功不代表內容就是設定；以 <!DOCTYPE html> 開頭的內容通常無法作為訂閱載入。
3. 選擇可信任的轉換環境。若必須轉換，優先考慮在本機執行的工具，或可信任服務商提供的轉換入口。線上轉換服務可能會接觸原始訂閱權杖與節點憑證。
4. 確認目標核心與範本。先確認所需協定可以輸出，再選擇規則範本；若只需要節點集合，請確認輸出格式適用於代理提供者，而不是直接取代主設定。
5. 使用新設定進行測試。保留目前可用的設定，將轉換結果作為獨立設定匯入。先查看設定檢查結果，再啟動核心；發生錯誤時依據記錄定位，不要直接覆寫唯一可用的檔案。
6. 確認最終生效的內容。用戶端可能會套用全域覆寫、合併或指令碼處理。請檢查處理後的群組名稱、規則、DNS 與連接埠，而非只查看下載的原始 YAML。

轉換網址中的來源訂閱網址通常需要編碼為參數。若來源網址本身含有 & 或 #，直接串接可能截斷權杖，或將部分內容變成另一個參數。請使用工具提供的輸入欄位或標準 URL 編碼功能，不要反覆手動編碼整個網址，也不要將產生的網址貼到公開討論區。

六、匯入成功後的四項檢查

1. 節點數量與重要參數

假設來源訂閱有 12 個節點，但轉換結果只有 9 個，應先檢查協定支援、地區篩選與去重設定。接著抽查至少一個可用節點的伺服器、遠端連接埠、SNI 與傳輸參數。數量相同也不能證明欄位完整；重新命名還可能影響依名稱篩選的規則。

2. 設定語法與引用

YAML 階層使用空格，不要使用 Tab。遇到 proxy not found 之類的錯誤時，請檢查群組內的引用與規則目標；遇到解析錯誤時，從記錄標示的行號及上一行開始檢查縮排、冒號與引號。節點名稱含有特殊字元時，使用正確的 YAML 引號可減少歧義。

3. 延遲、實際請求與規則命中

延遲測試成功只代表該測試請求收到回應，不代表所有網站都能存取。先使用系統代理驗證瀏覽器請求，再查看連線面板中的規則、策略群組與最終節點。確認基本連線正常後，若需接管不遵循系統代理的應用程式，再設定 TUN，避免將路由、DNS 與格式問題混為一談。

4. 訂閱更新是否會覆蓋修改

手動更新一次訂閱，確認自訂規則是否仍存在、節點提供者是否已更新，以及策略群組是否仍可選取節點。HTTP 提供者的 interval: 3600 表示更新間隔以秒計算，也就是 1 小時；圖形用戶端的訂閱更新週期可能是另一項設定，不要與節點健康檢查間隔混為一談。

七、格式選型與常見問題

為什麼 Base64 解碼後還是無法直接匯入？

解碼只會還原內容，不會組成 Clash 設定。取得節點 URI 清單後，需要用戶端支援匯入分享連結，或將內容轉換成目標核心可讀取的節點定義。將文字檔副檔名改成 .yaml 不會改變其內部結構。

其他用戶端的 JSON 可以直接轉成 Clash 嗎？

這取決於轉換器是否支援該種特定結構。例如 sing-box 的 JSON 不只描述出站設定，也可能包含其專屬的 DNS 與路由邏輯；即使節點參數可以轉換，路由語意也不一定能一對一遷移。節點遷移與規則重建應分別檢查，不能把「支援 JSON」理解成支援任意用戶端設定。

長期使用時，該選完整設定還是節點提供者？

若想直接採用服務商預設的規則，原生完整設定較省步驟；若要長期維護自訂分流，主設定搭配節點提供者通常更容易分開管理更新。只有 Base64 節點訂閱時，再考慮以明確目標進行轉換。無論採用哪種方式，都應保留原始入口、確認核心支援範圍，並以實際連線與規則命中作為最終驗證。