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

先看訂閱回傳的內容，別只看連結副檔名

訂閱連結是用戶端取得內容的網址，網址本身不等於設定格式。同一個以 https:// 開頭的 URL，可能回傳可直接載入的 Clash YAML，也可能是一整段 Base64 文字；有些網址開啟後甚至會顯示登入頁面或錯誤訊息。用戶端匯入失敗時，先分清楚是「無法連線到網址」，還是「回傳內容不受此匯入入口支援」，比反覆更改訂閱名稱有效。

日常會遇到的內容主要有三種：完整 YAML 設定、編碼後的節點清單，以及 ss:// 等單節點分享連結。它們能提供的資訊範圍不同，不能只因為「裡面都有節點」就把它們當成同一種設定。尤其是代理群組和規則：節點清單列出可連線的代理，完整設定還會決定流量如何選擇這些代理。

完整 YAML：除了節點，還包含選路設定

Clash 設定檔常用 .yaml 或 .yml 副檔名。檔案中的 proxies 用來定義節點，proxy-groups 用來定義手動選擇或自動測試等策略群組，rules 則決定規則模式下的比對結果。mixed-port 這類欄位會設定本機監聽連接埠。YAML 透過縮排表示層級，清單項目前的連字號和欄位所屬層級都會影響解析。

以下是用來說明結構的最小範例。127.0.0.1:1080 僅代表本機已存在的 SOCKS5 上游服務；若沒有相應服務，這段範例就無法建立對外連線。7890 是此範例設定的本機混合連接埠，不代表所有用戶端都固定使用這個連接埠。

mixed-port: 7890
mode: rule

proxies:
  - name: 本機示範
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: 手動選擇
    type: select
    proxies:
      - 本機示範
      - DIRECT

rules:
  - MATCH,手動選擇

在規則模式下，範例中的 MATCH 會將未符合其他規則的連線交給「手動選擇」群組；若群組內選取 DIRECT，這些連線就會直連。匯入實際設定後，請確認用戶端顯示的策略群組和規則數量，而不只是檢查節點清單是否出現。若設定使用 proxy-providers，也要確認提供者網址可正常更新，並確認目前用戶端及其核心支援設定中使用的欄位。

「YAML」只表示檔案語法，不保證內容一定是完整的可執行設定。例如只含 proxies: 的 YAML 節點清單，可能適合供某個代理提供者引用，卻未必能獨立完成流量分流。反過來說，包含 DNS、規則和策略群組的完整設定，即使檔名沒有 .yaml 副檔名，只要用戶端以 YAML 格式讀取且內容有效，仍可能正常載入。

Base64 節點清單：先解碼，再判斷通訊協定

Base64 是文字編碼方式，不是代理通訊協定。常見的 Base64 訂閱會將多條分享連結逐行排列，再把整份文字編碼成一串字元。解碼後應檢查每一行的通訊協定前綴和參數，而不是把編碼後的長字串直接貼進 config.yaml。將編碼文字放在 proxies: 底下，也不會自動產生 YAML 節點物件。

這類清單通常會提供伺服器、連接埠、驗證參數及節點名稱，但不會包含 Clash 的 proxy-groups、rules 或本機 mixed-port 設定。如果用戶端有專用的「節點訂閱」入口，可能會自行解析清單並將節點加入現有設定；如果只有「匯入設定」入口，就需要取得適用的 Clash 設定，或先在本機轉換，再補上策略群組與規則。實際入口名稱請以目前使用的用戶端介面為準。

• 開頭是 proxies:：優先依 YAML 格式檢查縮排、欄位及目標核心的相容性。
• 內容是一整段編碼字元：先確認它確實是 Base64 文字，再查看解碼後逐行排列的內容；不要根據 URL 的檔名猜測。
• 解碼後出現多行 ss:// 等連結：這是節點清單，不是可直接使用的分流設定。
• 回傳 HTML 或登入提示：先處理訂閱存取權限、登入狀態或 URL 過期問題；更改檔案副檔名無法改變回傳內容。

還有一種容易混淆的情況：單一分享連結內部也可能編碼了部分參數，但它仍然只描述一個節點，不能因為出現 Base64 字元就認定它是「Base64 訂閱」。判斷時先看最外層：取得的是一份編碼後的多行清單，還是一條帶有通訊協定前綴的分享連結。

單節點連結：可分享連線資訊，不能取代完整訂閱

ss://、vmess://、trojan:// 等前綴代表不同通訊協定的分享連結。一條連結通常對應一個節點。即使用戶端能從剪貼簿辨識並匯入，也不會只憑這條連結推斷該節點應加入哪個策略群組、哪些網域應直連，以及 DNS 應如何設定。手動新增節點後，還要確認目前設定中的策略群組有引用該節點。

通訊協定前綴有助於判斷類型，但不能單憑前綴保證相容。原版 Clash 與 Clash Meta（mihomo）支援的通訊協定和設定欄位範圍不同；例如遇到 vless:// 連結時，不應假設原版 Clash 可以直接使用。即使使用 mihomo，也要確認實際核心版本、通訊協定參數及用戶端的匯入能力。用戶端「無法辨識分享連結」和「核心不支援轉換後的節點欄位」是兩個不同環節，排查時應分別記錄錯誤訊息。

格式轉換：保留欄位，再補上選路邏輯

轉換並不是把 .txt 改名為 .yaml 這麼簡單。將節點清單轉為 Clash 設定時，轉換程序至少要將每條連結對應成 proxies 物件；之後還要決定策略群組名稱、節點歸屬及 rules 的配置。從完整 YAML 匯出成節點清單則是反向精簡：代理群組、規則、DNS 設定和本機連接埠通常不會隨單節點連結一併保留。

轉換前核對四類資訊

1. 通訊協定欄位：確認伺服器、連接埠、驗證方式，以及通訊協定所需的傳輸和 TLS 參數。少了任何欄位，都可能發生「節點已顯示但無法連線」的情況。
2. 節點名稱：轉換後檢查名稱是否重複。策略群組會透過名稱引用節點，重複名稱或名稱變更可能導致原有選擇不再對應預期節點。
3. 群組與規則：確認轉換結果是否實際包含 proxy-groups 和 rules。若只產生 proxies，就應將它視為節點清單，而非完整設定。
4. 目標核心：依預計使用的 Clash 或 mihomo 選擇輸出格式。轉換工具能產生欄位，不代表目前的核心一定能解析或使用這些欄位。

若需要定期更新，還要分清楚「只轉換一次的檔案」和「會隨訂閱更新的設定」。將某次訂閱內容複製到本機 YAML，只會保存當下的節點快照。上游日後調整節點或憑證，這份本機檔案不會自動同步。若使用用戶端的 URL 設定更新功能，請確認更新後的設定仍保留預期的群組和規則；若使用代理提供者，則要檢查提供者的更新結果，以及引用它的策略群組。

排查轉換結果可分三步：先確認 YAML 能否由用戶端載入，再檢查策略群組是否列出預期節點，最後在規則模式下透過實際連線驗證選路。成功載入只代表設定通過目前用戶端的解析，不代表節點參數、上游服務和規則結果都正確。測試前記下目前選取的群組成員，測試後再比對連線記錄，就能避免把選錯 DIRECT 誤判為訂閱故障。

匯入失敗時，依序檢查內容、解析與連線

第一步：是否成功取得內容

在用戶端的「設定」頁面使用 URL 匯入時，先確認網址是否完整、帳號是否仍有存取權限，以及更新時是否出現網路錯誤。在瀏覽器中能開啟頁面，不代表用戶端請求會取得相同的設定內容：登入頁面、重新導向後的提示頁或過期說明都不是 YAML。診斷時查看回傳內容的開頭，並避免在截圖中露出訂閱 URL 的權杖。

第二步：內容能否依預期格式解析

若出現 YAML 錯誤，請檢查縮排是否混入定位字元、冒號後是否缺少空格，以及清單項目是否位於正確層級。若匯入後只有節點，沒有規則和策略群組，請回頭確認原始內容是否本來就是節點清單。若出現未知通訊協定或欄位，請記下用戶端版本與核心名稱，再比對訂閱的目標格式；不要靠反覆更改檔名來解決核心相容性問題。

第三步：節點和選路是否正常

看到節點後，先確認它已加入目前的策略群組，再檢查規則模式下的比對結果。系統代理通常只會接管使用系統代理設定的應用程式；若需要接管其他流量，部分用戶端提供 TUN 模式，但 TUN 權限、DNS 和路由設定屬於另一層設定，無法透過轉換訂閱格式自動補齊。若節點已連線，但應用程式流量仍未經過預期的策略群組，請分別檢查用戶端模式、系統代理或 TUN 狀態，以及實際命中的規則。

格式選擇原則很簡單：想直接載入分流設定，優先取得符合目前核心的完整 YAML；只需將一批節點加入現有設定，使用用戶端支援的節點清單或代理提供者入口；只需分享單一連線資訊，則使用對應通訊協定的單節點連結。先確認內容類型，再選擇匯入入口，最後核對群組、規則和連線結果，就能分開處理格式與網路問題。