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

先區分訂閱網址、節點清單與完整設定

Clash 客戶端中的「訂閱」並不是固定的檔案格式。使用者取得的通常只是一個 HTTPS 網址，客戶端存取該網址後，伺服器可能回傳完整的 Clash YAML、僅包含節點的代理提供者檔案，也可能回傳經過 Base64 編碼的通用節點清單。連結外觀可能相似，但回應內容卻完全不同。

完整的 Clash 設定除了節點之外，還可能包含監聽連接埠、運作模式、代理群組、規則集、DNS、TUN 與流量嗅探設定。通用 Base64 訂閱通常只負責傳遞多個節點 URI，例如 ss://、trojan://、vmess:// 或 vless://。節點清單本身不會說明「國外網站要使用哪個群組」、「區域網路位址是否直連」，以及「最終未符合規則的流量如何處理」。

第三種常見內容是 Mihomo 或 Clash 的代理提供者檔案。它同樣是 YAML，但頂層通常只有 proxies:，供主設定中的 proxy-providers 引用。它不一定能直接作為完整設定啟動。釐清這三類內容後，才能判斷應直接匯入、作為 provider 使用，還是先轉換格式。

Clash YAML 設定包含哪些內容

YAML 是易讀的結構化文字。縮排代表層級，清單項目通常以連字號開頭。Clash 與 Mihomo 讀取設定時，會解析欄位名稱、資料類型與縮排關係，因此兩個空格、布林值、引號和冒號都可能影響結果。節點名稱含有冒號、井字號或方括號時，使用引號通常更穩妥。

以下是一份精簡後的結構範例。連接埠 7890、控制連接埠 9090 都是常見的示例值，並非所有客戶端的固定預設值；實際監聽值應以客戶端的「設定」或執行記錄為準。

mixed-port: 7890
allow-lan: false
mode: rule
external-controller: 127.0.0.1:9090

proxies:
  - name: "Tokyo-01"
    type: ss
    server: edge.example.net
    port: 443
    cipher: aes-128-gcm
    password: demo-password

proxy-groups:
  - name: "節點選擇"
    type: select
    proxies:
      - "Tokyo-01"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,節點選擇
  - GEOIP,LAN,DIRECT
  - MATCH,節點選擇

proxies 定義可用節點，proxy-groups 將節點組織成手動選擇、延遲測試或故障轉移群組，rules 依序決定連線去向。規則會由上到下比對，通常由 MATCH 處理前面未符合的連線。只有節點而沒有代理群組與規則時，客戶端可以透過額外範本補齊，但這已是客戶端或轉換器執行的二次處理。

完整設定與 provider 檔案的界線

代理提供者檔案的職責較窄。主設定負責宣告下載網址、重新整理週期與健康檢查，遠端檔案只提供節點。以下的 interval: 86400 表示每 86400 秒，也就是每 24 小時更新一次；健康檢查則每 600 秒存取一次測試網址。

proxy-providers:
  airport-main:
    type: http
    url: "https://sub.example.net/clash-provider.yaml"
    path: ./providers/airport-main.yaml
    interval: 86400
    health-check:
      enable: true
      interval: 600
      url: "https://www.gstatic.com/generate_204"

如果將只有 proxies: 的 provider 檔案直接當成主設定，客戶端可能提示缺少代理群組，也可能在匯入後看不到預期的分流入口。反過來，將包含 DNS、TUN 與規則的完整設定放入 provider 路徑，也不符合 provider 的資料結構。

Base64 訂閱究竟編碼了什麼

Base64 是文字編碼，不是加密。它會將原始節點 URI 轉換成由有限字元組成的文字，方便透過介面傳輸。解碼後通常是一行一個節點，每一行仍需由客戶端依照對應協定解析。Base64 內容可能採用標準字元集，也可能使用 URL 安全變體，以連字號和底線取代加號與斜線。

ss://[email protected]:443#Tokyo-01
trojan://[email protected]:443?security=tls#Singapore-02
vless://[email protected]:443?security=tls&type=ws#Los-Angeles-03

這些 URI 會描述伺服器、連接埠、驗證資訊、傳輸方式與備註，但無法統一承載 Clash 代理群組與規則。轉換器若要產生可執行的設定，就必須額外套用範本。例如將所有節點放入名為「節點選擇」的 select 群組，再加入 DIRECT 與最終的 MATCH 規則。

為什麼有時解碼後仍然看不懂

• 外層 Base64 解碼後可能得到多行 URI，其中某一行 vmess:// 後方仍是獨立的 Base64 JSON。
• 伺服器可能先以 gzip 壓縮回應。瀏覽器和 curl --compressed 通常會自動處理，直接複製原始位元組則可能顯示亂碼。
• 回傳內容可能是錯誤頁面。登入失效、存取頻率受限或權杖過期時，伺服器可能回傳 HTML，而不是訂閱內容。
• 訂閱可能使用 URL 安全 Base64，並省略結尾的填充字元 =，部分嚴格的解碼工具因此會報錯。
• 節點協定或擴充參數超出舊版 Clash 核心的支援範圍時，即使格式成功解碼，客戶端仍可能拒絕載入。

四個步驟判斷手上的訂閱格式

第一步：先查看客戶端顯示的錯誤位置

「下載失敗」和「解析失敗」不是同一個問題。前者通常發生在 DNS、TLS、網路連線、HTTP 狀態碼或訂閱權杖環節；後者表示客戶端已取得回應，但無法依目標格式讀取。如果記錄顯示 HTTP 401 或 403，應先更新訂閱網址。如果顯示 yaml: line 18、mapping values are not allowed 或 proxy 2: unsupported type，才應繼續檢查內容與核心相容性。

第二步：儲存回應，不要只看連結文字

可以在終端機將測試訂閱儲存成檔案。真實訂閱 URL 通常包含存取權杖，不應貼到公開截圖、線上論壇或公開的命令記錄中。以下使用的是示例網域與示範權杖。

curl -L --compressed \
  'https://sub.example.net/api/v1/client/subscribe?token=demo-token' \
  -o subscription.txt

wc -c subscription.txt
head -c 160 subscription.txt

-L 會跟隨重新導向，--compressed 允許伺服器回傳壓縮內容。檔案只有幾十個位元組，且以 <html、{"error" 或登入提示開頭時，問題通常不在 Clash 格式，而在介面回應。正常訂閱可能從數 KB 到數百 KB，沒有統一的長度標準。

第三步：檢查可見欄位

1. 出現 proxies:、proxy-groups: 和 rules:，通常就是完整的 Clash YAML。
2. 只有頂層 proxies: 與節點陣列，通常是 provider YAML。
3. 直接出現多行 ss://、trojan:// 或 vless://，屬於明文節點清單。
4. 主體是一整段 Base64 字串時，先解碼，再依前三項判斷。
5. 出現網頁標題、驗證碼、登入表單或 JSON 錯誤物件，表示伺服器沒有回傳訂閱資料。

第四步：確認目標核心

Clash Premium、Clash Meta 與後續的 Mihomo 並不是完全相同的設定目標。Mihomo 支援更多協定欄位、規則功能、DNS 選項與 TUN 參數。轉換時若只選擇「Clash」這個寬泛目標，可能產生面向舊核心的保守格式，也可能帶入舊客戶端無法辨識的欄位。使用 Mihomo 核心的客戶端，應優先選擇明確標示 Mihomo 或 Clash Meta 的輸出目標。

Base64 與 YAML 的互轉方法

方法一：使用客戶端內建的相容匯入

部分桌面客戶端會在訂閱匯入階段辨識通用 URI 清單，並自動產生本機設定。以採用 Mihomo 核心的客戶端為例，通常可從「訂閱」或「設定」頁面新增遠端 URL，再由客戶端解析回應。具體入口可能顯示為「訂閱」→「新增訂閱」或「設定」→「從 URL 匯入」。匯入後應檢查設定詳細內容，確認已產生代理群組與最終規則，而不是只查看「更新成功」提示。

自動相容功能適合快速使用，但產生策略由客戶端決定。一個客戶端可能將所有節點放入手動選擇群組，另一個則可能新增自動延遲測試群組。遷移到其他客戶端時，群組名稱、規則與 DNS 設定未必一致。

方法二：使用訂閱轉換服務

轉換服務通常會接收來源訂閱、目標格式與範本參數，接著下載來源內容、解析節點，並輸出 Clash 或 Mihomo YAML。常見流程是將目標選為 Mihomo，填入訂閱 URL，指定遠端設定範本，再產生新的訂閱網址。客戶端之後存取的是轉換後的網址，而不是直接讀取原始 Base64。

範本決定最終設定的品質。至少應檢查以下項目：

• 代理群組是否包含所有需要的節點，以及是否存在已引用卻未定義的群組名稱。
• 規則末尾是否有合理的兜底項目，例如 MATCH,節點選擇。
• 區域網路、常見私有位址與本機位址是否依預期直連。
• DNS 設定是否符合目前的網路環境，以及是否誤用了無法存取的上游 DNS。
• TUN、嗅探與 IPv6 設定是否適合目前的作業系統，而不是從範本機械式繼承。
• 輸出目標是否是客戶端實際使用的 Mihomo 或對應的 Clash 核心。

方法三：本機解碼後套用設定範本

如果只想確認 Base64 內容，可以在本機解碼，不必將訂閱交給第三方網頁。以下 Python 3 命令會讀取檔案、補齊缺少的 Base64 填充，並輸出至 decoded.txt。它只負責解碼，不會將 URI 轉換成 Clash 節點物件。

python3 -c "import base64,pathlib; p=pathlib.Path('subscription.txt').read_text().strip(); p += '=' * (-len(p) % 4); pathlib.Path('decoded.txt').write_bytes(base64.urlsafe_b64decode(p))"

head -n 5 decoded.txt

完整轉換還需要逐一解析協定 URI，並正確對應 TLS、WebSocket、gRPC、Reality、UDP 與憑證驗證等參數。手動複製幾個欄位很容易遺漏傳輸層設定，因此較適合除錯少量節點，不適合作為長期維護方式。節點數量較多時，應使用持續維護且明確支援目標核心的本機轉換工具。

轉換後匯入 Clash 或 Mihomo

取得 YAML 後，不要立即覆蓋目前可用的設定。先另存為新設定，再執行語法檢查與小範圍連線測試。桌面客戶端的典型流程是「設定」→「新增」或「從 URL 匯入」→「更新」→「設為目前設定」。不同客戶端的名稱略有差異，但都應保留舊設定，直到新設定完成驗證。

先檢查 YAML 結構

至少確認 proxies、proxy-groups 與 rules 中的名稱能夠互相對應。代理群組引用不存在的節點，或規則指向不存在的群組，都會導致啟動失敗或分流異常。YAML 不能使用 Tab 取代縮排空格，同一層級建議統一使用兩個空格。

接著檢查監聽連接埠

設定寫入 mixed-port: 7890 後，系統代理也應指向本機 127.0.0.1:7890。如果客戶端實際使用 HTTP 連接埠 7890、SOCKS 連接埠 7891，終端機環境變數必須選擇對應協定。連接埠已被其他程序佔用時，記錄中常見的訊息是 address already in use，此時修改格式沒有作用。

HTTP_PROXY=http://127.0.0.1:7890
HTTPS_PROXY=http://127.0.0.1:7890
ALL_PROXY=socks5://127.0.0.1:7891

最後驗證規則、DNS 與 TUN

1. 先在代理頁面手動選擇一個可用節點，排除自動策略群組選擇錯誤。
2. 開啟連線頁面，確認測試請求命中預期的代理群組，而不是 DIRECT 或 REJECT。
3. 查看記錄中的網域解析結果，確認沒有持續出現 DNS 逾時。
4. 先在一般系統代理驗證通過後，再啟用 TUN，以減少同時排查多個變數。
5. 啟用 TUN 後確認客戶端具備所需的系統權限，並檢查預設路由與區域網路存取是否正常。

TUN 模式解決的是接管不讀取系統代理之應用程式流量的問題，不會修復無效節點、錯誤驗證資訊或損壞的 YAML。轉換後連一般代理都無法建立連線時，應先回頭檢查節點參數、核心支援與訂閱有效期限，而不是反覆切換 TUN。

常見匯入失敗與對應處理方式

避免重複轉換

原始訂閱經由轉換服務 A 產生 Clash YAML，再將結果交給服務 B 轉換，容易出現節點備註變更、策略群組重建、規則範本遭覆蓋與參數遺失。應盡量維持單一轉換鏈：原始訂閱直接交給目標轉換器，再由客戶端讀取最終網址。

不要將訂閱更新等同於覆蓋設定

有些客戶端允許使用者在遠端設定的基礎上新增本機覆寫，例如修改連接埠、DNS 或規則。遠端更新後，本機覆寫是否保留取決於客戶端的實作。修改前應區分「編輯下載後的快取檔案」、「編輯遠端設定副本」與「新增持久化覆寫」這三種操作，否則下次更新可能會還原原始內容。

選擇格式的實用結論

如果訂閱提供者可以直接輸出 Mihomo 或 Clash YAML，應優先使用與目前核心相符的原生格式。它能完整表達節點參數，並可攜帶代理群組與規則。只有通用 Base64 時，再透過客戶端相容層或可信的轉換工具產生 YAML。

如果需要自行維護規則，較穩定的結構是將節點放在 provider 檔案中，由本地主設定負責代理群組、規則、DNS 與 TUN。如此一來，節點更新不會直接覆蓋規則邏輯，主設定也不必在每次訂閱重新整理時重新產生。provider 更新週期可設為 86400 秒，健康檢查週期則依節點數量與網路條件設定為 300 至 600 秒。

排查時應始終將問題拆成四個層次：訂閱網址能否存取、回應屬於哪種格式、目標核心能否解析，以及執行後的規則與網路是否正確。格式轉換只處理第二層與部分第三層，不能取代節點有效性、連接埠監聽、DNS 與系統代理檢查。