REALITY 與 XTLS Vision 經常同時出現在 VLESS 節點參數中，但兩者處理的是不同層面的問題：REALITY 負責建立連線、身分驗證與外觀特徵，Vision 負責連線建立後的資料流處理。若籠統地把兩者都理解成「加速協定」，容易誤判速度來源，也可能在匯入節點或排查日誌時找錯欄位。
本文適合已能匯入 VLESS 節點，並希望判斷 REALITY 與 Vision 是否適合目前線路的使用者。閱讀後可分清 TLS、REALITY、Vision 三層職責，核對用戶端關鍵欄位，並透過延遲、丟包、CPU 使用率與吞吐量資料判斷實際效益。
先拆解 TLS 握手與雙層加密成本
一般 HTTPS 連線通常會先完成 TCP 三向交握，再進行 TLS 握手。TLS 1.3 在連線順暢時通常只需 1 次往返延遲即可完成主要握手；如果用戶端到伺服器的往返延遲為 80 ms，光是等待網路往返就可能耗費約 80 ms。DNS 查詢、TCP 重傳與憑證鏈處理還會進一步增加首個封包的時間。
代理鏈路中也可能出現兩層加密：瀏覽器存取 HTTPS 網站時，應用程式資料已由網站 TLS 加密；如果外層代理傳輸又對整段資料執行一次通用加密，就會形成「內層網站 TLS＋外層代理加密」。這不代表設計錯誤，因為外層仍負責身分驗證與傳輸保護，但在傳輸大型檔案或高吞吐量鏈路中，重複處理會增加 CPU、記憶體複製與緩衝區調度成本。
延遲與吞吐量也需要分開觀察。握手最佳化主要影響首個封包與短連線體驗，流量控制最佳化則更容易反映在持續下載、影片傳輸與大量並行連線中。若線路只有 20 Mbps，CPU 原本就很空閒，Vision 未必能帶來肉眼可見的下載差距；如果伺服器出口達到 1 Gbps，而用戶端裝置的處理能力有限，降低重複加密與複製才更容易反映在速度上。
- 首個封包時間：關注 DNS、TCP、驗證與握手經過多少次往返。
- 持續吞吐量：關注 CPU 是否滿載、是否頻繁進行記憶體複製，以及線路是否丟包。
- 連線穩定性：關注 NAT 逾時、連接埠可達性、伺服器負載與中間網路品質。
- 協定相容性：用戶端與伺服器必須同時支援相應的 REALITY 與 Vision 實作。
REALITY 如何建立驗證與握手外觀
REALITY 是 Xray 體系中的傳輸安全方案，常與 VLESS、TCP 和 Vision 搭配使用。伺服器設定私鑰，用戶端持有對應的公鑰，並透過 shortId 等欄位參與驗證。用戶端還會攜帶 serverName、fingerprint 等參數，讓握手表現接近指定真實網站的 TLS 存取特徵。
這裡的「借用真實網站憑證」需要正確理解：REALITY 利用目標網站可驗證的 TLS 特徵建立連線外觀，但代理伺服器的身分仍由 REALITY 金鑰體系確認。用戶端不能只看 serverName 就判斷節點是否可信，publicKey、shortId、位址、連接埠等參數必須來自同一份有效設定。
VLESS + REALITY + Vision
- 網路
- TCP
- 安全性
- reality
- Flow
- xtls-rprx-vision
- 指紋
- chrome
- 常用連接埠
- 443
參數通常會隨分享連結或訂閱完整匯入，公鑰與 shortId 不應跨節點拼接。
VLESS＋TLS 傳輸
- 網路
- TCP 或 WebSocket
- 安全性
- tls
- 憑證
- 伺服器網域憑證
- Flow
- 依伺服器方案填寫
- 常用連接埠
- 443
傳統 TLS 方案由伺服器維護網域與憑證，適合需要標準 Web 入口的部署架構。
當未通過驗證的探測流量抵達時，伺服器可以將連線轉交給預設的目標網站，讓外部觀察結果更接近一般 TLS 服務。這個流程依賴正確的目標網站、連接埠與伺服器設定，並不表示任意網域都適合作為目標。目標應支援穩定的 TLS 1.3 存取，且其網路路徑必須符合伺服器環境。
- 用戶端先讀取節點中的位址、連接埠、使用者 ID、publicKey、shortId 與 serverName。
- 連線至伺服器後，用戶端依指定的 fingerprint 產生相應的握手特徵。
- 伺服器使用私鑰與驗證參數判斷連線是否來自合法用戶端。
- 驗證成功後進入 VLESS 資料通道；驗證失敗的流量則依伺服器策略轉交給目標。
XTLS Vision 為什麼能降低資料處理開銷
Vision 的重點不在於「使用更強的壓縮」，也不是單純將加密演算法換成更快的版本。它會辨識連線中的 TLS 資料形態，在完成必要驗證與初始保護後，對符合條件的內層 TLS 1.3 資料採用更直接的處理路徑，減少外層重複加密、解密與記憶體複製。內層 HTTPS 資料本身仍受到應用程式與目標網站之間 TLS 的保護。
這項最佳化不會直接套用到一般明文流量。Vision 需要依資料內容與連線階段調整流量控制，無法確認安全邊界時仍會維持外層保護。因此，實際效益取決於存取流量中的 HTTPS 比例、用戶端 CPU、伺服器 CPU、網路吞吐量與核心實作版本。
一組固定環境的對照測試可以說明差距來源：1 Gbps 有線網路、38 ms RTT、約 0.2% 丟包、同一台伺服器與同一個 1 GB HTTPS 檔案下，外層完整處理方案十次測試的吞吐量中位數為 684 Mbps，用戶端單一程序 CPU 峰值為 63%；啟用 Vision 後，吞吐量中位數為 742 Mbps，CPU 峰值為 48%。吞吐量提升約 8.5%，CPU 峰值下降 15 個百分點。這項結果僅用於示範分析方法，不代表所有線路都會得到相同比例。
結論：Vision 更像是處理路徑最佳化，不是產生線路頻寬的工具
如果測速已接近伺服器出口上限，修改 Flow 不會突破實體頻寬；若速度提升的同時 CPU 明顯下降，才符合減少重複加密與複製的預期。
- 低規格裝置、千兆鏈路與大量 HTTPS 傳輸更容易觀察到 CPU 差異。
- 高丟包線路可能先受到 TCP 重傳限制，流量控制最佳化無法取代網路品質。
- 短網頁請求更應關注首個封包時間，單次下載峰值無法完整代表瀏覽體驗。
- 伺服器負載過高時，應先檢查 CPU steal、連線數與出口壅塞。
REALITY 與 Vision 搭配後的實際鏈路
兩者搭配時，連線通常寫作 VLESS＋TCP＋REALITY，Flow 設定為 xtls-rprx-vision。REALITY 先處理握手外觀與身分驗證，Vision 再處理驗證後的資料流。VLESS 提供輕量的使用者驗證與資料承載，三者並非互相取代的關係。
在 v2rayN 中，分享連結可透過「伺服器」→「從剪貼簿匯入批次 URL」匯入。匯入後編輯節點，重點核對傳輸協定是否為 TCP、安全類型是否為 REALITY、Flow 是否為 xtls-rprx-vision，以及 serverName、publicKey、shortId 是否存在。全域核心設定可從「設定」→「參數設定」進入；切換核心後應重新啟動目前的連線。
- 先更新 v2rayN 使用的 Xray 核心，再匯入節點，避免舊版核心無法辨識 REALITY 欄位。
- 啟動連線前確認本機監聽連接埠沒有衝突。常見 SOCKS 連接埠為
10808，HTTP 連接埠為10809，實際值以「參數設定」為準。 - 啟動節點後查看資訊區域，正常情況應看到 Xray 啟動與入站監聽紀錄，而不是 unknown security 或 unsupported flow。
- 分別測試直連延遲、代理首個封包與持續下載，不要只用節點清單中的 TCP 延遲判斷頻寬。
v2rayN 桌面版核對
- 核心
- Xray
- 協定
- VLESS
- 安全性
- REALITY
- Flow
- xtls-rprx-vision
桌面版先檢查核心與欄位，再確認系統代理模式是否已開啟。
v2rayNG Android 版核對
- 核心
- Xray
- 匯入入口
- 從剪貼簿匯入
- 網路
- TCP
- 安全性
- reality
匯入後不要手動刪除公鑰或 shortId；系統省電限制可能會中斷背景連線。
哪些情境適用，哪些瓶頸無法解決
REALITY＋Vision 適合伺服器與用戶端都能執行較新版 Xray 核心、主要承載 HTTPS 流量、希望減少憑證維運流程並控制高吞吐量 CPU 開銷的情境。它也適合由單一伺服器直接接入、不依賴標準 Web 站點反向代理的架構。
如果現有部署依賴 WebSocket 路徑、標準 TLS 終止或與其他 Web 服務共用入口，就不能只將 security 改為 reality。REALITY 通常搭配 TCP 使用，伺服器監聽設定、目標位址、私鑰、公鑰與 shortId 都需要成套調整。訂閱服務產生的節點也必須完整包含這些欄位。
| 觀察到的現象 | 較可能的瓶頸 | 優先檢查項目 |
|---|---|---|
| 延遲穩定但下載速度上限為 50 Mbps | 出口限速或單一連線限速 | 伺服器頻寬、並行下載與出口佇列 |
| CPU 接近 100%，速度隨 CPU 波動 | 加密與資料複製開銷 | Xray 版本、Vision Flow 與裝置效能 |
| 每隔幾秒速度歸零 | 丟包、重傳或網路切換 | 持續 ping、核心日誌與網路穩定性 |
| 立即顯示握手失敗 | REALITY 參數不相符 | 公鑰、shortId、serverName 與系統時間 |
REALITY 也無法修復伺服器距離過遠、跨網壅塞、無線訊號不穩或 TCP 丟包等問題。以 180 ms RTT、5% 丟包的鏈路為例，即使 CPU 使用率很低，TCP 壅塞視窗仍會頻繁縮小，最終吞吐量可能遠低於 38 ms、0.2% 丟包的線路。此時應先更換出口或改善鏈路，而不是繼續疊加協定參數。
結論：先依瓶頸選擇方案
首個封包速度慢，先測試 RTT 與 DNS；持續下載速度慢，再查看 CPU 與丟包。只有在日誌確認 Vision 已生效、線路仍有餘裕時，協定對照測速才具備判斷價值。
常見設定疑問與排查順序
REALITY 節點故障通常集中在參數不完整、用戶端核心過舊、系統時間偏差或伺服器目標無法連線。排查時應保留原始訂閱內容，逐項比對，不要同時修改 serverName、fingerprint 與 shortId，否則無法判斷是哪一項讓連線恢復或持續失敗。
節點可以匯入，但啟動後提示不支援 REALITY？
先確認目前用戶端實際呼叫的是 Xray 核心。v2rayN 可進入「設定」→「參數設定」檢查核心選擇並更新核心；完成後結束目前連線，再重新啟動。若使用 v2flyNG，其 v2fly 核心不會處理這組 Xray 專用參數。
REALITY 節點一定要使用 443 連接埠嗎？
協定本身不強制固定連接埠，但 443 更符合一般 TLS 服務的使用方式。改用其他連接埠時，用戶端與伺服器必須設定一致，並確認伺服器防火牆、雲端平台入站規則及本地網路允許該 TCP 連接埠。
啟用 Vision 後測速為什麼沒有變化？
先確認節點 Flow 確實為 xtls-rprx-vision，再使用同一個檔案至少測試 5 次，記錄速度中位數與 CPU 峰值。如果線路頻寬已達上限或下載流量較小，效益可能主要表現為 CPU 降低，而不是速度繼續提升。
日誌顯示 invalid short id，應該修改哪個欄位？
重新從原始訂閱更新節點，核對 shortId 是否完整，並確認它與目前伺服器設定屬於同一個節點。不要複製另一個節點的 shortId，也不要自行補字元；伺服器修改後，用戶端設定也需要同步更新。
連線成功但網頁仍然無法開啟？
先檢查系統代理是否已啟用，再確認本機 SOCKS 或 HTTP 連接埠沒有被占用。v2rayN 常見連接埠為 10808 和 10809；如果日誌顯示監聽失敗，請在「設定」→「參數設定」中改用未使用的連接埠，然後重新連線。
最終判斷應建立在完整鏈路上：用戶端版本能辨識欄位，Xray 核心正常啟動，REALITY 參數成套相符，Vision Flow 在兩端一致，系統代理或應用程式代理指向正確的本機連接埠。只有這些條件同時滿足，測速資料才真正反映協定與流量控制的差異。