訂閱連結本質上是什麼
機場發給使用者的「訂閱連結」不是節點本身,而是一個可以反覆存取的 HTTP(S) 位址。客戶端定時請求這個位址,拿到一段文字,再把文字解析成節點清單和(可能存在的)分流規則。同一個訂閱位址背後傳回的內容格式並不統一,主要取決於機場用的面板軟體、客戶端類型的判斷邏輯,以及有沒有經過轉換服務處理。這也是為什麼同一條訂閱連結,貼進 Clash 能用,貼進另一個純節點客戶端卻報錯——不是連結壞了,是客戶端沒能識別傳回內容的格式。
理解格式差異,遇到訂閱匯入失敗時能快速判斷問題出在哪一層:是連結本身失效、機場沒適配這個客戶端,還是需要經過轉換服務再中轉一次。
三種常見格式與識別方法
Base64 節點清單
最早也最通用的一種。存取訂閱連結傳回的是一段 Base64 編碼字串,解碼後是若干行 vmess://、ss://、ssr://、trojan:// 之類的單節點連結,一行一個節點。這種格式不包含代理群組和分流規則,客戶端拿到節點清單後按自己的預設策略生成分組。絕大多數純代理客戶端(不侵限於 Clash 生態)都能識別這種格式,相容性最好,但功能也最基礎。
Clash YAML 訂閱
傳回內容是一份完整的 YAML 設定,包含 proxies、proxy-groups、rules 等區塊,和手寫的 config.yaml 結構一致。機場後台按 Clash 規範生成這份設定,客戶端下載後直接使用,分流策略、代理群組分組都是機場預先設計好的,使用者拿到手就能用。判斷方法很直接:用瀏覽器或命令列工具存取連結,如果開頭是 port:、mode: 或 proxies: 這類 YAML 關鍵字,就是這一類。
sing-box JSON 設定
隨著 sing-box 核心的普及,一些機場開始額外提供 JSON 格式的訂閱,結構對應 sing-box 的 outbounds、route 欄位。這類訂閱只能被 sing-box 核心或相容 sing-box 設定結構的客戶端識別,不能直接丟給 Clash 核心的客戶端使用。傳回內容以 { 開頭、能看到 "outbounds" 欄位是明顯特徵。
同一個機場往往會為不同客戶端類型傳回不同格式:請求標頭裡帶 Clash 標識就傳回 YAML,不帶就傳回 Base64 節點清單。這也是為什麼用瀏覽器直接開啟訂閱連結看到的內容,和客戶端實際拿到的內容可能不一致。
訂閱轉換服務的運作原理
訂閱轉換服務(常見的開源實作叫 subconverter)本質是一個中間代理:它先以合適的請求標頭存取原始訂閱連結,拿到節點資料後按目標格式重新生成一份設定,再傳回給客戶端。整個鏈路是「客戶端 → 轉換服務 → 原始訂閱位址 → 轉換服務 → 客戶端」,轉換服務在中間做了兩件事:格式轉換和規則套用。
格式轉換負責把 Base64 節點清單、sing-box JSON 等格式統一「翻譯」成客戶端能識別的 Clash YAML;規則套用則是轉換服務允許你額外指定一份分流規則範本(ACL4SSR 之類的規則集),把裸節點套上現成的分流策略,生成的訂閱連結直接包含代理群組和規則,不用手寫。使用時把原始訂閱位址作為參數拼進轉換服務的介面位址,再把介面傳回的新連結填入客戶端,操作上和填一條普通訂閱沒有區別。
https://某轉換服務域名/sub?target=clash&url=原始訂閱連結&config=規則範本位址需要注意,轉換服務本身也要能存取到原始訂閱位址,如果原始訂閱在特定網路環境下才能存取,轉換環節可能因為網路原因失敗,這類報錯和訂閱連結是否過期無關。
自建轉換服務的基本思路
公共轉換服務存在穩定性和隱私兩方面的顧慮:介面可能限流或下線,原始訂閱位址(通常包含帳號相關的 token)也會經過第三方伺服器。對穩定性和隱私有要求的使用者,可以自建轉換服務,基本思路如下:
準備執行環境
找一台能長期在線的伺服器或本機一直開機的裝置,裝好對應的執行環境(subconverter 提供預編譯二進位檔,不需要額外安裝語言執行環境)。
下載轉換程式與規則範本
取得 subconverter 程式本體,以及打算長期使用的分流規則範本檔案,放在同一目錄下,按專案自帶的設定說明設定監聽埠。
啟動服務並驗證
啟動程式後,用本機瀏覽器存取
http://127.0.0.1:埠號/sub?target=clash&url=測試訂閱位址,確認能正常傳回 YAML 內容。替換為自己的轉換位址
把公共轉換服務的域名換成自己伺服器的位址(建議搭配反向代理加上 HTTPS),後續所有訂閱都透過自建服務轉換,原始訂閱位址不再經過第三方。
自建轉換服務的維護成本主要在規則範本的更新上:分流規則會隨著服務變化持續調整,長期不更新範本會導致分流準確率下降,建議定期同步上游規則倉庫。
各格式在不同客戶端裡的相容性對照
下表按常見客戶端歸納對三種訂閱格式的直接支援情況,不經過轉換服務的前提下:
| 客戶端 / 核心 | Base64 節點清單 | Clash YAML | sing-box JSON |
|---|---|---|---|
| Clash(原版核心) | 需轉換後使用 | 原生支援 | 不支援 |
| Clash Meta / mihomo 核心 | 需轉換後使用 | 原生支援,含擴充欄位 | 不支援 |
| 純代理客戶端(僅認單節點連結) | 原生支援 | 不支援 | 不支援 |
| sing-box 核心客戶端 | 需轉換後使用 | 不支援 | 原生支援 |
可以看到,Clash YAML 只在 Clash 核心家族裡通用,拿去餵給 sing-box 核心的客戶端會直接解析失敗;反過來 sing-box 的 JSON 訂閱也不能直接匯入 Clash 客戶端。跨核心使用節點時,訂閱轉換是繞不開的一步,而不是可選步驟。
更換客戶端核心類型(比如從 Clash 換到基於 sing-box 的客戶端)時,先確認機場是否同時提供兩種格式的訂閱入口,不要假設同一條連結能跨核心通用。