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

先看回傳內容：訂閱網址不等於設定格式

匯入 Clash 訂閱失敗，先別急著換客戶端。同一個 HTTPS 網址，可能回傳可直接使用的 YAML 設定，也可能回傳一串 Base64 文字，甚至是登入頁面。網址結尾的副檔名並不可靠：沒有 .yaml 副檔名的介面也可能回傳 YAML，帶有這個副檔名的網址也可能因驗證失效而回傳錯誤訊息。

把訂閱分成三個層次會更容易判斷：訂閱網址是取得資料的入口，Base64 是文字編碼，YAML 或 URI 才是描述實際資料的格式。YAML 還要再區分完整設定與僅含節點的資料。把節點清單當成完整設定匯入，是常見的錯誤原因。

YAML 設定：節點、策略群組與規則各司其職

YAML 是資料序列化格式，並非 Clash 專用。能通過 YAML 剖析器，只代表語法正確；客戶端還會檢查欄位、節點協定與引用關係。對於以 mihomo 為核心的客戶端，實際支援範圍取決於正在執行的核心，不能只看介面名稱是否含有 Clash。

最小範例的結構

以下示範本機入口、一個 Shadowsocks 節點、一個選擇群組與規則之間的關係。node.example.invalid 是保留的示例網域，密碼也是示範用值，無法用於實際連線。連接埠 7890 是此範例明確設定的本機混合代理連接埠，不代表所有客戶端都使用這個連接埠。

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

proxies:
  - name: "Demo SS"
    type: ss
    server: node.example.invalid
    port: 443
    cipher: aes-128-gcm
    password: "demo-pass"

proxy-groups:
  - name: "手動選擇"
    type: select
    proxies:
      - "Demo SS"
      - DIRECT

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,手動選擇

• proxies：存放伺服器位址、協定、連接埠與驗證資訊。
• proxy-groups：組織節點或其他策略，供使用者選擇或執行自動策略。
• rules：依序比對流量；上例最後的 MATCH 會接手其餘連線。
• mixed-port：提供 HTTP 與 SOCKS 代理入口。客戶端的覆寫設定可能會變更這個值，請以實際執行的設定為準。

這個範例用於說明結構，未涵蓋 DNS、TUN 與區域網路存取策略。它不是通用的網路最佳化方案，也不能據此判定 DNS 請求的實際路徑。匯入真實設定前，請保留服務提供者要求的傳輸層與驗證欄位。

YAML 最容易出錯的三個地方

1. 縮排：請使用空格，不要使用 Tab。上例的清單項目縮排 2 個空格，節點屬性縮排 4 個空格。
2. 字串：含有特殊符號的密碼與節點名稱建議加上引號。未以引號括住的 # 在特定位置會開始註解，造成內容遭截斷。
3. 引用：節點名稱與策略群組名稱必須完全一致。將 Demo SS 改成 Demo-SS 後，群組中的引用也必須同步修改。

Base64 節點字串：先解碼，再匯入

一般所說的「Base64 訂閱」，通常是將多條 URI 連結以換行分隔，再把整段文字編碼成 Base64。解碼後得到的仍是節點清單，不會因此多出規則、策略群組或 DNS 設定。也有服務會編碼其他內容，因此最終仍須以解碼結果判斷。

標準 Base64 常見字元包括 +、/，結尾可能有 =；URL 安全變體則使用 - 和 _。有些介面會省略結尾的補位字元。不要因為沒有等號就認定它不是 Base64，也不要拿整個 HTTPS 訂閱網址去解碼。

在本機查看解碼結果

電腦已安裝 Python 3 時，可將訂閱回傳的編碼本文存成 subscription.txt，並在該檔案所在資料夾執行以下命令。程式只會讀取本機檔案，並將結果寫入 decoded.txt，不會上傳內容。輸出檔案同樣含有敏感憑證，使用後請妥善清除。

python3 - <<'PY'
from pathlib import Path
import base64
import binascii

raw = Path("subscription.txt").read_text(encoding="utf-8-sig")
encoded = "".join(raw.split())
encoded += "=" * (-len(encoded) % 4)

try:
    decoded = base64.b64decode(
        encoded, altchars=b"-_", validate=True
    ).decode("utf-8")
except (binascii.Error, UnicodeDecodeError, ValueError) as error:
    raise SystemExit("解碼失敗：請檢查輸入是否為 Base64 文字") from error

Path("decoded.txt").write_text(decoded, encoding="utf-8")
print("已寫入 decoded.txt，請在本機查看")
PY

這段命令使用類 Unix shell 的 here-document 寫法，適用於 macOS、Linux 等環境；Windows 使用者可將中間的 Python 程式碼存成腳本後執行。解碼失敗時，先確認是否誤存網頁內容、複製不完整，或連同檔案外層的引號一起複製。

URI 連結：一條連結描述一個節點

URI 通常以協定名稱開頭，例如 ss://、vmess://、vless:// 或 trojan://。這些連結並非共用相同的內部編碼。常見的 VMess 分享連結會將 JSON 編碼後放進連結；其他協定則可能透過使用者資訊、主機、連接埠與查詢參數組合來描述連線。

Shadowsocks 範例：只編碼驗證資訊

ss://[email protected]:443#Demo%20SS

在這個範例中，YWVzLTEyOC1nY206ZGVtby1wYXNz 解碼後是 aes-128-gcm:demo-pass；node.example.invalid:443 是伺服器與連接埠；#Demo%20SS 則是經過百分比編碼的顯示名稱。它對應前文的示範節點，但不包含策略群組與分流規則。

• 百分比編碼與 Base64 不同：%20 代表空格，應依 URI 元件解碼，不要當成 Base64 處理。
• 名稱不等於參數：連結末尾的備註通常只影響顯示；查詢參數中的傳輸設定則可能直接影響連線是否成功。
• IPv6 位址須留意方括號：URI 的主機位置通常要使用 [IPv6地址]:連接埠 的結構，不能單純依每個冒號切割。
• SS 分享格式有多種變體：驗證資訊編碼、舊式整體編碼與外掛參數的相容性各不相同，轉換器必須辨識實際格式。

不要手動套用「遇到冒號就拆開」的處理方式。密碼可能含有特殊字元，IPv6 位址本身就有冒號，WebSocket 路徑也可能包含查詢參數。可靠的轉換必須依協定解析，而不是用同一套字串取代規則處理所有連結。

格式轉換：哪些內容能保留，哪些會遺失

格式轉換的關鍵在於欄位對應，而不是單純更改副檔名。只有來源格式包含某項資料，且目標格式與目標核心都支援時，轉換器才可能完整保留該資料。先確認目標是「節點清單」、「provider 資料」還是「完整設定」，再選擇轉換方式。

轉換後逐項核對以下欄位

1. 基本連線資訊：伺服器、連接埠、密碼或 UUID、協定類型。連接埠必須保留原值，不能把所有節點都改成 443。
2. 加密與 TLS：Shadowsocks 的加密方式、TLS 開關、SNI、ALPN，以及憑證驗證設定。不要為了通過測試而隨意啟用略過憑證驗證。
3. 傳輸層：WebSocket 的路徑與 Host、gRPC 的 service name 等。即使位址與密碼相同，傳輸層不同也可能無法連線。
4. 協定擴充：Reality 公鑰與 short ID、VLESS flow 等欄位，須同時受到轉換器與核心支援。
5. 命名與引用：請妥善處理重複的節點名稱；重新命名後也要更新策略群組的引用，避免只修改節點清單卻留下無效名稱。

原版 Clash 與 mihomo 的功能支援範圍並不相同。目標核心不支援的協定，不會因為「轉換成 Clash 格式」就變成支援。遇到新協定時，確認目前的核心版本與對應欄位文件，比反覆更換訂閱轉換範本更有效。

匯入方式：完整設定與節點提供者分開處理

完整 YAML：以設定檔匯入並啟用

客戶端通常會在「設定」或「Profiles」頁面管理完整設定。各客戶端的選單名稱不盡相同，操作時請確認選擇的是「從 URL 匯入設定」或「匯入本機設定」，而不是「新增單一節點」。匯入完成後還須啟用該設定，並檢查執行記錄。檔案出現在清單中，不代表它已成為目前使用的設定。

只有節點：使用 provider 或受控合併

mihomo 的代理提供者可將節點來源與主設定分開管理。為方便在不同客戶端間移轉，建議優先使用明確包含 proxies: 的 YAML provider 檔案；其他輸入格式是否可用，請依所用核心版本確認。以下範例引用一個本機節點檔案，並透過 use 將節點加入策略群組。

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/nodes.yaml

proxy-groups:
  - name: "訂閱節點"
    type: select
    use:
      - local-nodes

rules:
  - MATCH,訂閱節點

./providers/nodes.yaml 應包含類似前文的 proxies: 節點清單。相對路徑的解析位置會受核心工作目錄與客戶端管理方式影響，不一定是下載檔案所在的資料夾。這段內容須合併至主設定，避免重複宣告同名的頂層鍵或策略群組。

遠端 HTTP provider 也涉及更新網址、快取路徑與更新間隔。若設定 interval: 86400，單位為秒，也就是每 24 小時更新一次。遠端節點清單與主設定的更新是兩個流程：前者更新節點，後者可能覆蓋規則、DNS 等整份設定。

匯入失敗排查：依序檢查回應、語法、核心與執行狀態

1. 檢查回傳內容。下載至本機後，查看檔案開頭幾行。HTTP 200 只表示請求成功取得回應，不保證本文就是設定；401、403 則應優先檢查驗證資訊與存取限制。有些服務會依 User-Agent 回傳不同格式，瀏覽器與客戶端看到的內容可能不一樣。
2. 檢查外層編碼。如果內容是 Base64，先解碼一次並查看結果。不要一再盲目解碼，也不要把訂閱網址、網頁本文與編碼後的節點字串混在一起處理。
3. 檢查 YAML 語法。「mapping」、「indentation」等錯誤通常與縮排、冒號或引號有關。記下錯誤行號，並檢查前後幾行；不適合將含有憑證的真實設定貼到線上 YAML 檢查工具。
4. 檢查欄位是否受支援。「unsupported proxy type」通常表示協定與核心功能不相容。先確認客戶端實際啟動的是哪個核心，再查看該核心的版本與支援清單。
5. 檢查名稱引用。遇到「proxy not found」之類的錯誤，請確認節點名稱、策略群組名稱與 provider 名稱是否一致。完整設定即使包含節點，若沒有可用的策略，也可能無法套用預期的分流方式。
6. 檢查執行狀態。設定載入成功後，再確認本機代理連接埠、系統代理或 TUN 是否已按需求啟用。匯入成功、啟用代理入口與節點能夠連線，是三個不同的檢查項目。

轉換後若出現「節點測速正常，網頁卻無法開啟」，也不應立刻歸因於編碼問題。測速只涵蓋指定的測試請求；實際連線還會受到 DNS、路由規則、UDP 支援與應用程式代理設定影響。先查看失敗的連線套用了哪項策略、選用了哪個節點，再定位問題環節。

格式選型結論：優先取得目標客戶端可直接使用的資料

• 需要直接匯入使用：優先選擇服務提供者明確標示適用於目前核心的完整 Clash 或 mihomo 設定，再確認分流與 DNS 設定。
• 已有自己的規則：優先使用 provider 節點資料，讓主設定保持獨立，減少訂閱更新覆蓋本機設定的機會。
• 要在不同客戶端間移轉節點：URI 清單方便傳送單一節點，但須逐項確認協定擴充，不要預期它能保留原有的所有策略。
• 收到 Base64 文字：先在本機解碼並辨識內容。編碼只是外層包裝，真正決定匯入方式的是內部資料結構。

確實需要轉換時，優先使用在本機執行的工具或自行掌控的服務。遠端轉換服務可能取得訂閱憑證或節點資訊，輸出內容也可能加入額外規則與設定。請保存原始輸入、轉換結果與一份可用的備份，依「檢查結構 → 對照欄位 → 啟用測試」的順序處理，發生問題時才有明確的復原依據。