2026-06-08 · 訂閱管理 · 約 12 分鐘

V2Ray 訂閱格式詳解：base64、原生 JSON 與分享連結如何互相轉換

拆解三種常見訂閱格式的結構與適用用戶端，說明 base64 編碼訂閱、原生 JSON 設定與 vmess:// 分享連結的轉換方式與注意事項。

本文速覽

本文適合需要判斷訂閱內容、移轉單一節點或排查匯入失敗的使用者。讀完即可分清編碼容器、分享連結與核心設定三層結構，並依欄位對應完成可控轉換。

先分清編碼、節點與執行設定

「V2Ray 訂閱」不是一種嚴格統一的檔案格式。實際使用時，這個詞可能指向一個回傳多行分享連結的網址，也可能指已解碼的節點清單，還可能是能直接交給 V2Fly 或 Xray 核心讀取的 JSON 設定。三者看似都包含伺服器資訊，但用途與資訊量並不相同。

base64 只是編碼方式，不是協定。它會將文字轉換成便於傳輸的一組字元，不會自動驗證伺服器、補齊傳輸參數或產生路由規則。常見訂閱回應的內層內容，是以換行分隔的 vmess://、vless:// 或 trojan:// 連結，外層再整體進行一次 base64 編碼。

分享連結描述的是一個出站節點，通常包含伺服器位址、連接埠、使用者識別碼、傳輸方式、TLS 參數與備註。原生 JSON 則面向核心執行，除了出站外，還可能包含入站監聽、DNS、日誌、路由規則與策略設定。因此，從 JSON 擷取分享連結通常只能保留其中一個出站；反向轉換也無法憑空還原原本的完整規則。

base64 訂閱

推薦

適合集中發布多個節點，用戶端可依訂閱網址定期更新。解碼後通常會得到每行一個分享連結的文字。

適合：日常訂閱更新、多節點分組

單一分享連結

方便複製單一節點並跨裝置匯入，欄位範圍集中在該節點的出站連線參數。

適合：單一節點移轉、逐項檢查參數

原生 JSON

直接表達核心設定樹，可容納多個入站、出站、DNS 與路由規則，結構最完整。

適合：精細路由、手動維護核心設定

結論：先判斷外層，再解析內層

看到一長串字元時，不要連續解碼多次。先判斷回應是 JSON、明文連結清單還是 base64 文字；每完成一層轉換，就檢查結果是否出現合法的協定標頭。

base64 訂閱內部是什麼

典型訂閱服務會回傳純文字。用戶端取得回應後，移除前後空白，執行一次 base64 解碼，再依 \n 或 \r\n 拆分。空白行應予忽略，每個非空白行再依協定標頭交給對應的解析器。若解碼結果已以左大括號開頭，可能代表 JSON，不應繼續當作連結清單拆分。

標準 base64 使用大小寫字母、數字、加號與斜線，結尾可能帶有等號補位。URL 安全變體會將加號與斜線替換為減號與底線。部分訂閱會省略結尾補位，解析器需要依長度補齊，但不能修改中間字元。UTF-8 位元組順序標記、回應前後的提示文字與 HTML 錯誤頁，也可能導致解碼失敗。

外層訂閱回應
        ↓ base64 解碼一次
vmess://編碼後的節點描述
vless://使用者識別碼@edge.example:443?encryption=none&security=tls&type=ws#範例節點
trojan://驗證資訊@edge.example:443?security=tls&type=tcp#備用節點
        ↓ 依行辨識協定
節點 1、節點 2、節點 3

判斷內容是否真的是訂閱，不能只看字元是否符合 base64 字元集。短英文、數字字串，甚至普通文字，都可能剛好符合字元規則。更穩妥的判斷方式是：解碼後的 UTF-8 文字中存在受支援的協定標頭，或得到符合預期結構的 JSON。也要檢查伺服器回應狀態，例如 HTTP 200 才進入解析流程；301 或 302 應依用戶端策略處理重新導向；401 和 403 通常表示網址憑證或存取條件已變更。

常見回應特徵

VMess、VLESS 分享連結的欄位差異

vmess:// 常見的寫法，是將單一節點 JSON 物件整體編碼後放在協定標頭之後。解碼後的物件常見欄位包括版本、備註、伺服器位址、連接埠、使用者識別碼、傳輸方式、偽裝類型、路徑、TLS 與 SNI。歷史實作中的欄位名稱較短，例如 add 代表位址、port 代表連接埠、id 代表使用者識別碼。

vless:// 更接近標準 URL：使用者識別碼位於使用者名稱位置，主機與連接埠位於 authority 部分，傳輸與安全參數位於查詢字串，備註位於井號之後。解析時必須先進行 URL 百分號解碼，並區分查詢參數與備註。連接埠 443 常用於 TLS 連線，連接埠 80 常見於未啟用 TLS 的 HTTP 或 WebSocket 入口，但連接埠本身無法證明安全層是否開啟。

連線資訊 VMess 常見欄位 VLESS URL 位置 轉換注意事項
伺服器位址 add 主機部分 網域名稱與 IPv6 位址的寫法不同，IPv6 必須保留方括號的語意
連接埠 port 主機後的連接埠 應轉換為 1 至 65535 的整數
使用者識別碼 id 使用者名稱部分 只能複製現有值，不能由備註或伺服器位址推導
傳輸方式 net type 參數 WebSocket、TCP、gRPC 的附加欄位各不相同
路徑或服務名稱 path path 或 serviceName 斜線、空格與特殊字元需要正確編碼
伺服器名稱 sni sni 參數 不要預設視為與連線位址相同
備註 ps 井號後的 fragment 只影響顯示名稱，不參與建立連線

VMess 連結中，不同產生器可能會將布林值寫成字串，將連接埠寫成數字或字串。轉換工具應先規範型別，再輸出目標格式。VLESS 連結則要處理重複查詢參數、參數大小寫與百分號編碼。未知參數最好原樣保留至擴充欄位，而不是靜默丟棄。

結論：協定名稱相同，不代表參數等價

轉換時至少要核對位址、連接埠、使用者識別碼、傳輸方式、安全層、SNI、路徑七項。只複製前三項，常會得到能夠匯入卻無法建立連線的節點。

原生 JSON 為什麼不能直接當作訂閱

核心 JSON 是完整的執行設定。常見的桌面設定會宣告本機入站，例如在回送位址監聽連接埠 10808，再定義一個或多個出站。路由部分會依網域、IP 或入站標籤選擇出站，DNS 部分則決定解析方式。分享連結沒有足夠空間表達這些關係，用戶端通常會使用自己的預設入站與路由範本。

以下結構只展示欄位層級，其中的說明文字不是可直接連線的設定。它說明同一個出站節點在原生 JSON 中需要嵌入 outbounds，而本機代理連接埠位於 inbounds，兩者不可混為一談。

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks"
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "edge.example",
            "port": 443,
            "users": [
              {
                "id": "由服務提供者分配的使用者識別碼",
                "security": "auto"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/gateway"
        }
      }
    }
  ]
}

從原生 JSON 產生 VMess 分享連結時，應先選擇目標出站，再讀取 settings.vnext 中的伺服器與使用者資訊，最後將 streamSettings 對應至傳輸欄位。若一個出站包含多個伺服器或多個使用者，就可能需要展開為多條連結。反向產生 JSON 時，用戶端還必須補充本機入站、日誌與路由預設值。

轉換時通常會遺失的內容

從訂閱轉換為分享連結的步驟

可靠的轉換應採用分層流程，而不是反覆嘗試解碼文字。先保留原始回應，記錄內容類型與字元編碼，再判斷外層。解析成功後建立統一的節點欄位模型，最後由不同輸出器產生 VMess、VLESS 連結或核心 JSON。如此更容易定位錯誤發生在取得、解碼、欄位解析還是輸出階段。

  1. 檢查回應

    確認請求回傳 HTTP 200，內容不是登入頁或錯誤頁。記錄回應是否包含換行、JSON 起始符號或可辨識的協定標頭。

  2. 解開外層

    僅在內容符合編碼訂閱特徵時執行一次 base64 解碼。相容於標準字元表與 URL 安全字元表，並以 UTF-8 讀取結果。

  3. 拆分節點

    依 CRLF 或 LF 分行，移除空白行。每行依據 vmess://、vless:// 或 trojan:// 分派至解析器。

  4. 規範欄位

    將連接埠轉換為整數，統一傳輸名稱，分別保存位址、使用者識別碼、TLS、SNI、路徑與備註，並單獨保留未知欄位。

  5. 匯入並驗證

    在 v2rayN 開啟「設定」→「參數設定」→「Core 類型」，確認所選核心支援目標協定，再匯入新的分組並查看核心日誌。

驗證不能只看「匯入成功」。匯入成功只代表用戶端接受了語法。還應檢查節點詳細資訊中的伺服器、連接埠與傳輸參數，啟動後查看日誌是否出現 DNS 失敗、TLS 名稱不相符、路徑錯誤或連接埠佔用。若本機連接埠使用 10808，還要確認沒有其他程序佔用相同的監聽連接埠。

適合自動化的檢查項目

  1. 訂閱回應大小是否合理；空回應應直接停止解析。
  2. 解碼結果是否為有效的 UTF-8，異常位元組是否來自錯誤的字元集。
  3. 每個節點的連接埠是否位於 1 至 65535。
  4. 啟用 TLS 時是否保留 SNI 或對應的伺服器名稱。
  5. WebSocket 路徑是否以斜線開頭，查詢參數是否被重複編碼。
  6. 節點備註是否經過 URL 解碼，同時避免備註覆蓋連線欄位。

在 v2rayN、v2rayNG 與 v2flyNG 中匯入

v2rayN 適合在桌面環境管理訂閱分組。新增訂閱網址後執行更新，用戶端便會取得並解析節點清單。若只取得單一分享連結，可以使用從剪貼簿匯入的入口。不同版本的選單文字可能略有調整，但操作順序仍是先建立訂閱分組，再更新該分組，最後選擇節點並啟用系統代理。

v2rayNG 使用 Xray 核心，v2flyNG 使用 V2Fly 核心。兩者都能處理常見的 VMess 訂閱與分享連結，但特定協定擴充是否可用，取決於核心支援情況。遇到連結能夠解析、啟動時卻提示未知傳輸或未知安全類型，應檢查連結所需的核心能力，而不是繼續修改 base64 內容。

貼上訂閱網址後沒有節點？

先在瀏覽器以外檢查用戶端日誌中的 HTTP 狀態。若回傳 200，再確認解碼結果是否包含逐行排列的協定標頭；若回傳的是 JSON 物件，則需要使用相應的匯入方式。

為什麼解碼一次後仍然是亂碼？

檢查文字是否採用 URL 安全 base64，並補齊結尾等號。仍然失敗時，查看回應是否混入提示文字、UTF-8 位元組順序標記或 HTML 錯誤內容。

節點匯入成功卻連線失敗？

逐項核對連接埠、傳輸方式、TLS、SNI 與路徑，再查看核心日誌。WebSocket 路徑少一個斜線或遺漏 SNI，都可能讓握手在幾秒內失敗。

更新訂閱會覆蓋手動備註嗎？

多數用戶端會依訂閱回傳內容重建該分組，手動修改的名稱可能會被替換。需要長期保留的節點，應複製到獨立分組，並記錄原訂閱歸屬。

原生 JSON 可以直接匯入訂閱欄位嗎？

通常不行。訂閱欄位期待網路網址或節點清單，核心 JSON 應使用用戶端提供的自訂設定入口，並另外檢查入站連接埠、路由與 DNS 設定。

在 v2rayN 中排查核心選擇時，可進入「設定」→「參數設定」→「Core 類型」查看目前設定。訂閱更新後若清單沒有變化，先確認更新的是正確分組，再查看日誌時間戳記。行動裝置匯入前，應檢查剪貼簿內容是否完整；長連結被聊天工具截斷時，結尾備註看似存在，中間的查詢參數卻可能已經遺失。

匯入後的四項驗證

轉換界線與維護建議

訂閱轉換的目標應是保持連線參數一致，而不是製造表面相似的連結。遇到工具不認識的欄位時，保留原始資料並明確提示，比刪除欄位後繼續輸出更可靠。尤其是傳輸層擴充與安全參數，遺失後仍可能產生語法正確的連結，但連線結果已經不同。

訂閱網址本身通常扮演更新入口的角色。將某次取得的節點匯出為靜態分享連結後，它不會自動取得後續的伺服器、連接埠或使用者資訊變更。長期使用時應保留原訂閱分組，靜態連結更適合作為暫時移轉或參數分析資料。

原生 JSON 適合保存經過驗證的路由與入站設定。修改前記錄目前的本機監聽連接埠、系統代理狀態、核心類型與設定檔來源。發生問題時先還原這些基礎項目，再檢查節點欄位，可以避免將系統代理問題誤判為訂閱格式問題。

目標 建議輸入 建議輸出 必須複核
定期更新多個節點 訂閱網址 用戶端訂閱分組 更新狀態、分組歸屬、協定支援
移轉單一節點 單一分享連結 建立新節點 TLS、SNI、路徑、備註
維護精細路由 原生 JSON 獨立核心設定 入站連接埠、DNS、路由標籤
分析訂閱內容 原始回應 解碼後的唯讀副本 只解碼一層，避免公開連線資訊

最穩妥的工作方式，是保留三份資料：未修改的訂閱回應、規範化後的節點欄位，以及最終匯入檔案。三者分開後，任何連線異常都能追溯至具體的轉換階段。對一般使用者而言，優先讓用戶端直接管理訂閱；只有在移轉、除錯或建立自訂路由時，才需要手動處理編碼與 JSON 對應。

下載 V2Ray 用戶端 Windows、macOS、Android、Linux