Clash 訂閱格式解析：Base64 節點連結、YAML 設定與轉換

訂閱網址、節點連結與設定檔

同樣稱為「訂閱」，實際提供的內容可能大不相同：可能是一個 HTTPS 網址、幾行以 ss:// 開頭的節點連結，或一份含有 proxies: 的 YAML 檔案。判斷能否匯入 Clash，關鍵不在網址長短或檔案副檔名，而在於用戶端取得的回應內容，以及目前的核心是否能解析其中的欄位。

訂閱網址是取得內容的入口，訂閱格式是入口回傳的資料結構，代理協定則是節點與伺服器通訊的方式。三者不可混為一談。將檔名從 nodes.txt 改成 config.yaml 不會改變格式；將文字做 Base64 編碼，也不會讓用戶端支援新的協定。

• 訂閱網址：通常是附有帳戶權杖的 HTTPS URL，用來定期抓取更新；回傳內容由伺服器決定。
• 節點分享連結：以協定相關的 URI 表示單一節點，例如 ss://、vmess://、trojan://。不同協定的欄位編碼方式各不相同。
• 完整設定檔：除了節點，也可能包含策略群組、規則、DNS、監聽連接埠及外部資源。

Base64 訂閱：編碼後的節點連結集合

常見的通用訂閱會先將多個節點分享連結逐行排列，再將整段文字做 Base64 編碼。解碼後得到的是一組 URI，而不是 Clash 可直接載入的完整設定檔。有些服務則會直接回傳未編碼的連結清單，或 JSON 等其他格式，不能只憑「看起來像一長串字母」就下結論。

Base64 不提供加密保護

例如 aGVsbG8= 解碼後就是 hello。Base64 只是將位元組轉換成方便以文字傳輸的表示方式，不需要金鑰。訂閱中的密碼、UUID、伺服器位址即使經過編碼，取得內容的人仍可能還原。

標準 Base64 常見字元包括英文字母、數字、+、/，結尾可能有 =；URL 安全變體則使用 -、_，部分實作會省略填充字元。解碼失敗也可能是變體或換行處理所致，不應立即認定訂閱已失效。

外層解碼後，仍須另外解析單一連結

傳統的 vmess:// 分享連結常將 JSON 放在 Base64 載荷中；ss:// 則有自己的使用者資訊編碼方式及外掛參數規範。解碼外層訂閱與解析單一協定連結是兩個步驟，不能反覆按同一個「解碼」按鈕來取代協定解析器。

Clash YAML：節點、策略群組與規則的組合

YAML 是一種資料表示語言，並非 Clash 專用格式。只有符合目前核心設定結構的 YAML 才能作為設定檔使用。語法正確但內容只是一般文件的 YAML，仍不能當作 Clash 設定檔匯入。

僅供理解結構的設定範例

以下範例使用混合連接埠 7890，只包含直連策略，沒有遠端代理節點，不能用來驗證代理服務是否可用。此範例用來說明清單、縮排、策略群組引用與兜底規則之間的關係。7890 是此範例採用的數值，不代表所有用戶端都使用這個連接埠。

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

proxies: []

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

rules:
  - MATCH,出口選擇

YAML 縮排應使用空格，不可用 Tab 取代層級縮排。含有 #、冒號等特殊字元的密碼建議加上引號；節點名稱也應保持一致。若將上例的規則目標改成不存在的「代理出口」，即使縮排完全正確，設定檔驗證仍可能失敗。

也要區分完整設定檔與節點提供器資源。常見的 YAML 節點資源只有頂層 proxies:，適合由 proxy-providers 引用，但不等於已設定好分流規則的完整設定檔。有些用戶端會自動補齊策略群組，有些則不會，因此不能預期匯入結果都相同。

格式相容與核心相容是兩項檢查

Clash 用戶端負責介面、訂閱管理與系統整合；核心則負責連線、解析及執行規則。Clash Meta 後續以 mihomo 之名持續發展，但「支援 Clash 設定」不代表不同世代的核心支援完全相同的欄位。

例如，包含 VLESS、Hysteria2 或 TUIC 等節點的設定檔，必須確認目標核心及其具體版本支援哪些功能。將這些節點轉成 YAML，不會讓較舊的 Clash 核心取得相應的協定實作。即使支援該協定名稱，Reality、傳輸層或 TLS 參數也可能有版本要求。

1. 先檢查輸入格式：匯入功能接受的是訂閱 URL、完整設定檔，還是單一節點分享連結？「從剪貼簿匯入」也不一定支援所有 URI。
2. 再確認核心類型：在用戶端的「關於」或核心管理頁面確認實際執行的核心，不要只看應用程式名稱。
3. 最後檢查欄位：記下完整的設定檔驗證錯誤，確認問題出在節點類型、傳輸參數或資源引用，避免反覆重新安裝用戶端。

以 Clash for Android 常見介面為例，遠端設定通常可從「設定」→「＋」→「從 URL 匯入」新增；匯入後還要選取該設定並啟動服務。其他用戶端可能將相同功能放在「設定」或「訂閱」頁面，按鈕名稱也會隨版本改變，請以目前介面為準。如果只有單一節點連結，別直接假設貼到「設定 URL」欄位就能完成匯入。

訂閱轉換：解析節點，再產生目標設定檔

訂閱轉換不是替 Base64 文字換個副檔名。轉換器通常會先取得來源內容、識別並解析各個節點，再建立內部表示，最後依目標格式產生節點欄位。若目標是完整 Clash 設定檔，也可能套用規則範本、建立策略群組、設定 DNS，或加入自動測速設定。

哪些內容可轉換，哪些可能遺失

• 通常可以對應：目標核心支援時，伺服器位址、連接埠、密碼或 UUID，以及有明確對應欄位的 TLS 和傳輸參數。
• 可能無法保留：目標格式不支援的外掛選項、協定專屬參數、用戶端私有擴充，以及來源不明的憑證設定。
• 需要重新設計：規則、DNS、策略群組巢狀結構及測試策略。節點連結本身通常沒有足夠資訊可還原這些設定。

反過來說，將完整 YAML 匯出成通用節點連結，通常也只會保留節點。原有的分流規則、DNS 和策略群組選擇邏輯不會自動加入每條 URI。因此，「YAML → 連結清單 → YAML」不保證能還原原始設定，不能把這種來回轉換當成備份方式。

線上轉換的憑證風險

如果將訂閱 URL 交給線上轉換服務，該服務通常需要存取來源訂閱，因此也能取得網址中的權杖及回傳的節點憑證。即使瀏覽器以 HTTPS 連線至轉換頁面，也只保護傳輸路徑，無法阻止服務端讀取這些資料。

優先使用服務提供者提供的 Clash 或 mihomo 專用訂閱；確實需要轉換時，選擇了解其運作方式的工具，並在可行情況下於本機處理。分享轉換結果前，也要檢查完整網址，因為來源訂閱可能藏在查詢參數中。若不慎外洩，請在服務提供者的管理後台重設訂閱權杖，並確認是否還需要更換節點驗證資訊。

匯入失敗：依序排查回應、解析與連線

「訂閱匯入成功」和「節點連線成功」是不同階段。排查時先保留原始設定檔，不要同時修改 DNS、規則、連接埠和 TUN。每次只調整一個環節，才容易找出問題來源。

HTTP 200 只表示請求收到回應，不保證正文就是設定檔；Content-Type 也只能作為參考。瀏覽器能開啟、用戶端卻無法抓取時，還可能與重新導向、憑證信任、請求標頭或網路路徑差異有關。不要把瀏覽器工作階段 Cookie 當成通用解法，也不要為了排錯而停用憑證驗證。

更新後失效，先確認修改內容儲存在哪裡

更新遠端設定時，通常會重新下載內容。直接編輯下載的檔案，可能在下次更新時遭到覆寫。若只想補充個人規則，應優先使用用戶端明確支援的覆寫、合併或擴充功能，並確認處理順序；這些功能屬於用戶端，各家的選單與語法並不一致。

也要檢查策略群組是否引用了已重新命名或遭篩除的節點，以及外部節點資源是否更新成功。遠端設定本身下載成功，不代表它引用的所有資源也都已成功取得。

匯入訂閱前的選擇清單

1. 已有 Clash 或 mihomo 專用訂閱：優先直接匯入，並先確認與目前核心相容，以減少轉換環節。
2. 只有通用 Base64 訂閱：查看用戶端是否內建節點解析或轉換功能；若沒有，再選擇合適的轉換工具。
3. 只有單一分享連結：尋找明確支援該協定的節點匯入功能；若需要完整設定檔，還得補上策略群組與規則。
4. 取得 YAML 檔案：先確認是完整設定檔還是節點資源，再檢查語法、引用關係與核心支援情況。
5. 準備替換目前使用的設定檔：先保留可用版本，新設定通過驗證後再切換，並確認節點數量、策略群組及規則運作正常。

格式檢查回答的是「資料能否讀懂」，核心相容性回答的是「協定能否執行」，連線記錄則能進一步說明「服務是否可連線」。將這三個步驟分開處理，通常就能避免在訂閱轉換、用戶端設定和網路故障之間反覆嘗試。初次啟動流程請參閱本站的使用指南；協定與設定欄位則可搭配協定參考查核。