V2Ray 訂閱格式解析：Base64、原生 JSON 與分享連結轉換

先區分編碼、容器與協定

處理 V2Ray 訂閱時，最容易混淆的是「編碼格式」、「設定容器」和「代理協定」這三個層級。Base64 是一種文字編碼方式，負責將原始位元組轉換為便於傳輸的字元；JSON 是結構化資料格式，可以保存完整的核心設定，也可以只保存某個節點的欄位；VMess、VLESS 則是代理協定，決定用戶端與伺服器如何交換必要資訊。三者不在同一個層級，不能簡單視為彼此替代。

常見的訂閱回應看起來是一長串沒有明顯分隔的字元，解碼後往往會得到多行分享連結。此時 Base64 只是外層包裝，真正可匯入的內容位於解碼結果中。另一類訂閱網址會直接回傳 JSON，其中可能包含節點陣列，也可能是一份包含入站、出站、路由與 DNS 設定的核心設定。還有些網址會直接回傳逐行排列的 vmess:// 或 vless:// 連結，不再增加外層編碼。

因此，辨識格式時應由外而內判斷：先查看 HTTP 回應是一般文字還是 JSON，再判斷一般文字是否需要以 Base64 解碼，最後確認解碼內容屬於分享連結清單、單一節點物件，還是完整設定。僅憑檔案副檔名、字串長度或訂閱網址結尾，無法可靠判定內容類型。

如何辨識與解碼 Base64 訂閱

傳統 Base64 訂閱通常會先將多個分享連結逐行串接，再對整段文字進行編碼。用戶端更新訂閱時，會取得回應本文、嘗試解碼、依換行符號拆分項目，然後分別解析每個 URI。換行可能採用 LF 或 CRLF，規範的解析流程需要兼容兩者，並忽略首尾空白與空行。

標準 Base64 字元表包含大小寫英文字母、數字、加號與斜線，結尾可能帶有一或兩個等號作為填充。URL 安全變體會將加號與斜線替換為減號與底線，有時也會省略結尾填充。某些訂閱產生端還會在本文前加入不可見標記，或回傳包含額外空格的內容。若轉換工具只接受其中一種字元表，即使訂閱本身仍然有效，也可能回報「解碼失敗」。

解碼後的結果通常會呈現如下的逐行結構。以下僅示範結構，網域使用保留後綴，不對應任何可連線的服務：

vless://[email protected]:443?encryption=none&security=tls&type=ws&host=edge.invalid&path=%2Fconnect#Office
vmess://eyJ2IjoiMiIsInBzIjoiVGVzdCIsImFkZCI6Im5vZGUuaW52YWxpZCJ9

第一行是參數位於 URI 中的 VLESS 分享連結；第二行的 vmess:// 後方仍包含一段編碼文字，需要繼續解碼才能看到單一節點 JSON。也就是說，外層訂閱與單一 VMess 分享連結可能各自使用一次 Base64。只解開訂閱外層，不代表節點欄位已完成解析；連續解碼時也不能把一般 UUID、路徑或備註誤當成新的編碼層。

使用瀏覽器或命令列工具解碼時，也要留意文字編碼。節點備註通常採用 UTF-8；如果工具以其他字元集處理結果，中文備註可能出現亂碼，但伺服器位址、連接埠與 UUID 未必受到影響。遇到亂碼不應靠刪除節點欄位處理，正確做法是維持 UTF-8，並在重新編碼前確認換行與 URI 百分號編碼沒有被改動。

原生 JSON 設定的層級與界線

原生 V2Ray 或 Xray JSON 設定通常描述可直接交由核心處理的執行結構。不只包含遠端節點，也可能包含本機監聽連接埠、DNS、日誌、路由規則、策略及多個出站。以下是經過精簡的結構示意：

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "node.invalid",
            "port": 443,
            "users": [
              {
                "id": "11111111-2222-3333-4444-555555555555",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/connect",
          "headers": {
            "Host": "edge.invalid"
          }
        }
      }
    }
  ]
}

這類設定中的 inbounds 決定本機應用程式如何接入代理，outbounds 描述流量離開用戶端後的處理方式，routing 決定流量應進入哪個出站，dns 則控制網域解析。分享連結通常只涵蓋某個遠端出站所需的資訊，無法完整表達本機監聽、複雜分流、多個出站之間的關係及 DNS 規則。

有些服務會將「訂閱 JSON」設計成自訂物件，例如頂層包含節點陣列、更新時間或群組名稱。這種 JSON 並非核心原生設定，欄位名稱與層級由產生端和用戶端共同約定。看到大括號後，不能直接交給核心；應先檢查是否存在 inbounds、outbounds 等核心結構，或確認用戶端是否明確支援這種訂閱結構。

v2rayN 可管理節點、訂閱與路由，再依介面設定產生核心執行設定。Android 上的 v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心。即使三者都能辨識常見分享連結，實際支援的傳輸參數仍可能因核心版本而異。將完整 JSON 從一個用戶端複製到另一個用戶端時，本機監聽、日誌路徑或平台相關設定通常需要重新核對。

VMess 與 VLESS 分享連結各自保存哪些內容

VMess 連結：編碼後的單一節點物件

常見的 VMess 分享連結以 vmess:// 開頭，後方是一段以 Base64 編碼的 JSON。解碼後常見欄位包括版本識別、備註、伺服器位址、連接埠、使用者 ID、傳輸網路、偽裝網域、路徑與傳輸安全設定。不同產生工具可能使用簡寫欄位，欄位值也可能以字串形式保存，因此轉換時需要進行型別正規化。

VMess 分享物件是長期形成的交換格式，並不等同於完整的 V2Ray 設定規範。某些擴充欄位只有特定用戶端能夠辨識，另一些舊欄位在新核心中已不再發揮原有作用。轉換工具應優先保存明確可對應的資訊，不能根據備註文字猜測傳輸方式，也不應在缺少參數時自動填入與伺服器不一致的值。

VLESS 連結：URI 參數直接表達連線資訊

VLESS 通常採用標準 URI 格式：使用者資訊位置保存 UUID，主機與連接埠緊接其後，查詢參數描述加密標記、傳輸網路、安全層、伺服器名稱、路徑等內容，井字號後的片段則作為節點備註。查詢參數的順序通常不影響語意，但參數名稱、大小寫與取值必須依照用戶端支援範圍解析。

URI 中的路徑、備註、主機標頭等內容可能經過百分號編碼。例如斜線、空格與中文備註在連結中會呈現為逸出序列。解析時應先依 URI 規則拆分結構，再解碼各個欄位；若先對整條連結進行不加區分的替換，可能破壞分隔符號，或使路徑中的特殊字元改變含義。

分享連結未涵蓋的設定

單一連結主要用於節點交換，不負責攜帶整個用戶端環境。系統代理開關、TUN 設定、本機連接埠、訂閱更新週期、延遲測試方式、路由規則集與 DNS 策略通常不會隨節點連結傳遞。匯出後再匯入另一台裝置，節點可能會出現，但原有分流行為未必一併恢復；這是格式界線，而不是節點遺失。

格式轉換必須保留的關鍵欄位

將訂閱清單轉換為分享連結、從分享連結產生出站 JSON，或將完整 JSON 拆成單一節點資訊時，最重要的是建立欄位對應關係。伺服器能夠建立連線，依賴的不只是位址與連接埠，還包括身分、傳輸層、安全層及其附屬參數。

1. 伺服器位址與連接埠：網域應保持原樣，除非設定明確要求固定位址。過早將網域替換成某次解析得到的位址，可能繞過後續 DNS 更新。
2. 使用者身分欄位：VMess 和 VLESS 通常使用 UUID。複製、解碼與重新編碼過程中必須保持字元完整，不能將它當成數字處理，也不能移除連字號後自行改變格式。
3. 傳輸網路：TCP、WebSocket、gRPC 等傳輸方式需要與伺服器一致。只保留伺服器與連接埠而遺失網路類型時，用戶端通常會依預設方式連線，結果便會與原始設定不符。
4. 傳輸附加參數：WebSocket 路徑與 Host、gRPC 服務名稱等欄位都屬於連線的一部分。空字串、根路徑與欄位缺失有時代表不同含義，轉換時不宜合併處理。
5. 安全層參數：TLS 是否啟用、伺服器名稱及相關選項都應準確對應。伺服器位址與安全握手使用的名稱可能不同，不能因為兩者看起來相似就覆蓋其中一個。
6. 節點備註：備註不會決定連線，但會影響節點辨識與分組。應使用 UTF-8 保存，並在 URI 片段中正確進行百分號編碼。

將完整 JSON 轉換成分享連結時，最明顯的損失是路由與 DNS。假設設定中有 proxy、direct 和 block 三個出站，並由規則決定不同網域進入哪個出站，那麼匯出 proxy 對應的單一連結後，只能保留這個遠端連線。重新匯入連結不會自動重建另外兩個出站及其規則關係。

反向轉換同樣存在界線。分享連結可以產生一個遠端出站，但本機入站連接埠、日誌層級、DNS 伺服器與路由模式仍需由用戶端補充。v2rayN、v2rayNG 與 v2flyNG 通常會以各自的預設設定組合節點資訊，因此同一連結在不同裝置上匯入成功，不代表最後產生的完整執行設定會逐項相同。

訂閱匯入失敗的分層排查

遇到「訂閱無法解析」或「匯入後沒有節點」時，應依取得、解碼、拆分、協定解析與連線驗證的順序定位。一次修改所有欄位會掩蓋真正原因，也容易把原本可用的設定改壞。

第一步：確認取得的是訂閱本文

訂閱網址可能因授權失效、網路重新導向或伺服器錯誤而回傳一般提示頁。提示頁同樣是文字，但既不是 Base64，也不是 JSON。檢查回應開頭是否出現頁面標籤、錯誤說明或登入提示，並確認用戶端請求後取得的內容，與瀏覽器環境所需的驗證方式一致。

第二步：判斷是否需要外層解碼

如果本文由 Base64 字元組成，可以嘗試依標準形式與 URL 安全形式解碼。解碼後應出現可辨識的連結前綴或 JSON 結構。若結果仍是沒有規律的二進位內容，不要反覆解碼；先確認回應是否經過壓縮、字元集是否正確，以及複製過程中是否遺漏字元。

第三步：檢查行分隔與不可見字元

解碼結果包含多個連結，卻只匯入一個節點，常見原因是換行沒有正確辨識。檢查連結之間使用的是 LF、CRLF，還是被逸出成字面字元。檔案開頭的不可見標記也可能導致第一個連結的前綴辨識失敗。清理時只刪除明確的空白與標記，不要刪除 URI 內部的百分號編碼。

第四步：核對協定欄位與用戶端能力

連結可以辨識，但提示不支援參數，通常表示分享格式包含目前用戶端或核心版本尚未處理的欄位。先更新至適合平台的 v2rayN、v2rayNG 或 v2flyNG，再對照原始設定確認傳輸網路、安全層與附屬參數。不要為了追求「匯入成功」而隨意刪除未知參數，因為被刪除的欄位可能正是伺服器要求的連線條件。

第五步：將解析成功與連線成功分開判斷

節點出現在清單中，只能表示文字解析已完成。真正建立連線還取決於伺服器狀態、網域解析、本機網路、時間設定、傳輸參數與安全握手。排查時先確認節點欄位與來源內容一致，再執行實際連線測試；如果多個經格式轉換的節點都無法連線，應回到原始連結或原始 JSON 進行比對，而不是繼續疊加轉換。

依使用目的選擇格式

如果目標是定期取得多個節點，訂閱清單更適合集中更新；如果只需要在裝置之間傳遞一個節點，分享連結更直接；如果需要保存複雜分流、多個出站、本機入站與 DNS 策略，只有完整 JSON 能提供足夠的表達能力。格式選擇應取決於設定範圍，而不是比較哪一種字串看起來更短。

日常管理中，可以將訂閱作為節點來源，由用戶端負責更新與分組，再在本機維護路由和 DNS。需要遷移複雜設定時，應分別備份節點來源與本機規則，避免把單一分享連結當成完整備份。轉換前保留來源資料，轉換後逐項核對位址、連接埠、UUID、傳輸網路、安全設定、路徑與伺服器名稱，可以大幅減少「成功匯入但無法連線」的情況。