本文適合正在排查訂閱匯入失敗、需要遷移節點或想了解設定結構的使用者。判斷順序是先識別回應內容，再區分節點分享資訊與完整執行設定，最後依欄位能力進行轉換；讀完即可判斷一段文字屬於 base64 聚合訂閱、原生 JSON，還是 VMess、VLESS、Trojan、Shadowsocks 分享連結。
先判斷取得的是哪種格式
「訂閱」不是單一檔案規範，而是一種發布方式。用戶端存取訂閱網址後，伺服器可能回傳經過 base64 編碼的多行分享連結，也可能直接回傳逐行文字、JSON 節點清單，甚至是針對特定用戶端定義的設定物件。網址以 https:// 開頭只能說明傳輸方式，無法表示回應本文的結構。
單一分享連結描述一個出站節點，常見前綴包括 vmess://、vless://、trojan:// 和 ss://。通常包含伺服器位址、連接埠、驗證資訊、傳輸方式與 TLS 參數。聚合訂閱則將多個分享連結放在同一份回應中，用戶端更新時會重新下載並覆寫對應的訂閱群組。
原生 JSON 設定的範圍更廣。它可以同時包含 inbounds、outbounds、routing、dns 和 log，因此不只描述遠端節點，也能指定本機監聽連接埠、路由規則與 DNS 行為。將完整 JSON 當作一般訂閱匯入，用戶端不一定會接受。
| 觀察到的內容 | 較可能的格式 | 適合的匯入入口 |
|---|---|---|
| 長串字母、數字，結尾可能有一或兩個等號 | base64 聚合訂閱 | 訂閱群組或訂閱設定 |
| 以大括號開頭，包含 inbounds、outbounds | 原生 JSON 設定 | 自訂設定或核心設定入口 |
| 以 vmess://、vless:// 等前綴開頭 | 單一分享連結 | 從剪貼簿匯入或掃描 QR Code |
| 多行內容，每行都是協定前綴 | 未整體編碼的聚合清單 | 取決於用戶端的訂閱解析能力 |
結論：先看本文，不要根據網址副檔名猜格式
訂閱網址即使以 .json 結尾，也可能回傳 base64 文字；沒有檔案副檔名的介面也可能回傳 JSON。排查時應查看實際回應的前幾十個字元、HTTP 狀態與回應類型，再決定使用哪個匯入入口。
如何拆解 base64 聚合訂閱
最常見的傳統訂閱結構，是先用換行字元連接多個分享連結，再將整段文字進行一次 base64 編碼。base64 只是字元編碼，不負責加密，也不會驗證欄位是否正確。成功解碼只代表字元層面可以還原，不表示其中每個節點都能被目前的核心識別。
標準 base64 字元表包含大小寫英文字母、數字、加號與斜線，結尾可能使用等號補齊。部分服務採用 URL-safe 變體，將加號替換為減號、斜線替換為底線，並省略結尾補位。若用戶端只接受標準字元表，就可能出現「訂閱內容為空」或「格式無效」。
編碼前的聚合內容示意：
vmess://eyJ2IjoiMiIsInBzIjoiV00tMDEiLCJhZGQiOiJleGFtcGxlLmNvbSJ9
vless://[email protected]:443?encryption=none&security=tls&type=ws&path=%2Fedge#VL-01
trojan://[email protected]:443?security=tls&sni=example.com#TR-01
處理順序：
HTTP 回應本文 → 移除前後空白 → 整體 base64 解碼 → 依換行拆分 → 逐一解析協定連結- 檢查空白字元：本文前方的 UTF-8 BOM、複製時混入的空格與多餘空行，都可能影響嚴格解析器。
- 檢查補位：base64 長度通常需要能以 4 個字元分組；缺少補位時，解析器可以依餘數補上，但不能任意刪除中間字元。
- 檢查換行：伺服器可能使用 LF 或 CRLF。穩妥的拆分方式應同時處理兩種換行，並篩除空行。
- 檢查重複編碼：若第一次解碼後仍是一整段明顯的 base64 字元，不要立即認定必須再次解碼，應先確認伺服器是否套用了額外封裝。
VMess 分享連結本身也經常採用「前綴加 base64 JSON」的結構，因此聚合訂閱可能形成兩層編碼：外層用來包裝節點清單，內層則屬於 VMess 分享格式。外層解碼後應停在逐行連結階段，再將每條 vmess:// 後面的內容個別解碼。VLESS 與 Trojan 通常採用 URI 查詢參數，不需要再將整條連結進行 base64 解碼。
為什麼原生 JSON 不能等同於節點清單
原生 V2Ray 或 Xray JSON 是核心執行設定。它描述資料從哪個本機入口進入、符合哪些路由規則、交給哪個出站連線，以及網域如何解析。一個出站節點只是 outbounds 陣列中的一項；完整設定還可能包含 direct、block 等多個出站標籤。
以下縮減範例展示結構層級。監聽於 127.0.0.1:10808 的 SOCKS 入站接收本機流量，名為 proxy 的 VLESS 出站連線至遠端 443 連接埠。實際使用時，傳輸層、TLS 或 REALITY 參數還會放在 streamSettings 中。
{
"inbounds": [
{
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"udp": true
}
}
],
"outbounds": [
{
"tag": "proxy",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "example.com",
"port": 443,
"users": [
{
"id": "11111111-1111-4111-8111-111111111111",
"encryption": "none"
}
]
}
]
}
}
]
}分享連結或訂閱
推薦由用戶端產生本機入站、記錄檔與基本路由，節點只提供遠端連線欄位，遷移成本較低。
適合：在 v2rayN、v2rayNG、v2flyNG 中管理日常節點
原生 JSON
可以完整控制入站、出站、DNS、路由與策略，但不同核心支援的欄位集合可能不同。
適合：需要自訂路由鏈路或精確控制核心行為
用戶端備份
除了節點外，還可能儲存訂閱群組、介面選項與本機資料庫資訊，通常只適合在相同用戶端中還原。
適合：在相同用戶端版本之間遷移設定
從 JSON 擷取分享連結時，不能只複製 address、port 和 id。還要讀取 streamSettings.network、security、WebSocket 路徑、HTTP Host、gRPC serviceName、TLS serverName，以及 REALITY 的 publicKey、shortId 和 fingerprint。遺漏其中任何關鍵欄位，都可能得到語法正確但握手失敗的連結。
反向轉換也會遺失資訊。單一分享連結通常無法完整承載複雜的 routing.rules、DNS hosts 對應、多個入站連接埠、負載平衡器或鏈式代理。匯入分享連結後，用戶端會依自身範本重新產生這些本機部分，而不是還原原始 JSON 的全部行為。
結論：轉換時以遠端出站為界線
需要在不同用戶端之間遷移節點時，只轉換伺服器出站所需欄位；需要保留 DNS、路由分流與多個入站時，應遷移原生 JSON，並確認目標核心支援其中每個設定段。
VMess、VLESS 與其他分享連結的欄位差異
VMess 常見分享格式會將 JSON 物件編碼後接在 vmess:// 後方。常見欄位包括版本 v、備註 ps、位址 add、連接埠 port、使用者識別碼 id、額外 ID aid、加密方式 scy、傳輸網路 net、偽裝類型 type、Host、路徑、TLS、SNI、ALPN 與指紋。此格式由用戶端生態長期擴充，部分新增欄位在舊版用戶端中可能會被忽略。
VLESS 更接近標準 URI：使用者資訊位置放 UUID，主機與連接埠放伺服器位址，查詢參數描述傳輸與安全層，井號後的片段則是節點備註。VLESS 的 encryption 通常為 none；這不是 TLS 開關，TLS、REALITY 等安全方式由 security 參數表示。
| 分享欄位 | 意義 | 常見錯誤 |
|---|---|---|
| address / add | 遠端伺服器網域或 IP | 複製時混入協定前綴或路徑 |
| port | 遠端監聽連接埠，例如 443 | 誤填成本機 10808 連接埠 |
| id | VMess 或 VLESS 使用者 UUID | 缺少字元、含空格或使用錯誤使用者 |
| type | 傳輸類型，例如 tcp、ws、grpc | 與伺服器傳輸設定不一致 |
| security | 傳輸安全方式，例如 tls、reality、none | 與協定本身的加密欄位混淆 |
| sni / serverName | TLS 握手使用的伺服器名稱 | 填入 IP 或遺漏伺服器要求的網域 |
| path | WebSocket HTTP 路徑 | 斜線或百分比解碼層級錯誤 |
| flow | VLESS 流控方式，例如 xtls-rprx-vision | 將一般 TLS 節點誤設為 Vision |
| pbk / sid | REALITY 公鑰與 shortId | 將伺服器私有參數寫入用戶端欄位 |
VLESS 連結結構示意：
vless://UUID@伺服器:連接埠
?encryption=none
&security=reality
&type=tcp
&sni=握手網域
&fp=chrome
&pbk=REALITY公鑰
&sid=shortId
&flow=xtls-rprx-vision
#節點備註Trojan 連結會將密碼放在使用者資訊位置，後方同樣可以攜帶 security、sni、type、path 等查詢參數。Shadowsocks 分享連結則主要表達加密方法、密碼、位址與連接埠，擴充傳輸參數的相容程度取決於具體格式。若轉換工具只識別基本欄位，可能保留節點驗證資訊，卻遺失外掛程式或傳輸設定。
URI 中的節點備註、路徑與 Host 可能經過百分比編碼。例如空格可表示為 %20，斜線在查詢參數中可能表示為 %2F。正確的處理方式是依 URI 規則解析各個組成部分，而不是對整條連結反覆執行字串替換。過早解碼井號、問號或連接符號，可能改變欄位邊界。
三種格式互相轉換的穩妥流程
轉換的首要目標是保留連線所需欄位，而不是追求文字外觀一致。先確認來源格式，再建立統一的節點資料模型，至少記錄協定、位址、連接埠、驗證資訊、傳輸、安全層與備註。最後由目標用戶端或產生器依目標格式輸出。
識別來源內容
查看回應開頭、協定前綴與 JSON 頂層鍵。若是訂閱網址，先確認 HTTP 狀態為 200，並判斷回應是否需要整體 base64 解碼。
拆分節點
將聚合訂閱依 LF 或 CRLF 分行並篩除空行；每條連結依協定前綴選擇對應解析器，不要將 VLESS 參數套用到 VMess。
統一欄位
統一儲存伺服器、連接埠、使用者識別碼、傳輸類型、TLS 或 REALITY 參數，並分別保留 WebSocket path、gRPC serviceName 與 SNI。
核對核心
在 v2rayN 中檢查「設定」→「參數設定」→「Core 類型」，確認所選核心支援節點使用的協定、REALITY 或 XTLS Vision 欄位。
匯入並測試
先只匯入一個節點，查看核心記錄是否出現 unknown field、failed to find an available destination 或 TLS handshake 等訊息，再進行批次轉換。
在 v2rayN 中，訂閱通常放入訂閱群組，再執行更新所有訂閱；單一分享連結則更適合透過剪貼簿匯入。若需要載入完整 JSON，應使用用戶端提供的自訂設定功能，而不是將 JSON 檔案網址直接放入一般訂閱網址欄位。匯入後還需選擇作用中的伺服器，並啟用系統代理或所需的 TUN 模式。
在 v2rayNG 與 v2flyNG 中，訂閱設定負責儲存遠端位址與更新結果，剪貼簿匯入則負責處理單一分享連結。v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心；兩者對常見 VMess、VLESS、Trojan、Shadowsocks 的支援範圍，以及對較新傳輸欄位的接受程度並不完全相同。遷移後應進入節點詳細資料逐項核對，而不是只看節點名稱是否出現。
結論：先轉換一個節點，再處理整份訂閱
用單一節點完成匯入、啟動核心與實際連線三項驗證，可以快速找出欄位對應問題。若直接轉換數十個節點，節點重名、部分協定不相容與記錄交錯都會增加排查成本。
訂閱匯入後為空的排查順序
匯入後清單為空，不代表訂閱中沒有節點。問題可能發生在網路請求、回應解碼、逐行識別、協定相容性或群組顯示的任一階段。有效的排查應從最前面的環節開始，避免反覆刪除用戶端設定。
先確認訂閱請求確實回傳本文，而不是登入頁面、流量限制提示或 HTML 錯誤頁。一個頁面即使回傳 200，也可能因存取權杖失效而輸出提示文字。回應若以 <html、<!doctype 開頭，base64 解碼與協定解析自然不會產生節點。
訂閱更新提示逾時怎麼辦？
先確認裝置可以存取訂閱網域。若直接連線路徑不可用，可先連線至一個現有的可用節點，再到訂閱設定中啟用透過代理更新；同時檢查系統時間與訂閱網址是否完整複製。
更新成功但節點清單為空？
查看更新記錄中的新增數量，並檢查回應解碼後是否出現 vmess://、vless:// 等前綴。若只看到 JSON，確認它是節點陣列，還是包含 inbounds、outbounds 的完整核心設定。
只有部分節點被匯入？
依未匯入節點的協定與傳輸類型分類，重點檢查 URL-safe base64、REALITY 參數、gRPC serviceName 以及備註中的特殊字元。舊版用戶端可能會略過無法識別的欄位或整筆記錄。
節點存在但啟動核心失敗？
在 v2rayN 開啟「設定」→「參數設定」→「Core 類型」核對核心，再查看核心記錄中的第一個錯誤。若連接埠被占用，檢查本機 10808 等監聽連接埠；若是欄位錯誤，回到節點編輯頁核對傳輸與安全層。
更新後手動修改被覆寫？
訂閱節點通常由遠端內容管理，再次更新可能覆寫本機欄位。需要長期保留修改時，請將節點複製到獨立群組，或直接修正來源訂閱中的對應參數，不要只修改訂閱群組中的暫存副本。
- 請求層：檢查狀態碼、重新導向、回應長度與存取權杖是否有效。
- 編碼層：確認標準 base64、URL-safe base64、補位與 UTF-8 文字都已正確處理。
- 結構層：確認解碼結果是逐行分享連結、節點陣列，還是完整核心設定。
- 協定層：核對 VMess、VLESS、Trojan、Shadowsocks 前綴及必要欄位。
- 核心層：確認 Xray 或 v2fly 核心支援所使用的安全方式、傳輸方式與 flow。
- 執行層：檢查本機連接埠占用、系統代理、TUN 模式、路由分流與核心記錄。
如果訂閱可以解碼、分享連結也能單獨匯入，但批次更新仍然為空，常見原因是回應格式與用戶端訂閱解析器的預期不同。例如伺服器直接回傳 JSON 陣列，而用戶端只依 base64 多行連結處理。此時應調整訂閱輸出格式，或選擇明確支援該 JSON 結構的匯入方式。
如果節點可以匯入但連線失敗，應停止繼續研究 base64。此時編碼階段已經完成，問題更可能出在位址、連接埠、UUID、密碼、SNI、WebSocket path、gRPC serviceName、REALITY publicKey、shortId 或 flow。依核心記錄中的第一個握手錯誤逐項核對，比重複更新訂閱更有效。
格式選擇與長期維護建議
日常在 v2rayN、v2rayNG 或 v2flyNG 中維護多個節點時，訂閱搭配分享連結更方便更新。用戶端負責產生本機入站、系統代理與基本路由，訂閱來源只維護遠端節點。需要調整某個節點時，應優先修正訂閱來源，避免下次更新覆寫本機修改。
需要複雜 DNS、依網域或 IP 路由、多個入站連接埠或鏈式出站時，原生 JSON 更合適。這類設定應記錄目標核心及支援版本，並在切換 Core 類型後重新檢查欄位。Xray 與 v2fly 的設定結構有許多相同部分，但 REALITY、XTLS Vision 與部分擴充能力不能只憑欄位名稱推斷相容性。
| 使用目的 | 建議格式 | 維護重點 |
|---|---|---|
| 定期更新多個節點 | 聚合訂閱 | 群組、更新時間、回應格式 |
| 臨時傳送一個節點 | 分享連結 | 協定欄位、URI 編碼、備註 |
| 精確控制路由與 DNS | 原生 JSON | 核心相容性、設定層級、出站標籤 |
| 跨用戶端遷移 | 標準分享欄位 | 先驗證單一節點，再批次產生 |
儲存設定時也應區分「節點資料」與「用戶端狀態」。節點資料包括位址、連接埠、驗證資訊與傳輸參數；用戶端狀態包括目前選取的節點、訂閱群組、系統代理模式、TUN 設定與路由規則。只匯出分享連結不會帶走後者，這是格式的界線，並非匯出失敗。
最後可以用一條簡單規則選擇：需要自動更新一組節點，就使用訂閱；需要傳遞一個節點，就使用分享連結；需要重現完整核心執行行為，就使用原生 JSON。發生轉換時，先列出目標格式無法表達的欄位，再決定接受遺失、改由用戶端重建，或保留原始設定。