Clash 訂閱格式解析：YAML 設定、Base64 連結與 SIP008 轉換教學

先確認訂閱回傳的內容，再決定是否轉換

「訂閱連結」只表示用戶端會透過某個網址取得內容，不代表內容一定是 Clash 設定。同一個 HTTPS 網址可能回傳完整 YAML、Base64 編碼的節點清單、SIP008 JSON，甚至是登入頁面。匯入失敗時，先查看回應本文，比反覆更改副檔名有效。

還要區分三個層次：訂閱 URL 是取得內容的入口；YAML、JSON、Base64 是內容結構或編碼方式；Shadowsocks、Trojan、VLESS 等則是節點使用的代理協定。解碼 Base64 不會把 Shadowsocks 節點變成其他協定，也不會自動產生規則分流。

內容類型	辨識線索	匯入 Clash 的處理方式
完整 YAML	常見欄位包括 `proxies:`、`proxy-groups:`、`rules:`	確認目標核心相容後，匯入作為設定檔
節點型 YAML	主要包含 `proxies:`，缺少策略組與規則	作為節點來源使用，或補齊設定結構
Base64 節點訂閱	編碼文字；解碼後常見多行 `ss://` 等連結	解析節點後產生 YAML 設定
SIP008 JSON	常見欄位包括 `version` 和 `servers`	將 Shadowsocks 伺服器欄位轉換為節點
HTML 或錯誤 JSON	登入提示、拒絕存取、流量額度錯誤	先排除訂閱存取問題，轉換無法解決

Clash YAML：節點、策略組與規則之間的關係

Clash 系列核心使用 YAML 表達執行設定。節點負責連線至遠端伺服器；策略組將多個節點組織成手動選擇、自動測速或故障切換的入口；規則則依序比對連線目標，將流量交給指定策略。監聽連接埠、DNS 與 TUN 則屬於本機網路連線設定。

完整設定不等於節點清單

proxies 中有節點，不代表流量就會使用它們。如果最後一條規則仍是 MATCH,DIRECT，未符合前面規則的連線就會直接連線。如果規則引用不存在的策略組，設定可能無法載入。訂閱轉換必須一併處理節點名稱與策略引用，不能只把幾段文字串在一起。

以下是用來說明結構的直連範例，不包含遠端代理節點。監聽連接埠設為 7890，且只允許本機存取；所有流量都交由「出口選擇」，而該組只有 DIRECT。這份設定無法用來確認遠端節點是否可用。

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

proxies: []

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

rules:
  - MATCH,出口選擇

YAML 語法與核心支援度要分別檢查

縮排請使用空格，不要使用 Tab。同一層級的縮排要一致，範例採用兩個空格。
建議將節點名稱、密碼及含特殊符號的字串加上引號，避免被解讀成其他資料類型。
YAML 可以解析，只代表語法正確；協定類型、傳輸參數與策略組選項仍須獲得目標核心支援。
傳統 Clash 與 Clash Meta（現名 mihomo）的支援範圍不同。使用 VLESS、Hysteria2 等節點時，應查閱目標核心的文件，不能只憑用戶端名稱判斷相容性。

Base64 訂閱：解碼只會還原文字，不會產生規則

常見的 Base64 訂閱會先將多條分享連結逐行排列，再把整段文字編碼。解碼後可能會看到 ss://、trojan://、vmess:// 或 vless://。每種連結都有各自的欄位規則，轉換器必須逐一辨識。

內容也可能有內外兩層編碼：外層是訂閱清單的 Base64，內層則是單一分享連結中的編碼資料。例如，部分 Shadowsocks 連結會將認證資訊編碼；常見的 VMess 分享連結則以 Base64 承載 JSON。只解開外層後，節點資訊未必都能直接讀取。

在本機檢查訂閱內容

將訂閱回應儲存為 subscription.txt 後，即可在本機解碼。以下指令適用於常見的標準 Base64 文字；輸出檔案含有節點憑證，請存放在私人資料夾，不要上傳至公開儲存庫。

# Linux：GNU coreutils
base64 --decode subscription.txt > nodes.txt

# macOS
base64 -D -i subscription.txt -o nodes.txt

如果工具提示編碼無效，請先確認下載到的內容是否為 HTML，以及是否使用 URL 安全字元、缺少填充字元或含有額外包裝。不要把所有錯誤都歸咎於「訂閱壞了」。部分轉換器能相容這些變體，但實際支援情況取決於各自的實作。

SIP008：Shadowsocks 伺服器的 JSON 訂閱格式

SIP008 是 Shadowsocks 生態系中的一種訂閱規範，不是通用代理協定，也不是 Clash 設定。其 JSON 以伺服器陣列描述節點，常見欄位包括伺服器位址、連接埠、加密方式與密碼。標準結構可包含多個 Shadowsocks 伺服器，但不會因此具備 Clash 的策略組或分流規則。

以下使用保留的範例網域展示欄位關係，密碼也僅用來說明結構，並不對應可連線的服務。實際轉換時應保留服務提供者給的原始認證值。

{
  "version": 1,
  "servers": [
    {
      "id": "80a3cf64-dcec-4ca9-bd7b-b69b9763ca15",
      "remarks": "SS 範例節點",
      "server": "edge.example.com",
      "server_port": 443,
      "password": "demo-password-not-for-use",
      "method": "aes-128-gcm"
    }
  ]
}

SIP008 與 Clash 的欄位對應

remarks 通常會用作 Clash 節點的 name；若名稱重複，需先去重，並同步調整策略組的引用。
server 保留為伺服器位址，server_port 對應為 port。
method 對應為 cipher，password 保留作為認證密碼，並設定 type: ss。
如果來源資料包含 plugin 和 plugin_opts，需確認目標核心支援的外掛程式及參數格式，不能直接照原樣複製成 Clash 欄位。

部分服務端回傳的是自訂 JSON 或舊式陣列，與上述結構不完全相符。轉換工具即使標示「支援 SIP008」，也未必相容所有變體。若出現「沒有可用節點」，應檢查回應的頂層結構與必填欄位，而不是反覆嘗試相同的匯入操作。

訂閱轉換流程：從原始回應到完整 YAML

優先使用來源網站提供的目標格式

如果訂閱管理頁面已提供 Clash 或 mihomo 專用入口，請優先使用對應選項。這通常能減少中間轉換步驟，並保留服務提供者設定的節點參數。同一個訂閱網址有時會依請求參數或 User-Agent 回傳不同格式，因此瀏覽器中看到的結果不一定與用戶端取得的內容相同。

需要轉換時，依照五個步驟處理

確認目標核心。先在用戶端的「關於」或核心資訊頁面確認使用的是傳統 Clash 還是 mihomo。介面路徑會因用戶端而異，請以實際畫面為準，不要以外層程式名稱代替核心名稱。
辨識來源格式。查看回應開頭與結構，區分 YAML、Base64、SIP008 和錯誤頁面。保留原始檔案以供比對，不要直接覆寫目前使用的設定。
選擇轉換的執行位置。優先使用可信任的本機工具或自行部署的服務。網頁表單不代表資料會在本機處理；如果表單將訂閱網址送到後端，後端就能存取訂閱內容。
選擇輸出範本。確認輸出的是完整設定，還是僅包含節點的 provider 檔案。檢查策略組、規則與 DNS 設定是否符合需求，不要直接套用為其他核心設計的範本。
儲存、驗證並試跑。將輸出另存為 YAML 檔案，使用目標核心測試後再匯入用戶端。先保留舊設定，確認連線與更新都正常後，再切換為日常使用。

轉換器中的「Clash」與「Clash Meta」目標選項可能代表不同的序列化能力。選擇傳統目標可能會捨棄新協定或傳輸參數；選擇 mihomo 目標，也不會讓傳統核心讀懂新增欄位。輸出格式必須與實際執行的核心相符。

匯入前檢查：欄位保留、設定測試與實際連線

「成功產生檔案」不等於「成功連線」。檢查分成三個層次：先檢查語法與設定引用，再檢查節點交握，最後檢查規則命中情況與目標網站連線。如此才能區分解析錯誤、認證錯誤與分流錯誤。

使用目標核心測試設定

如果已安裝 mihomo 命令列程式，可使用它測試轉換結果。指令中的 converted.yaml 是儲存在本機的輸出檔名；如果檔案不在目前目錄，請使用實際檔案路徑。

mihomo -t -f ./converted.yaml

設定測試可能需要讀取外部 provider 或規則資源，執行環境也會影響結果。測試通過只表示此次檢查未發現會阻止載入的問題，不代表伺服器認證成功，也不保證所有網站都能連線。

逐項檢查容易遺失的參數

位址與連接埠：確認 server、port 資訊完整；連接埠為 443 也不代表已啟用 TLS。
認證欄位：確認密碼、UUID、加密方式等協定必要資訊，並留意跳脫字元與 URL 解碼是否正確。
TLS 與傳輸：確認 SNI、憑證驗證、ALPN、WebSocket 路徑及 Host 等欄位；不要透過關閉憑證驗證來掩蓋參數錯誤。
節點引用：策略組引用的名稱必須存在；重新命名節點後，應同步更新相關引用。
本機監聽：範例中的 7890 是本機代理連接埠，不是遠端伺服器連接埠。如果已被其他程序佔用，需協調修改用戶端與應用程式的代理設定。

匯入後先手動選擇一個節點，再查看連線記錄中的目標、命中規則與出口策略。如果記錄顯示 DIRECT，應先檢查規則是否將流量交給代理組。如果已命中節點但交握失敗，再檢查協定參數與伺服器連線狀態。

持續更新：分開管理完整設定與 proxy-providers

一次轉換後儲存為本機 YAML，通常只會得到當下的快照。服務提供者新增節點、更換密碼或移除線路後，本機檔案不會自動同步。只有設定了有效的遠端更新機制，用戶端或核心才有機會取得新內容。

常見做法有兩種：讓用戶端定期更新完整的遠端設定；或在主要設定中保留策略組與規則，透過 proxy-providers 更新節點。後者適合想固定本機分流邏輯的使用者，但必須正確設定 provider、策略組的 use 引用及更新週期。

不要將任意訂閱網址直接當成 provider

一般 YAML 節點 provider 通常需要回傳以 proxies: 組織的節點內容。完整設定、Base64 清單與 SIP008 JSON 不能不加判斷就互換。mihomo 的 provider 支援能力會因核心實作而異，使用其他格式前應先查閱文件並測試。

例如將更新間隔設為 3600 秒，代表每小時嘗試更新一次，但不保證每次請求都成功。網址失效、網路無法連線或轉換服務故障時，仍須查看更新記錄與本機快取。不要只因為已啟用排程器，就認定節點資料是最新的。

常見問題：匯入錯誤、節點遺失與憑證保護

提示 YAML 解析失敗時，該從哪裡檢查？

先查看檔案開頭是否為 HTML、JSON 錯誤訊息或尚未解碼的文字，再依錯誤行號檢查縮排、引號與冒號。網路請求即使回傳 HTTP 200，也可能是登入頁面；狀態碼本身無法證明取得了設定。

轉換後節點數量變少，算是正常過濾嗎？

不能直接認定是正常情況。先檢查地區或名稱篩選條件，再確認目標格式是否支援所有協定，最後檢查重複名稱的去重處理、外掛參數與解析錯誤記錄。節點變少可能是明確篩選，也可能是轉換能力不足，應與來源資料比對確認。

單一節點連結可以直接當成訂閱嗎？

單一分享連結通常只描述一個節點，不包含遠端更新機制。部分用戶端支援新增單一節點，但這不等於匯入完整設定。若要使用規則分流，仍須將該節點加入策略組與規則。

訂閱網址已經傳給第三方，該怎麼處理？

請在服務提供者的後台重設或撤銷原訂閱權杖，更新用戶端儲存的網址，並刪除公開紀錄中的敏感內容。只刪除本機轉換檔案，無法撤銷已外洩的存取權限；是否也要更換節點密碼，則應依服務提供者的憑證機制判斷。

實際操作可歸納為四件事：確認輸入格式、選擇符合核心的輸出、測試最終生效設定，以及保護訂閱憑證。先確實做好這四件事，再調整規則範本與更新方式，排查問題時就能更聚焦。