從握手往返次數、加密層開銷、行動裝置耗電三個面向,橫向比較 VMess、VLESS、Trojan、Shadowsocks,再給出可直接套用的選型順序。適合已經在 v2rayNG 或 v2rayN 匯入訂閱、需要在同一台伺服器的多個協定連接埠之間取捨的使用者;讀完能判斷目前網路下該優先保留哪種協定的節點。
握手路徑:四種協定各多出幾趟往返
協定之間的差距,一半來自握手,一半來自加密層。握手決定「連上要幾趟往返」,加密層決定「每傳一個封包要多花多少 CPU 和多少位元組」。VMess 與 VLESS 出自同一套 Project V 體系:VMess 自帶認證與加密層,VLESS 把加密完全交給外層 TLS 或 REALITY,自身只保留一個極簡請求標頭。
Trojan 走的是偽裝路線,認證資訊放在 TLS 建立之後的第一段資料裡,握手成本大約等於一次普通 HTTPS 握手。Shadowsocks 是另一種思路:不套 TLS,直接用 AEAD 對整條資料流加密,客戶端連上就能傳資料。
把四種協定放進同一張表,差異集中在往返次數與標頭位元組這兩欄。
| 協定 | 握手組成 | 額外往返 | 標頭開銷(量級) |
|---|---|---|---|
| VMess(AEAD,alterId=0) | TCP + VMess 認證標頭 | 0 | 約 40–50 位元組 |
| VLESS | TCP + 極簡請求標頭 | 0 | 約 20–40 位元組 |
| Trojan | TCP + TLS 握手 + 密碼驗證 | 1(TLS 1.3)/ 2(TLS 1.2) | 約 60 位元組 |
| Shadowsocks(AEAD) | TCP + AEAD 加密酬載 | 0 | 約 30 位元組 |
表裡的額外往返以裸 TCP 情境計算,標頭開銷不含 TLS 記錄層,實際位元組數會隨位址類型(網域、IPv4、IPv6)浮動。一旦把 VMess 或 VLESS 套進 WebSocket + TLS,就要再加一到兩趟 TLS 往返——這也是同一條線路上,裸 TCP 的 VLESS 往往比 WebSocket + TLS 的 VMess 先送出第一個位元組的原因。
握手開銷如何換算成首位元組延遲
一次請求的總延遲,大致等於鏈路 RTT 乘以往返次數,再加上伺服器處理時間。跨境線路單程 80 ms 時,一趟往返就是 160 ms 左右;TLS 1.2 的握手比 TLS 1.3 多一趟,首位元組就多出一個往返,在上述線路上約 160 ms。
開啟一個頁面通常不是一次連線,而是十幾次。瀏覽器的連線重用能省掉一部分,但每個新網域、每次訂閱更新、每個獨立 App 的請求,都可能重新走一遍握手。協定之間的差距,就在這些「重新握手」的次數上被放大。
VLESS TCP 1 趟 → 請求標頭隨首個封包送出,總往返 1
VMess TCP 1 趟 → 認證標頭隨首個封包送出,總往返 1
Trojan TCP 1 趟 → TLS 1.3 握手 1 趟,總往返 2
Shadowsocks TCP 1 趟 → AEAD 酬載直送,總往返 1把這張階梯套回四種協定:VLESS 與 Shadowsocks 只付 TCP 那一趟;VMess AEAD 同樣只多一個認證標頭,不額外佔用往返;Trojan 與套了 TLS 的 VMess、VLESS 則要多付一到兩趟。挑協定時先數往返趟數,再談其他參數。
結論:先看 TLS 版本,再看協定名稱
同一台伺服器上,VLESS 裸 TCP 與 Trojan 的首位元組差距,主要來自 TLS 1.2 與 1.3 的選擇;把伺服器端升級到 TLS 1.3 並開啟工作階段重用,收益比換協定更大。
行動裝置耗電:加密方式與連線次數
安卓端的耗電大頭不在協定名稱,而在兩件事:加密演算法有沒有硬體加速、單位時間內的連線次數。ARMv8 之後的手機 SoC 普遍帶 AES 指令集,VMess 與 Shadowsocks 選 aes-128-gcm 時 CPU 佔用低;只有較舊的 ARMv7 裝置上,chacha20-ietf-poly1305 的純軟體實作才更快。
連線次數與 Mux 多工複用有關。v2rayNG 的節點編輯頁裡有「啟用 Mux」開關,開啟後多條請求共用同一條連線,握手次數隨之下降,適合訊息類 App 這種高頻小請求;跑大型檔案下載時反而建議關掉,避免單條連線成為瓶頸。
不同鏈路品質下,這套本機參數的取捨並不一樣。
推薦方案:依鏈路品質分成兩套本機參數
行動網路(4G / 5G)
- 優先選用 VLESS + REALITY 或 Trojan + TLS 節點
- VMess 與 Shadowsocks 節點把加密方式設為 aes-128-gcm
- 開啟 Mux,降低握手次數
固網寬頻(Wi-Fi / 有線)
- VLESS 裸 TCP 與 Shadowsocks AEAD 都能跑滿頻寬
- 大流量下載時關閉 Mux
- 需要 UDP 的情境請確認伺服器端已開放 UDP 轉送
協定由伺服器端決定,客戶端能調的是加密方式、Mux 與路由模式這三項。
依情境挑協定:四種組合的適用範圍
協定要搭配傳輸方式,才是訂閱裡真正能用的節點形態。以下四種組合涵蓋了絕大多數訂閱中出現的節點類型。
VLESS + REALITY
推薦握手等於一次 TLS 1.3,不需要自簽憑證,抗主動探測的表現最好;Xray 核心原生支援,流控填 xtls-rprx-vision。
適合:日常主力、跨境高延遲線路
Trojan + TLS
流量形態與一般 HTTPS 一致,節點參數只有位址、連接埠、密碼三項;前提是伺服器端持有可用憑證。
適合:已有網域與憑證的自架節點
VMess + WebSocket + TLS
相容性最好,可以套 CDN 中轉;代價是多一層 WebSocket 與 TLS,握手往返次數最多。
適合:舊節點、需要 CDN 中轉的線路
Shadowsocks AEAD
握手最輕、CPU 佔用最低,連線建立幾乎只有 TCP 那一趟;沒有 TLS 外殼,流量特徵更明顯。
適合:內網跳板、鏈路穩定的專線
四種組合沒有絕對優劣:VLESS + REALITY 把握手壓到最低,且不需要自簽憑證;Trojan 的設定項目最少;VMess + WebSocket 在需要 CDN 中轉時幾乎是唯一選擇;Shadowsocks 在鏈路本身乾淨時開銷最小。
結論:先排除鏈路問題,再談協定
握手次數固定後,同一台伺服器上四種協定的吞吐差距主要來自加密開銷,量級在 10% 以內;而換一條丟包率更低的線路,首位元組延遲的改善往往超過 40%。
客戶端核對:協定欄位對照表
協定選型落到客戶端,就是幾個欄位的核對。v2rayNG 裡長按節點進入「編輯」,能看到別名、位址、連接埠、使用者 ID、alterId、加密方式、流控、傳輸方式與偽裝網域;v2rayN 裡是「伺服器」選單選中節點後點「編輯」,欄位與安卓端一一對應。
不同協定用到的欄位並不相同,下面這張對照表可以當檢查清單用。
| 欄位 | VMess | VLESS | Trojan | Shadowsocks |
|---|---|---|---|---|
| 使用者 ID / 密碼 | UUID | UUID | 密碼 | 密碼 |
| alterId | AEAD 模式下填 0 | 不適用 | 不適用 | 不適用 |
| 加密方式 | auto / aes-128-gcm | 固定為 none | 不適用 | aes-128-gcm / chacha20-ietf-poly1305 |
| 流控 flow | 不適用 | xtls-rprx-vision | 不適用 | 不適用 |
| 傳輸方式 | tcp / ws / grpc | tcp / ws / grpc | tcp | tcp |
把 VLESS 節點的「加密方式」改成 aes-128-gcm。VLESS 協定規定該欄位必須是 none,填其他值會在握手階段被伺服器端直接拒絕;需要更強的加密時,應該在外層選擇 TLS 或 REALITY。
連接埠方面,v2rayN 預設在本機開 10808(SOCKS)與 10809(HTTP),v2rayNG 的本機 SOCKS 連接埠同樣是 10808。這兩個連接埠只服務本機應用程式,和節點伺服器端的 443、8443 是兩回事,排查時別混淆。
改完參數回到節點列表,先做一次真連線延遲測試,再開啟頁面確認代理生效;如果測速正常但頁面打不開,優先檢查路由模式與分應用程式代理有沒有把目標 App 排除在外。
常見問題
同一節點換協定後速度差很多,是協定本身的問題嗎?
先核對兩件事:伺服器端 TLS 是 1.2 還是 1.3、節點有沒有套 WebSocket。協定自身的標頭只有幾十位元組,不足以造成成倍差距;差距通常來自這兩項,以及伺服器端到出口的那段線路。
安卓手機上哪種協定比較省電?
關鍵在加密方式而不是協定名稱。VMess 與 Shadowsocks 選 aes-128-gcm,ARMv8 裝置有 AES 硬體加速,CPU 佔用低;再開啟 Mux 減少握手次數。同一機型上換協定帶來的耗電差異,通常小於螢幕亮度的影響。
Shadowsocks 沒有 TLS,還能用嗎?
看鏈路環境。內網跳板或穩定專線上,Shadowsocks 的握手最輕、延遲最低;公網直連時沒有 TLS 外殼,流量特徵更明顯,被限速的機率更高,這種情境優先換成 VLESS 或 Trojan。
訂閱裡同一台伺服器提供多個協定連接埠,該留哪一個?
先用真連線延遲測試把每個連接埠都測一遍,保留首位元組最快的一個當主力。同一台伺服器的不同協定連接埠走的是同一台機器,差距通常來自握手方式,優先留 TLS 1.3 的 VLESS 或 Trojan 連接埠,其餘不用刪,方便隨時切換。