REALITY 與 XTLS Vision 原理解析：少一層加密為何更快

先釐清三個名稱：VLESS、REALITY 與 Vision

在 v2rayN 或 v2rayNG 中，常見的節點組合是「VLESS + REALITY + XTLS Vision」。這三者不是可以互換的協定名稱。VLESS 說明代理請求如何帶上使用者身分與目標位址；REALITY 負責外層連線的安全握手與驗證；Vision 則是 Xray 的流量控制機制，決定通道內部分資料的處理方式。先釐清這三個層次，才能知道出錯時該從哪個欄位查起。

VLESS 的 encryption 常見值為 none。這表示 VLESS 協定本身不會再額外加上一層負載加密，不代表整條連線都以明文傳輸。使用 REALITY 時，安全層仍會參與建立連線；瀏覽器瀏覽 HTTPS 網站時，應用程式本身的 TLS 加密也依然存在。

HTTPS 經過代理時，為什麼會有兩層加密？

瀏覽器開啟 HTTPS 網站時，會先與目標網站進行 TLS 握手。接著，網頁內容、登入資訊與回應資料都會成為應用層的 TLS 密文。代理的工作只是將這條連線傳送至目標網站，不會因此取得網站連線的解密金鑰。

如果代理通道本身也使用 TLS，瀏覽器產生的密文就會再包進代理連線的 TLS 記錄中。用戶端加密一次外層，伺服器解密外層後，再將內層密文轉送至網站。這種「雙層封裝」很常見，也有實際用途；不過在大量傳輸時，會增加額外的加解密、緩衝區處理與資料複製成本。

Vision 的核心不是取消 HTTPS，而是辨識內層 TLS 所處的階段，並在符合條件時調整後續資料的傳輸方式。對於辨識出的 TLS 1.3 流量，它能在適當階段切換為直接轉送，讓已加密的應用程式資料不必再經過外層 TLS 加解密。初始握手與必要的代理資訊仍會受到保護，並非連線成功後就把所有資料裸露傳送。

• 網站端的加密維持不變：瀏覽器仍會驗證目標網站的憑證，代理也不應要求使用者關閉網站憑證驗證。
• 最佳化有辨識條件：並非所有 TCP 資料或 TLS 版本，都能採用相同的最佳化路徑。
• 一般 HTTP 不會因此變成 HTTPS：Vision 不會替應用程式補上與目標網站之間的端對端加密。
• 握手階段仍會填充資料：Vision 會填充初始階段的資料，因此不能簡化成「每個封包都變小」。

REALITY 如何借用真實網站的握手外觀

一般 TLS 代理服務通常需要準備自己的網域與憑證。REALITY 採用不同的設計：伺服器會設定合適的真實 TLS 目標，用戶端則帶上約定的驗證參數發起握手。通過驗證的連線會在用戶端與 REALITY 伺服器之間建立代理通道；未通過驗證的連線則可由伺服器轉交給設定的目標，呈現與真實網站正常進行 TLS 交握的樣貌。

「借用真實網站」是為了方便理解的說法，不表示持有該網站的私鑰，也不代表代理的所有流量都會先繞到該網站。驗證成功後，伺服器會依目標位址轉送代理資料；設定的真實網站主要參與握手外觀與未驗證連線處理等機制。用戶端用來信任 REALITY 伺服器的依據，也不是單純把目標網站的公開憑證複製到本機。

位址、SNI 與真實目標是不同欄位

• 伺服器位址：用戶端實際連線的代理伺服器 IP 或網域，不能隨意改成握手目標網站。
• SNI / Server Name：用戶端在握手時使用的名稱，必須符合伺服器允許的名稱。位址能連上，不代表這個欄位就正確。
• 伺服器端的真實目標：由伺服器管理者選定。應確認 TLS 1.3、HTTP/2 等相容條件，並留意伺服器連往目標時的延遲與可用性。
• 用戶端指紋：會影響 ClientHello 的組成，例如 chrome。它無法取代正確的金鑰、SNI 與身分參數，也不能保證行為與真實瀏覽器完全一致。

在 v2rayN 與 v2rayNG 中，哪些參數需要核對？

建議先從可信任的訂閱匯入完整節點，再進入節點編輯頁面核對欄位。不同版本的用戶端可能會更改選單名稱，但協定、傳輸方式、安全層與 Flow 的意義不變。以下兩張卡片呈現同一連線兩端的核對關係，並非可直接複製使用的完整節點。連接埠 443 只是常見範例，實際設定請以伺服器監聽的連接埠為準。

REALITY 的金鑰參數在用戶端介面與不同版本的 Xray 設定中，名稱可能有所不同。舊版設定常見 publicKey，較新的設定則可能使用 password。不要只看欄位名稱就手動搬移 JSON，應依目前執行的核心文件與用戶端匯入規則處理。伺服器私鑰則絕不可提供給一般使用者。

Short ID 使用十六進位字串；若非空值，字元數必須是偶數，且最多 16 個字元。是否允許空值取決於伺服器設定。它不是使用者 ID，也不是可以隨意填寫的備註。若訂閱中已提供 Short ID，請保留原值；即使只自行修改一個字元，也可能導致驗證失敗。

少一層加密為何可能更快？又為何不一定？

加密並非唯一的成本，但在高吞吐量連線中，可能成為明顯的負擔。Vision 會減少符合條件的資料重複加解密，並在實作允許時採用更有效率的傳輸路徑，降低 CPU 使用率與資料搬移負擔。伺服器同時處理多條大流量連線時，這種改善比短小的網頁請求更容易顯現。

如果瓶頸來自行動網路封包遺失、伺服器出口頻寬、電信業者網路壅塞或目標網站限速，少一層加密不見得能提升下載速度。TCP 壅塞控制依然存在，REALITY 也不會增加線路的實體頻寬。不能因為某個節點速度快，就推論「所有 REALITY 節點都比其他組合快」。

如何進行可比較的測試

1. 固定使用同一台裝置、同一個網路、伺服器與下載目標，關閉其他大量傳輸工作，避免把 Wi-Fi 訊號變化誤當成協定帶來的效益。
2. 使用伺服器明確支援的兩組測試設定，不要直接清空 Flow 欄位當作對照；用戶端與伺服器的設定必須互相吻合。
3. 每組連續下載 60 秒，重複 3 次，同時記錄平均傳輸量、用戶端 CPU、伺服器 CPU 與連線錯誤。
4. 分別測試大型檔案下載與網頁首次開啟。如果只有 CPU 使用率下降、傳輸量沒有變化，表示最佳化確實有效，但目前的速度瓶頸可能在其他地方。

連線失敗時，依握手階段逐步排查

「握手失敗」只代表安全連線尚未完成，不能直接判定是憑證問題。REALITY 驗證參數不符、SNI 不在允許清單中、伺服器無法連上目標，或裝置時間有誤，都可能造成連線失敗。先確認 TCP 能否建立，再檢查 REALITY 驗證，最後核對 VLESS 使用者與 Flow，通常比反覆切換加密選項更有效。

1. 先檢查連線位址：確認用戶端連線的是代理伺服器，而不是握手目標。如果記錄顯示連線逾時或遭拒，請檢查監聽連接埠、防火牆與網路連線狀況。
2. 接著檢查系統時間：在 Windows 的「設定」→「時間與語言」→「日期與時間」中，確認自動設定時間與同步狀態；Android 也應開啟自動日期和時間。REALITY 可依伺服器政策限制時間差。
3. 核對驗證參數：逐一比對 SNI、用戶端驗證金鑰參數與 Short ID。伺服器更換金鑰後，即使位址沒有變更，舊訂閱也可能無法繼續使用。
4. 檢查使用者與 Flow：確認伺服器上存在該 VLESS 使用者 ID，且兩端使用相容的 Vision 設定。不要混淆 REALITY 安全層選項與 Flow 欄位。
5. 確認實際使用的核心：確認 v2rayN 目前使用的是支援此組合的 Xray 核心。介面能儲存節點，不代表所選核心一定接受所有欄位。
6. 最後檢查目標與轉送：若握手已成功但網頁仍無法開啟，請檢查伺服器 DNS、出站路由、目標連線狀況，以及用戶端是否將該流量送進代理。