REALITY 協議與 XTLS Vision 技術科普：新一代傳輸為何更快

「REALITY 更快」通常把三件不同的事混為一談：握手是否順利、資料是否重複加密，以及線路本身是否壅塞。REALITY 主要處理身分驗證與外觀問題，XTLS Vision 主要處理資料傳輸路徑；真正決定最終速度的，還包括往返延遲、封包遺失率、伺服器頻寬與裝置效能。

TLS 握手成本：慢的不是「加密」兩個字

TLS 可理解為「傳輸層安全協定」。瀏覽器存取 HTTPS 網站時，客戶端會先傳送 ClientHello，伺服器回傳 ServerHello、憑證與握手參數，雙方確認金鑰後才開始傳輸應用程式資料。TLS 1.3 通常只需一次網路往返即可完成完整握手，因此往返延遲越高，首次建立連線時的等待就越明顯。

例如客戶端到伺服器的往返延遲為 120 毫秒，即使處理時間幾乎為零，完整 TLS 1.3 握手也很難低於一次往返。若網域解析、TCP 建立連線與 TLS 握手依序進行，首次連線還會繼續累積等待時間。頁面中的圖片與腳本若能重複使用同一條連線，後續請求才不必反覆支付這項成本。

憑證本身也會帶來處理與傳輸成本，但不能簡單理解為「自簽憑證一定比受信任憑證慢」。兩者都要交換憑證並完成密碼學運算。自簽憑證更突出的問題是，客戶端無法依賴公開信任鏈直接確認身分，部署者需要額外分發、固定或核對憑證資訊，設定維護也更容易出錯。

• 網路成本：TCP 建立連線、TLS 握手，以及可能發生的重傳。
• 計算成本：金鑰協商、憑證簽章驗證與對稱式加密。
• 設定成本：憑證申請、續期、私鑰保存與網域對應關係。
• 應用程式成本：代理層解密後，目標 HTTPS 流量可能仍需執行自身的 TLS 加密。

REALITY 的職責：身分驗證與真實 TLS 外觀

REALITY 常被稱為協定，但在設定結構中，更準確的說法是「傳輸安全層」。它通常與 VLESS、TCP 和 XTLS Vision 組合使用。VLESS 負責代理協定與使用者身分，TCP 承載位元組串流，REALITY 負責握手外觀與伺服器驗證，Vision 則決定符合條件的資料如何繼續傳輸。

傳統自建 TLS 服務通常需要準備網域憑證，讓伺服器直接展示自己的憑證。REALITY 改變了這種部署方式：伺服器持有 REALITY 私鑰，客戶端設定對應的公鑰，並透過 serverName、shortId 等欄位參與驗證。部署者不必再為這個入口單獨申請及續期自簽憑證或公開憑證，這就是「省去自簽憑證環節」更精確的含義。

REALITY 並不保證把一次遠距離往返變成零往返。它的直接效益首先是部署流程更短、憑證維護項目更少，以及握手外觀更接近一般 TLS 客戶端。在相同線路、相同機器與相同密碼套件下，只比較一般 TLS 與 REALITY 的首次握手，差距往往遠小於網路抖動。

XTLS Vision 的職責：減少代理層的重複加密

XTLS Vision 對應的常見 flow 值是 xtls-rprx-vision。它關注的不是憑證簽發，而是代理建立後，位元組如何從客戶端流向目標。存取 HTTPS 網站時，應用程式資料原本已由瀏覽器或應用程式完成 TLS 加密；如果代理外層再持續加密與解密整段資料，就會產生額外的密碼學處理與記憶體複製。

Vision 會識別符合條件的 TLS 流量，並在安全邊界允許時切換至更直接的資料路徑。可以將它理解為：驗證與必要的控制仍由代理完成，但大量且已加密的應用程式資料不再始終經過相同的重複封裝流程。系統支援時，還能使用更有效率的轉送方式，減少使用者模式與核心模式之間的複製。

減少重複處理不等於取消加密。瀏覽器到目標網站的 TLS 仍然存在，REALITY 連線所需的驗證與保護也仍然存在。Vision 只是避免對已符合條件的資料執行不必要的重複工作。一般明文 TCP、短小請求與無法識別的資料流，不一定能獲得同等幅度的效益。

效能差距通常出現在哪裡

1. 高速下載：吞吐量越高，每秒需要處理的資料越多，CPU 與記憶體複製的差異就越容易被放大。
2. 低功耗裝置：處理器效能有限時，持續加密與解密更容易造成頻率上升與耗電增加。
3. 多連線情境：影片、圖片與背景同步同時進行時，排程與複製成本會疊加。
4. 低延遲高品質線路：線路不再是瓶頸後，客戶端與伺服器的處理成本才更容易顯現。

組合後的實際差異：延遲、吞吐量與耗電

以下是一組用於說明測試方法的同機對照資料。伺服器為 4 核心 Linux 主機，監聽 TCP 443；客戶端網路往返延遲中位數為 86 毫秒，封包遺失率低於 0.5%；測試檔案大小為 2 GB，連續執行三輪並取中位數。兩組設定使用相同位址、相同線路與相同時間區段，僅調整傳輸組合。

在這組結果中，首位元組只差 2 毫秒，仍在正常抖動範圍內；持續吞吐量卻相差約 15.8%。這正好說明，REALITY 的主要價值不能概括為「握手瞬間快很多」，而 Vision 的差異更容易在大量流量階段出現。若線路上限只有 20 Mbps，兩組都會受頻寬限制，使用者很可能觀察不到吞吐量差異。

耗電測試也需要控制變因。以同一台 Android 裝置、螢幕亮度 40%、關閉背景同步、播放相同 1080p 影片 30 分鐘為例，對照組電量下降 7%，REALITY + Vision 組下降 6%。單次 1 個百分點不能推廣到所有裝置，但結合平均 CPU 使用率從 18% 降至 13%，可以判斷資料路徑減少處理後，確實降低了部分負載。

在 v2rayN 與 v2rayNG 中核對設定

桌面端使用 v2rayN，Android 端使用採用 Xray 核心的 v2rayNG。REALITY 與 Vision 需要客戶端核心支援，不是介面中出現欄位就一定能正常連線。排查時應同時記錄客戶端版本、Xray-core 版本與節點欄位；只更新介面程式卻保留過舊核心，也可能導致握手或 flow 識別失敗。

1. 確認核心

   在 v2rayN 中依序開啟「設定」→「參數設定」→「Core 類型」，確認 VLESS 使用 Xray core。測試環境可記錄為 v2rayN 7.12.5 與 Xray-core 25.6.8，方便重現問題。

2. 檢查節點

   編輯伺服器，逐項核對位址、連接埠 443、使用者 ID、傳輸方式 tcp、安全層 reality、flow 值 xtls-rprx-vision、serverName、公鑰與 shortId。

3. 儲存並重新啟動

   儲存節點後重新選取該伺服器，再執行「伺服器」→「重新啟動服務」。只關閉編輯視窗，無法保證舊連線會立即重建。

4. 讀取記錄

   開啟主介面的記錄區域，先確認核心已成功啟動，再搜尋 handshake、reality、invalid user 或 connection reset 等關鍵字。

5. Android 重新測試

   在 v2rayNG 中編輯同一個節點，確認傳輸層設定為 tcp、傳輸層安全性為 reality、流量控制為 xtls-rprx-vision。連線後從側欄開啟記錄，不要只根據狀態列圖示判斷。

v2flyNG 使用 v2fly 核心，主要面向 v2fly 體系支援的協定與傳輸。REALITY 與 XTLS Vision 是 Xray 著重支援的功能，因此這類節點應優先使用 v2rayN 的 Xray core 或 v2rayNG。將同一條 REALITY 分享連結匯入不同核心，不代表各核心會自動補齊相同能力。

記錄應先看哪幾行

2026/06/14 10:22:31 core started
2026/06/14 10:22:32 outbound: VLESS
2026/06/14 10:22:32 transport security: REALITY
2026/06/14 10:22:32 flow: xtls-rprx-vision
2026/06/14 10:22:33 connection established

上述順序比單獨看到「已連線」更有價值。核心成功啟動後，記錄還應明確顯示已進入 VLESS 出站、REALITY 安全層與 Vision flow。若錯誤發生在 connection established 之前，優先核對公鑰、shortId、serverName、系統時間與連接埠；若建立連線後網頁仍無法開啟，再檢查系統代理、路由規則與 DNS。

常見誤解與排查順序

協定問題最容易被誤判為線路問題，線路問題也常被誤判為客戶端問題。固定排查順序可以減少反覆修改設定：先確認本地時間與核心啟動，再核對節點欄位，接著測試網路可達性，最後才比較吞吐量與耗電。

另一個常見誤區，是把「REALITY」、「VLESS」與「Vision」當成三個可以任意切換的同級協定。實際設定是分層的：VLESS 位於代理協定層，REALITY 位於傳輸安全層，Vision 透過 flow 欄位改變資料處理方式。任何一層與伺服器不一致，都可能表現為逾時、握手失敗或連線後沒有資料。

• 連線前失敗：檢查位址、連接埠、本地網路與伺服器監聽狀態。
• 握手階段失敗：檢查系統時間、公鑰、shortId、serverName 與客戶端核心。
• 驗證後中斷：檢查 UUID、flow 與伺服器使用者設定。
• 連線後無法存取：檢查系統代理、DNS、路由分流與目標網站的可達性。
• 可以存取但速度很慢：檢查封包遺失、伺服器負載、線路頻寬與尖峰時段壅塞。

如何判斷是否值得切換至 REALITY + Vision

如果現有 VMess 或 VLESS 節點穩定、線路頻寬較低，且裝置 CPU 也沒有明顯壓力，切換後不一定會出現肉眼可見的速度變化。協定升級不能取代高品質線路，更無法修復伺服器出口壅塞。保留可重現的對照資料，比追逐單次測速峰值更重要。

如果主要流量是 HTTPS 影片、大型檔案下載或高並發網頁，且客戶端與伺服器都使用相容的 Xray-core，線路也能穩定達到較高吞吐量，REALITY + Vision 更有機會降低持續處理成本。對 Android 裝置而言，效益通常表現為長時間傳輸時 CPU 使用率更穩定，而不是每次點擊都立即快一倍。

最終判斷可以濃縮成一句話：REALITY 簡化並重新建構了安全握手與身分驗證方式，Vision 則優化符合條件的持續資料路徑。前者不等於憑空消除網路往返，後者也不等於取消加密。兩者結合後的速度優勢，只有在欄位相符、核心相容、線路穩定且測試方法一致時才有意義。