V2Ray 協議與核心
技術參考

先拆分協議、傳輸與安全層

一個節點不只是一個協議名稱

用戶端清單中顯示「VLESS」或「VMess」，只是連線結構的一部分。完整節點至少包含伺服器位址、連接埠、使用者身分、代理協議、底層傳輸與安全參數。以 VLESS 為例，它可以直接運作於 TCP，也可以透過 WebSocket、gRPC 等傳輸承載；外層可以使用標準 TLS，也可以搭配 REALITY。兩個都稱為 VLESS 的節點，如果傳輸層和安全層不同，握手次數、首封包大小、連線重用方式以及故障特徵也會不同。

分層理解的價值在於縮小排查範圍。用戶端提示「連線逾時」時，問題可能位於網域解析、TCP 建立連線、TLS 握手、REALITY 參數比對或代理協議驗證。若只反覆切換 VMess 與 VLESS，錯誤的伺服器名稱、連接埠或傳輸路徑不會因此改變。正確順序是先確認網路層可達，再確認安全層能完成握手，最後檢查協議身分與路由規則。

常見連線堆疊如何組合

VMess 內建使用者識別與時間相關驗證，常見組合包括 VMess over TCP、VMess over WebSocket 並疊加 TLS。VLESS 讓協議層更精簡，通常將機密性與伺服器身分確認交給 TLS 或 REALITY。Trojan 的常見形式是 Trojan over TLS，驗證資訊會在受保護的連線中傳遞。Shadowsocks 使用約定的 AEAD 加密方法直接保護資料流，設定項目相對集中。REALITY 則不是與 VMess、VLESS 同層的代理協議，而是 Xray 體系中的傳輸安全方案，最常與 VLESS 組合。

WebSocket、gRPC、HTTPUpgrade 和原生 TCP 也不是驗證協議，它們決定資料如何裝入底層連線。WebSocket 相容於成熟的 HTTP 基礎設施，但會增加框架封裝；gRPC 建立於 HTTP/2，適合多路複用與串流傳輸，但需要用戶端、伺服器及中間鏈路保持一致；原生 TCP 路徑較短、參數較少，通常更容易定位問題。QUIC 類傳輸建立於 UDP 之上，能否良好運作取決於網路的 UDP 品質與逾時策略，不能只依理論特性判斷。

比較時保持其他變數一致

協議測試需要控制變數。伺服器硬體、線路、加密演算法、傳輸方式、並行數與測試目標都應盡量一致。直接比較一條近距離 VLESS 節點與一條遠距離 VMess 節點，只能說明兩條完整鏈路的結果，不能證明協議本身較快。下載測速還會受到伺服器出口頻寬與目標網站限速影響；短連線測試較偏向握手開銷；長時間大流量傳輸更能觀察持續吞吐量與 CPU 使用率。

用戶端中的「延遲」也需要區分。ICMP ping、TCP 建立連線時間、實際代理握手，以及透過代理存取測試位址，都是不同指標。詳細原理可參閱延遲測試原理解析。選擇時應優先觀察實際連線是否穩定、常用應用程式是否正常，以及持續使用後的資源變化，而不是只取清單中最小的一個數字。

五類方案的背景與設計取捨

VMess：完整驗證機制與成熟相容性

VMess 是 Project V 生態早期形成的核心協議之一。它將使用者身分、請求中繼資料與動態驗證納入協議結構，設定中最常見的身分欄位是 UUID。VMess 的優勢不在於參數最少，而在於長期累積的用戶端支援與設定經驗。許多既有訂閱、面板輸出與舊設定仍以 VMess 為基礎，因此需要相容既有環境時，它經常是穩妥的選擇。

VMess 驗證與系統時間有關。裝置時間偏差過大時，即使位址、連接埠和 UUID 全部正確，也可能無法完成驗證。因此遇到「同一節點在一台裝置可用、另一台裝置立即失敗」時，應將系統自動校時列入檢查項目。VMess 也有不同的加密或安全選項，用戶端自動值通常用於適配核心能力；手動指定時必須確認伺服器支援，不能把舊教學中的固定值直接套用到所有設定。

VLESS：簡化協議層，依賴外部安全層

VLESS 的設計重點是減少協議本身承擔的加密與驗證負擔。它保留輕量的身分識別與代理請求表達，將傳輸機密性主要交給 TLS 或 REALITY 等安全層處理。這樣能減少重複加密的可能，也讓協議層與安全層的職責更清楚。代價是設定不能只停留在 UUID：流量控制、傳輸、安全類型、伺服器名稱與公鑰等欄位都會影響最終連線。

VLESS 本身不等於「已加密」。如果訂閱顯示 VLESS，還需要查看 security 欄位。使用 TLS 時要核對伺服器名稱與憑證的關係；使用 REALITY 時還要核對公鑰、短識別碼、指紋與伺服器名稱。用戶端介面若將這些欄位分散在不同區域，使用者容易只複製位址與 UUID，結果節點雖成功儲存，卻無法建立連線。

Trojan：以 TLS 作為基本組成

Trojan 的典型設定以密碼完成身分驗證，並依賴 TLS 保護連線。其概念模型相對直接：先正確完成 TLS 握手，再在受保護的資料中處理驗證與代理請求。對使用者而言，最關鍵的欄位通常是伺服器位址、連接埠、密碼、伺服器名稱與憑證驗證設定。若網域與憑證不相符，協議驗證尚未開始，連線就會在 TLS 層終止。

Trojan 的實際效能高度依賴 TLS 工作階段、網路往返時間與底層實作。它不會因名稱簡單，就必然比 VMess 或 VLESS 更省資源。長連線下，握手成本會被持續傳輸攤薄；大量短連線下，TLS 工作階段重用與用戶端連線池更為重要。比較 Trojan 時，應觀察用戶端日誌中的失敗發生在 TLS 還是驗證階段。

Shadowsocks：緊湊的加密代理結構

Shadowsocks 常簡稱為 SS。它使用密碼與加密方法衍生工作階段所需資訊，現代設定應使用目前核心支援的 AEAD 方法。其設定欄位較少、資料路徑直接，適合希望降低設定複雜度的環境。請注意，加密方法名稱必須完全一致。將相近名稱誤認為同一種演算法，或使用用戶端核心未實作的方法，都會導致連線失敗。

Shadowsocks 的訂閱表達方式有多種歷史格式。有些連結直接攜帶方法、密碼、主機與連接埠，有些還會附加外掛參數。用戶端能識別基礎 SS，不代表能識別所有外掛組合。匯入後應檢查「加密方式」和「外掛」欄位是否完整，尤其不能只因節點名稱已出現在清單中，就判定解析成功。

REALITY：安全方案，不是獨立代理協議

REALITY 屬於 Xray 功能體系，通常與 VLESS 組合。用戶端看到的「VLESS REALITY」表示 VLESS 負責代理語意，REALITY 負責傳輸安全。其關鍵參數包括伺服器公鑰、短識別碼、伺服器名稱與用戶端指紋。公鑰不是憑證檔案，短識別碼也不是使用者 UUID；這些欄位承擔不同角色，互換後不會產生可用連線。

REALITY 對設定精確度要求較高，但不代表日常使用複雜。訂閱完整、用戶端核心支援且欄位未被中間工具遺失時，匯入後通常即可直接連線。問題主要出現在舊版用戶端無法識別欄位、訂閱轉換器刪除新參數，或手動輸入時將 publicKey、shortId 和 serverName 放錯位置。若使用 V2Fly 核心的用戶端，應先確認目標方案是否在其支援範圍內，不能預設所有 Xray 擴充功能都能直接執行。

連線速度、吞吐量與資源使用量

首封包速度主要受握手鏈路影響

使用者感知的「開啟速度」通常由 DNS 查詢、底層連線、傳輸握手、安全握手、協議驗證與目標網站回應共同構成。協議層只佔其中一部分。在高往返延遲鏈路上，多一次需要等待對端回應的握手會明顯拉長首封包時間；在本地低延遲網路中，這種差異可能只有輕微體感。TLS 工作階段恢復、HTTP/2 連線多路複用與核心連線池也會進一步改變結果。

VMess、VLESS、Trojan 與 Shadowsocks 都能維持長連線，但用戶端與應用程式是否重用連線並不完全相同。瀏覽器可能重用 HTTP/2 或 HTTP/3 工作階段，命令列工具可能頻繁建立新連線，訊息類應用程式則常駐少量長連線。測試一個網頁不代表所有應用程式。選擇時至少需要涵蓋短連線頁面、持續下載與常駐應用程式三類行為。

持續吞吐量通常由線路與加密能力主導

進入穩定傳輸後，線路丟包、壅塞控制、伺服器出口、裝置單核心效能與加密實作往往比協議標頭大小更重要。VLESS 的協議層較輕，但若外層傳輸產生額外複製或隊頭阻塞，最終吞吐量未必更高。Shadowsocks 的資料路徑緊湊，但所選加密方法是否具備硬體加速，會直接影響低功耗裝置上的 CPU 使用率。

桌面處理器通常擁有充足的單核心效能，幾種常見方案在一般瀏覽和影片情境中的差異容易被網路波動掩蓋。路由器、低功耗主機和舊款 Android 裝置則更為敏感。此時應關注持續高負載下 CPU 是否長時間滿載、裝置是否降頻、網路中斷後能否迅速恢復，而不是只看一次測速峰值。關於路由裝置的硬體門檻，可繼續閱讀V2Ray 核心在路由器與旁路由上的部署概覽。

封裝層會增加頻寬與處理成本

原生 TCP 的封裝路徑通常最短。WebSocket 會增加框架標頭與 HTTP 升級流程，但相容性成熟，許多情境下這部分開銷相對於業務資料很小。gRPC 建立於 HTTP/2，能利用多路複用，不過流量控制視窗、連線重用及中間鏈路對 HTTP/2 的處理都會影響實際表現。傳輸層越複雜，需要核對的參數越多，發生故障時也越需要分層查看日誌。

小封包密集型應用程式更容易受到封裝與排程影響。語音、遊戲或即時控制流量對抖動和丟包敏感，平均下載速度不能代表使用體驗。UDP 經代理時，還要考慮協議是否支援 UDP、用戶端是否啟用相關能力、網路是否頻繁回收 UDP 對映，以及路由規則是否將相關網域與 IP 送入同一出口。任何一處不一致，都可能表現為登入正常但即時功能異常。

建立可重現的比較方法

測試時應固定裝置、網路、伺服器位置與目標檔案，並關閉會改變路徑的其他代理工具。先連續執行多次實際連線測試，記錄中位數而非最小值；再進行足夠長時間的下載，觀察穩定吞吐量；最後檢查用戶端程序與核心程序的 CPU、記憶體變化。若兩種協議來自不同伺服器，就只能評估節點整體品質，不能歸因於協議設計。

還應區分冷啟動與熱連線。首次啟動包含載入核心、建立 DNS 快取與建立安全工作階段；後續存取可能重用既有連線。若使用情境是頻繁切換網路，冷啟動與重新連線更重要；若裝置長時間在線，穩定性與背景資源更重要。沒有任何一種協議能在所有這些指標上固定領先。

Android 裝置的電量與背景行為

耗電不只來自加密運算

行動裝置上的代理耗電由無線網路喚醒、CPU 運算、虛擬網卡轉送、DNS 查詢、連線保活與應用程式背景流量共同構成。協議加密只是其中一項。螢幕關閉後，如果大量應用程式持續建立短連線，行動網路會反覆從低功耗狀態恢復，產生的能耗可能高於協議本身。反過來，少量穩定的長連線即使使用 TLS，也可能維持較平穩的功耗。

v2rayNG 使用 Xray 核心，適合需要 VLESS、REALITY 等 Xray 功能的訂閱；v2flyNG 使用 v2fly 核心，可作為面向 V2Fly 設定的選擇。兩者都可能透過 Android 的 VPN 介面接管流量。實際耗電取決於啟用的路由範圍、應用程式數量、DNS 策略與連線狀態，不能只憑用戶端名稱或協議名稱判斷。

虛擬網卡模式與系統代理的差異

Android 用戶端通常透過系統提供的 VPN 介面轉送應用程式流量。每個封包都需要經過使用者空間處理、路由判斷與出站連線，規則越複雜、並行連線越多，排程負擔越明顯。桌面端 v2rayN 可以只設定系統代理，也可以使用 TUN 模式接管不遵循系統代理的程式。TUN 的原理與權限要求可參閱TUN 模式接管全域流量的設定說明。

行動裝置沒有必要讓所有應用程式始終進入代理。若用戶端支援依應用程式分流，可只選擇確實需要處理的應用程式，減少無關的背景流量。路由規則也應保持可理解：先定義區域網路與必要直連，再處理代理規則，最後設定預設出口。大量重複或互相覆蓋的規則不僅難以維護，也會讓故障定位更加困難。

連線保活、重新連線與網路切換

Wi-Fi 與行動網路切換時，原有 TCP 連線通常需要重新建立。若用戶端保留失效連線過久，應用程式會經歷較長等待；若過於頻繁地探測與重新連線，又會增加喚醒次數。協議不會單獨決定這種行為，核心的連線管理、Android 背景限制與應用程式自身的重試策略都會參與。穩定使用時不建議同時啟用多個週期過短的連通性測試。

WebSocket、gRPC 與原生 TCP 對網路切換的恢復方式不同，但結果仍取決於應用程式是否重新發起請求。QUIC 或其他基於 UDP 的傳輸具有不同的連線語意，不過行動網路可能更積極地回收 UDP 對映。若表現為鎖定螢幕後恢復緩慢，應先確認用戶端是否受到系統背景執行限制，再觀察日誌中是網路無法連線、DNS 逾時，還是遠端連線被關閉。

DNS 策略會影響喚醒與失敗重試

DNS 設定不一致會產生重複查詢、逾時與回退。用戶端同時設定本地 DNS、遠端 DNS、系統 DNS 和應用程式自帶的加密 DNS 時，請求路徑可能比預期複雜。較穩妥的方法是明確哪些網域由本地解析、哪些透過代理出口解析，並避免多個規則同時接管同一類查詢。若節點伺服器使用網域，還要確保用於連線伺服器的解析不會被自身代理鏈路循環處理。

出現「瀏覽器可用但部分應用程式持續耗電」時，應查看這些應用程式是否不斷存取解析失敗的網域，或是否使用未被目前代理方式接管的網路介面。核心日誌中的重複逾時行，通常比電池統計中的單一百分比更有定位價值。若日誌持續出現相同目標的快速重試，應先處理路由或 DNS，而不是立即更換協議。

如何進行有意義的電量比較

比較兩套設定時，應使用同一台裝置、同一個網路與相近的業務流量。充電狀態、螢幕亮度、訊號強度與背景同步都會干擾結果。至少觀察一個完整的日常使用週期，並結合系統電池統計、用戶端日誌與裝置溫度判斷。短時間開啟頁面後查看電量變化，樣本不足，無法分離無線通訊與協議運算的影響。

若目標是降低資源消耗，應優先減少無效連線、縮小代理應用程式範圍、修正 DNS 逾時，並選擇裝置支援良好的加密實作。協議層應以相容性與穩定性為前提。一個理論上標頭較小、但在目前用戶端持續報錯重連的方案，實際耗電一定不會更好。

V2Fly 與 Xray 的核心家族關係

共同來源與不同演進方向

V2Fly 與 Xray 都源自 Project V 技術生態，保留許多相似的設定概念：入站、出站、路由、DNS、策略與傳輸設定。兩者都能處理 VMess、Shadowsocks 等多種常見設定，也都採用結構化設定描述連線關係。相似不代表完全相同。隨著各自演進，新增協議能力、傳輸選項、欄位名稱與預設行為都會出現差異。

Xray 在 VLESS、流量控制與 REALITY 等方向提供相應能力，因此 v2rayN 與 v2rayNG 常使用 Xray 處理這類節點。v2flyNG 面向 v2fly 核心，更適合訂閱本身依 V2Fly 能力產生的情況。用戶端介面只是設定入口，最終能否連線取決於目前實際啟動的核心是否理解這些欄位。

設定相似不代表可以原樣互換

基礎出站結構在兩個家族中可能十分接近，但擴充欄位會形成相容界線。例如一份包含 REALITY 設定的 Xray 設定，不能因外層仍是 JSON，就推斷 V2Fly 可以讀取。未知欄位可能導致啟動時直接報錯，也可能被忽略後產生與預期不同的行為。設定遷移必須按功能逐項確認，而不是只修改可執行核心名稱。

即使雙方都支援相同協議名稱，傳輸細節也可能不同。需要核對 network、security、flow、streamSettings、TLS 參數與 DNS 結構。用戶端自動產生設定時，會依所選核心調整欄位；手動匯入完整 JSON 時，這層轉換未必存在。因此一般使用者應優先匯入訂閱或分享連結，讓用戶端產生執行設定，而不是長期維護跨核心的大型設定檔。

v2rayN、v2rayNG 與 v2flyNG 如何對應

桌面端首選 v2rayN，支援 Windows、macOS 與 Linux。它提供訂閱管理、系統代理、路由模式與核心日誌入口，適合統一管理多種桌面環境。Android 上，訂閱包含 VLESS、REALITY 或明確依賴 Xray 的欄位時，優先使用 v2rayNG；訂閱依 V2Fly 能力輸出，或需要驗證 V2Fly 行為時，可以選擇 v2flyNG。

這三款用戶端並不是三種協議。用戶端負責介面、設定產生、系統網路接管與核心程序管理；核心負責解析設定與轉送流量；協議則描述用戶端核心與伺服器如何交換資料。將三個層次分開後，許多問題會變得明確：分享連結無法匯入屬於用戶端解析問題，核心啟動失敗屬於設定相容問題，握手失敗則通常進入協議或安全層排查。

從日誌判斷相容性問題

核心啟動失敗時，先讀取日誌中的第一條錯誤，而不是末尾重複的退出資訊。未知欄位、無法識別的協議類型、缺少必要參數與 JSON 語法錯誤，通常會在啟動階段明確出現。具體方法可閱讀從日誌第一行定位核心啟動失敗。如果核心已經啟動，但連線時失敗，則繼續查看 DNS、撥號、TLS 與驗證相關行。

遷移設定後若只有部分節點失效，應將可用與不可用節點按協議、安全層和傳輸層分類。所有 REALITY 節點失敗而 VMess 正常時，優先檢查核心能力；同一協議中只有某一種傳輸失敗時，優先檢查 streamSettings；所有節點都無法啟動，則檢查整體設定結構、連接埠占用與權限。這樣分類比逐一刪除並重建節點更有效。

訂閱格式與分享連結相容性

訂閱是容器，不等於協議

訂閱連結通常會回傳一組節點描述。節點可以是 VMess、VLESS、Trojan 或 Shadowsocks，也可能包含用戶端專用欄位。訂閱位址本身只負責定位內容，不能說明內部協議。用戶端更新訂閱後，需要先下載文字，再識別編碼與格式，最後將每個節點轉換為本地設定。任一階段失敗，使用者看到的結果都可能是「沒有節點」。

常見內容包括多條分享連結、經過編碼的連結集合或結構化設定。不同用戶端對擴充欄位與組合格式的處理範圍不同。若訂閱服務輸出 REALITY 參數，而中間轉換步驟只保留基礎 VLESS 欄位，匯入後節點仍會出現，但公鑰、短識別碼或指紋已經遺失。這種情況比完全解析失敗更隱蔽。

分享連結能表達什麼

VMess 分享內容一般包含位址、連接埠、使用者識別碼、傳輸與安全設定；VLESS 連結透過查詢參數表達 encryption、security、type、flow、serverName、publicKey、shortId 等資訊；Trojan 連結需要密碼、位址、連接埠及 TLS 相關參數；Shadowsocks 連結主要表達加密方法、密碼、伺服器與連接埠，並可能附帶外掛參數。

連結參數名稱區分明確。以 VLESS REALITY 為例，pbk 通常對應伺服器公鑰，sid 對應短識別碼，sni 對應伺服器名稱，fp 對應用戶端指紋。有些用戶端介面會顯示完整名稱，訂閱則使用縮寫參數。匯入後應對照欄位含義，不要依顯示順序猜測。

vless://使用者識別碼@example.invalid:443?encryption=none&security=reality&type=tcp&sni=www.example.invalid&fp=chrome&pbk=範例公鑰&sid=範例短識別碼#VLESS-REALITY-範例

上面的結構用於說明欄位位置，網域與身分資訊是明確的範例值。實際節點必須使用伺服器提供的完整參數。手動編輯連結時還要注意 URL 編碼：節點名稱中的空格、中文與特殊符號需要正確編碼；密碼若含保留字元，也不能直接依可見文字拼接。

匯入成功不等於設定完整

用戶端能建立節點記錄，只能證明最外層格式已被識別。下一步應開啟節點詳細資料，檢查協議類型、位址、連接埠、身分欄位、傳輸方式與安全層。對於 WebSocket，要檢查 path 與 Host；對於 gRPC，要檢查 serviceName；對於 TLS，要檢查 serverName；對於 REALITY，要檢查 publicKey、shortId、fingerprint 與 flow。

若更新訂閱後原有節點可用、新增節點不可用，應比較兩者的欄位差異，並確認用戶端核心能力。若所有節點消失，先確認訂閱回傳內容是否為空、位址是否被截斷，以及用戶端是否識別目前格式。六種高頻原因與檢查順序請見訂閱連結失效或解析失敗的自我檢查說明。

訂閱更新與本地修改的覆蓋關係

多數用戶端在更新訂閱時，會依訂閱群組重新產生節點。本地手動修改可能在下次更新後被覆蓋。需要長期保留的自訂路由、DNS 與系統代理設定，應放在用戶端提供的獨立設定區域，而不是逐一修改訂閱節點。臨時修改節點用於驗證問題時，建議複製為本地節點並重新命名，避免與訂閱來源混淆。

節點名稱不是穩定識別碼。訂閱提供者可以調整名稱或排序，用戶端也可能依位址、協議或內部識別碼去重。排查時應記錄協議、伺服器、連接埠與關鍵傳輸參數，而不是只說「第二個節點」。日誌中的目標位址與出站標籤更適合建立對應關係。

選擇用戶端時應看欄位保真度

桌面環境使用 v2rayN，可以在同一個介面檢查多種協議欄位與執行日誌。Android 訂閱包含 Xray 擴充功能時使用 v2rayNG；明確面向 V2Fly 設定時使用 v2flyNG。若訂閱同時包含多種協議，用戶端應能逐一保留欄位，而不是強制將所有節點轉換為單一協議。

遇到複雜訂閱時，最安全的判斷方法不是反覆經過多個轉換環節，而是直接在目標用戶端匯入原始訂閱，再各抽查一個不同協議的節點。確認欄位完整後再進行連線測試。每增加一次格式轉換，就增加一次欄位遺失、預設值變更與編碼錯誤的機會。

協議參數核對與故障定位

位址、連接埠與身分欄位

排查任何協議都從最基礎的三項開始：伺服器位址能否解析、連接埠是否正確、身分欄位是否完整。VMess 與 VLESS 常使用 UUID；Trojan 使用密碼；Shadowsocks 使用密碼與加密方法。複製時應清除前後空格，但不能改變內容內部字元。連接埠必須是有效數字，並與伺服器監聽設定一致。

伺服器位址是網域時，先確認用戶端所在網路能取得解析結果。若設定同時填寫 IP 與 serverName，要理解兩者用途不同：IP 決定連線目標，serverName 用於 TLS 或 REALITY 握手。將 serverName 替換為 IP 可能導致安全層失敗；將連線位址改為憑證網域，也可能改變實際線路。

TLS 與伺服器名稱

在 TLS 設定中，serverName 通常用於伺服器身分確認與握手。它應與伺服器設定及憑證關係一致。用戶端提供「略過憑證驗證」之類的選項時，不應將它當作常規修復方法。憑證錯誤通常表示網域、時間、憑證鏈或中間網路存在問題，關閉檢查會掩蓋根因，也讓後續遷移更難判斷。

系統時間也會影響憑證有效期判斷。若多個 TLS 節點同時失敗，而非 TLS 節點正常，應檢查裝置時間、時區與憑證相關日誌。只有一個網域失敗時，重點檢查該節點的 serverName、目標位址與伺服器憑證設定。

REALITY 的四組關鍵參數

REALITY 用戶端設定至少需要正確理解 publicKey、shortId、serverName 與 fingerprint。publicKey 來自伺服器的對應金鑰；shortId 是伺服器允許的值之一；serverName 必須符合伺服器設定；fingerprint 表示用戶端握手指紋類型。VLESS 身分 UUID 仍獨立存在，不能用 publicKey 取代。

flow 欄位也可能參與 VLESS 設定。伺服器與用戶端必須使用相容值。若訂閱明確提供 flow，應原樣匯入；若伺服器未啟用對應流量控制，不應根據其他節點經驗自行加入。錯誤的 flow 可能讓基礎連線建立後仍無法正確傳輸，日誌通常比用戶端顯示的通用錯誤更具體。

WebSocket、gRPC 與路徑欄位

WebSocket 主要核對 path 和 Host。path 是否以斜線開頭、是否包含查詢部分，應依伺服器原值處理；Host 與 TLS serverName 可以相同，也可能承擔不同作用。gRPC 主要核對 serviceName，並確認用戶端與伺服器對多路模式等選項的理解一致。將 WebSocket 的 path 填入 gRPC serviceName，名稱看似相近，協議行為卻完全不同。

當連線日誌顯示底層 TCP 已建立、TLS 也成功，但之後回傳 HTTP 狀態錯誤或串流被關閉時，應重點檢查傳輸路徑。若伺服器前方存在反向代理，還要確保它支援對應的升級或 HTTP/2 轉送。用戶端只會依設定發出請求，無法自動推斷正確路徑。

使用最小變數法排查

先選擇一個已知設定完整的節點，關閉自訂路由與額外 DNS 規則，使用用戶端預設代理模式測試基礎連線。基礎連線成功後，再逐項恢復路由、TUN、應用程式分流與自訂 DNS。若一開始就同時修改協議、傳輸、路由與系統代理，失敗後便無法判斷是哪一項造成。

日誌需要從首次錯誤開始讀取。重複重新連線會產生大量相似行，末尾通常只記錄程序退出或情境取消。保存一次乾淨測試：清空日誌、啟動核心、存取一個明確目標，等待錯誤出現後停止。如此可以按時間順序排列 DNS、撥號、握手與驗證。

依使用情境選擇協議與用戶端

已有訂閱優先維持原始設定

如果訂閱已提供可用節點，第一原則是依原始協議與參數匯入，不要為了追求某個名稱而手動轉換。VMess 節點不能只修改類型就變成 VLESS，Trojan 密碼也不能直接當作 Shadowsocks 密碼使用。協議轉換需要伺服器同時提供對應的監聽與參數，單方面修改用戶端並不能完成轉換。

桌面使用者優先選擇 v2rayN，再依訂閱內容選擇節點。Android 使用者遇到 VLESS、REALITY 或其他 Xray 擴充功能時使用 v2rayNG；訂閱明確依 V2Fly 核心產生時可使用 v2flyNG。對應安裝入口集中在用戶端下載頁，平台說明包含 Windows、macOS、Android 與 Linux。

需要相容舊環境時選擇 VMess

既有伺服器、訂閱系統與用戶端都穩定支援 VMess 時，沒有必要只因出現新協議就立即遷移。VMess 的設定資料與相容經驗較豐富，適合需要繼續使用現有 WebSocket、TLS 或 TCP 組合的環境。需要重點維護系統時間、UUID、傳輸欄位與安全設定。

若計畫逐步遷移，可以讓伺服器並行提供新舊入口，在相同線路與裝置上測試。先驗證功能與穩定性，再處理訂閱切換。遷移期間保留可運作的原始設定，有助於區分新協議問題與伺服器整體問題。

需要清晰分層時選擇 VLESS

VLESS 適合希望將輕量協議層與 TLS、REALITY 等安全層明確組合的環境。使用標準 TLS 時，憑證、serverName 與傳輸設定必須完整；使用 REALITY 時，需要 Xray 核心以及相符的公鑰、短識別碼、指紋與流量控制參數。它的優勢來自完整連線堆疊的合理組合，不是單純將協議名稱改成 VLESS。

在 v2rayN 和 v2rayNG 中匯入 VLESS 分享連結後，應抽查 streamSettings。若訂閱經過轉換，尤其要確認 REALITY 參數沒有被刪除。設定準確時，日常操作並不比其他協議複雜；設定來源不完整時，需要排查的欄位會比基礎 VMess 更多。

以 TLS 設定為核心時考慮 Trojan

伺服器已依 Trojan 方式提供密碼與 TLS 參數時，用戶端直接使用對應節點即可。選擇重點是憑證與伺服器名稱是否正確、TLS 工作階段是否穩定，以及目前傳輸是否與伺服器一致。Trojan 適合偏好清晰密碼驗證與 TLS 連線結構的環境，但不能繞過憑證、網路與伺服器設定的基本要求。

大量短連線情境應觀察首封包與工作階段重用，持續下載情境則應觀察穩定吞吐量。不要只根據協議結構推斷效能。若 Trojan 節點與其他協議節點不在同一台伺服器，測試結果主要反映完整線路差異。

追求較少設定項目時考慮 Shadowsocks

Shadowsocks 的基礎設定集中在位址、連接埠、密碼與加密方法，適合伺服器已提供用戶端支援的現代 AEAD 方法，且不依賴複雜擴充功能的情境。低功耗裝置上還應確認所選演算法具備良好實作，不能把「參數少」直接等同於「任何裝置都更快」。

如果分享連結帶有外掛參數，需要確認用戶端是否支援該外掛與選項。基礎 SS 可以匯入但外掛欄位遺失時，節點仍可能無法使用。UDP 應用程式還要單獨確認用戶端、核心、伺服器與網路鏈路都支援相應轉送。

行動端優先穩定連線與清晰分流

在 Android 裝置上，協議差異經常小於背景限制、訊號強度與 DNS 重試造成的差異。先選擇用戶端核心明確支援的節點，再限制不必要的代理應用程式，保持路由規則簡單，並觀察網路切換後的恢復情況。若鎖定螢幕後出現異常，不要立即歸因於協議。

需要長時間在背景執行時，應選擇穩定且不會頻繁重新連線的完整設定。一次測速略高但持續出現握手重試的節點，不適合作為背景預設連線。透過日誌確認重新連線原因後，再決定是修正參數、更換傳輸，還是更換節點。

最終決策順序

第一步確認伺服器實際提供哪些協議與完整參數；第二步確認目標用戶端與核心支援該組合；第三步匯入後核對欄位是否完整；第四步使用實際連線、持續吞吐量與常用應用程式測試穩定性；第五步再觀察 CPU、記憶體、電量與網路切換。這個順序能避免將格式解析問題誤判為協議問題，也能避免用單次延遲數字取代長期使用體驗。

如果只需要完成安裝、訂閱與連線，請返回快速入門教學依步驟操作。需要選擇安裝套件時，前往V2Ray 用戶端下載頁。遇到訂閱解析、核心啟動或延遲指標問題，可繼續閱讀本頁連結的專題文章。協議選擇沒有脫離伺服器、核心與網路條件的統一答案，完整相容性與穩定運作應排在理論差異之前。