Clash 訂閱連結匯入教學:URL 格式辨識與轉換方法

訂閱連結不只一種

許多人拿到一條訂閱連結就直接貼到用戶端裡,結果不是匯入失敗就是節點列表空白。問題往往不在用戶端本身,而是連結的格式與用戶端預期的格式不符。訂閱連結大致分三類,先分清類型再動手,能省下大半排查時間。

第一類是 Clash 原生設定檔直連結:請求這個 URL 會直接回傳一份 YAML 文字,裡面帶有 proxies、proxy-groups、rules 等欄位,本質上就是一份完整的 Clash 設定檔,只是放在伺服器上按需生成。這類連結對 Clash、Clash Meta(mihomo 核心)系用戶端最省事,匯入即用,不需要任何轉換。

第二類是 通用分享協定聚合連結:回傳內容是若干條 vmess://、ss://、trojan://、ssr:// 節點連結拼在一起,再整體做一次 Base64 編碼。這種格式最早是為 V2rayN、Shadowrocket 一類用戶端設計的通用交換格式,Clash 核心本身並不認得它,必須先轉換成 YAML 才能用。

第三類是 訂閱轉換服務生成的中轉連結:使用者先把原始訂閱丟進一個線上轉換後端,後端再對外吐出一條新的 URL,存取這條新 URL 才會回傳 Clash 能讀的 YAML。使用體驗上和第一類一樣是「直接匯入」,差別只是多繞了一層轉換伺服器,更新時機也取決於那台轉換伺服器是否還正常運作。

如何快速辨識連結類型

不確定拿到的是哪一種,最簡單的方法是把連結貼到瀏覽器網址列直接存取,看回傳的原始文字長什麼樣子,再依下面幾點判斷:

• 回傳內容以 proxies:、proxy-groups:、rules: 開頭或包含這些關鍵欄位,並且是可讀的鍵值結構——這是 Clash 原生 YAML,直接用。
• 回傳內容是一整段看起來雜亂的字母數字,長度是 4 的倍數,結尾可能有一到兩個 = 號——大概率是 Base64 編碼的節點列表,需要轉換。
• 回傳內容能直接用肉眼看到大量 vmess://、ss://、trojan:// 前綴——這是未編碼的通用分享連結聚合,同樣需要轉換。
• 回應標頭 Content-Type 是 text/yaml 或 application/x-yaml,基本可以確認是 Clash 直連結;如果是 text/plain 就要看內容才能判斷。

不方便用瀏覽器存取的話,也可以直接把連結貼進用戶端試一次,大多數用戶端在匯入失敗時會給出提示,例如「無法解析設定」「格式不支援」這類訊息,可以作為二次確認的線索。

各用戶端的匯入入口

不同平台的用戶端介面差異不小,但匯入訂閱的操作邏輯基本一致,都是「貼上 URL → 命名 → 儲存並下載」三步。

Windows / macOS 桌面用戶端

在設定管理或訂閱管理頁面找到新增入口,貼上訂閱 URL,填寫一個便於識別的名稱,確認後用戶端會立即發起一次請求拉取內容。如果用戶端支援自訂更新間隔,建議順手設定成 12~24 小時一次,避免手動更新遺漏導致節點資訊過期。

Android 用戶端

Android 端一般在主介面的設定或訂閱列表裡有一個新增按鈕,支援貼上 URL 或掃描訂閱 QR Code 兩種方式匯入。掃碼適合從電腦分享到手機的情境,能避免手動輸入長連結出錯。

iOS 用戶端

iOS 端多數走系統分享選單或應用程式內貼上兩種路徑,部分用戶端還支援透過 Safari 擴充功能直接識別頁面裡的訂閱連結一鍵匯入,省去手動複製貼上的步驟。

通用分享格式如何轉換成 Clash 設定

如果確認拿到的是 vmess://、ss:// 一類的聚合連結,常見處理思路有兩種。

第一種是使用訂閱轉換服務:把原始訂閱連結作為參數傳給轉換後端,後端會解析每條節點資訊並重新生成一份 Clash 能識別的 YAML,再把生成結果的存取位址作為新的訂閱 URL 交給用戶端使用。這種方式幾乎不需要手動操作,但依賴轉換伺服器長期在線,一旦服務停止或限流,訂閱會連帶失效。

第二種是本地手動轉換:把 Base64 內容解碼還原成明文節點列表,再依 Clash 的 proxies 欄位結構逐條改寫。以 Shadowsocks 節點為例,一條最簡單的 Clash 代理條目大致如下:

proxies:
  - name: "範例節點-01"
    type: ss
    server: example.example.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"
    udp: true

手動轉換的好處是不依賴第三方伺服器,壞處是節點數量一多就很容易出錯或漏改欄位,一般只建議用在節點數量少、追求長期穩定的情境。日常使用還是優先選擇原生 Clash 直連結或穩定的轉換服務。

這裡要特別提一句 Clash Meta(mihomo 核心):相比早期 Clash 核心,它對協定的支援範圍更廣,原生識別 Hysteria、TUIC、VLESS 等新協定節點,很多情況下不再需要額外轉換就能直接匯入,如果發現某些節點在舊核心用戶端裡始終無法識別,可以優先確認用戶端使用的是否為 Meta 核心。

匯入後節點列表為空的排查順序

連結類型確認無誤、也確實做了轉換,但匯入完節點列表還是空的,可以依下面順序逐條排查,基本能定位問題所在。

1. 確認連結本身是否有效。 直接用瀏覽器存取一次,看是否能正常回傳內容,而不是 404 或空白頁面,機場端過期或流量耗盡都會導致訂閱介面直接失效。
2. 檢查是否觸發了 User-Agent 限制。 部分訂閱伺服器會依請求標頭判斷用戶端類型,拒絕瀏覽器或非白名單用戶端的請求,這種情況下瀏覽器打不開連結不代表訂閱本身失效,應以用戶端內的更新結果為準。
3. 核對設定格式版本。 如果訂閱內容裡用到了用戶端尚未支援的新欄位或新代理類型,解析時會被整段跳過,更新一下用戶端版本往往能解決。
4. 排查系統代理循環。 如果裝置目前已經開啟了全域代理或 TUN 模式,拉取訂閱這個請求本身也會經過代理轉發,一旦代理節點當時不可用,訂閱更新請求也會跟著失敗,可以先關閉代理再手動更新一次訂閱確認。
5. 查看更新時間戳記。 用戶端一般會顯示訂閱最後更新時間,如果時間沒有變化,說明更新請求實際沒有成功發出,需要回到前四步逐一確認,而不是反覆點擊更新按鈕。

讓訂閱長期保持可用的幾個習慣

訂閱連結匯入成功只是第一步,長期用下來還需要留意幾個細節:一是替每條訂閱設定合理的自動更新週期,避免節點資訊滯後;二是備份一份訂閱連結原文到本地筆記,防止誤刪設定後找不回來;三是如果同時使用多台裝置,盡量讓各裝置的更新時間錯開一點,減少同一時刻並發請求對訂閱伺服器造成壓力;四是節點全部失效時,先檢查訂閱是否過期,再考慮是否需要更換服務商,不要先懷疑用戶端本身出了問題。

把這幾點養成習慣之後,訂閱相關的問題基本都能在幾分鐘內自查清楚,不需要每次都重新摸索。