VLESS 負責代理協定與使用者識別，REALITY 處理連線握手與驗證，XTLS Vision 則調整流量封裝方式。本文適合準備匯入或手動設定 REALITY 節點的使用者，說明三者的分工、效能提升的條件，以及 v2rayN 中位址、SNI、公鑰、Short ID 和 Flow 的對應欄位。
VLESS、REALITY 與 Vision 各自負責什麼
節點名稱中的「VLESS + TCP + REALITY + Vision」不是四個同義詞，也不是把四種加密疊在一起。拆解各自所屬的層級，才能理解為什麼同樣標示 VLESS 的兩個節點，設定欄位和連線表現可能截然不同。
- VLESS：代理協定，承載使用者識別、目標位址等資訊。通常以 UUID 識別使用者；協定本身不負責類似 TLS 的內容加密。
- TCP：此處採用的底層傳輸方式。較新的 Xray 設定和部分介面也會使用 RAW 這個名稱，請依用戶端與核心的欄位說明判斷。
- REALITY：Xray 生態系中的傳輸安全機制，涵蓋握手、伺服器身分驗證，以及未通過驗證的連線如何處理。
- XTLS Vision：VLESS 的流控方案，常見 Flow 值為
xtls-rprx-vision，用來調整初期資料的傳輸形式，並在符合條件時減少重複封裝與加密。
v2rayN 是管理介面，實際建立連線的是它啟動的核心。討論這組參數時，應確認目前節點是由支援相關功能的 Xray 核心處理，而不只是看用戶端視窗能否開啟。V2Fly 與 Xray 的功能發展並不完全一致，不能因為兩者都源自 V2Ray 技術體系，就直接沿用同一份 REALITY 設定。
REALITY 握手：位址、SNI 與驗證資訊
瀏覽器連線至 HTTPS 網站時，會先協商 TLS 參數並驗證對端身分。代理連線則在瀏覽器與網站之間多出一段用戶端至代理伺服器的連線。REALITY 主要處理的是這段連線，而不是代替瀏覽器簽發目標網站憑證。
REALITY 用戶端會使用伺服器提供的公鑰等參數驗證連線，並在握手過程中傳送相應的驗證資訊。伺服器也會檢查設定允許的伺服器名稱、Short ID 等條件。未通過驗證的連線可依 REALITY 機制轉往伺服器設定的目標網站；實際行為取決於設定及失敗階段，並非任何錯誤都一定會開啟網頁。
有兩種位址很容易混淆：節點的「位址」決定用戶端要連線到哪台代理伺服器；SNI，也就是伺服器名稱，是握手時使用的名稱參數，通常必須符合伺服器允許的名稱。直接把節點 IP 填入 SNI，或將節點位址改成 SNI 對應的網站位址，都可能導致原有設定失效。
- 節點位址與連接埠：由節點提供方提供。常見連接埠是
443，但這只是常見慣例，不代表其他連接埠無法使用。 - 伺服器名稱：對應
serverName；分享連結中常見的參數名稱是sni，請保留原樣。 - 公鑰：必須與伺服器端的私鑰配對。用戶端只需取得連線所需的公鑰資訊，不應索取或填入伺服器端私鑰。
- Short ID：是伺服器允許的短識別碼，不是從 UUID 擷取的片段，也不是可以任意填寫的備註。
- 指紋：常見值為
chrome，用來選擇用戶端的握手特徵，不會把實際使用的瀏覽器變成 Chrome。
REALITY 不要求網站管理員以傳統方式為這段代理連線設定自己的網域憑證，但伺服器端目標網站的選擇與連線可達性仍很重要。它也無法保證流量在所有網路環境中都無法辨識；除了握手之外，連線時間、封包長度和存取行為仍是網路上可觀察的資訊。
XTLS Vision 為何可能降低開銷
一般 TLS 代理承載 HTTPS 流量時，會有兩層保護：瀏覽器與目標網站之間已有一層 TLS，用戶端與代理伺服器之間又再包一層 TLS。這不代表內容有問題，但外層的重複處理會耗用運算資源，也會增加記錄封裝與資料複製等開銷。
Vision 會辨識代理連線的初期資料，並在前期透過填充等方式調整資料形式；對符合條件的 TLS 流量，尤其是可辨識的 TLS 1.3 連線，可在適當階段切換資料處理方式，避免持續對已加密的應用程式資料進行相同的外層加密。瀏覽器與目標網站之間的 TLS 仍然存在。
「更快」有明確的適用範圍。如果伺服器的加密處理或資料轉送已接近 CPU 上限，減少重複處理就比較可能帶來效益；如果瓶頸是跨境線路壅塞、伺服器限速或封包遺失，換成 Vision 也不會憑空增加頻寬。非 TLS 流量和不符合最佳化條件的連線，也不能預期會有相同效果。
判斷方式：同時觀察傳輸量與 CPU 使用率
在同一台伺服器、下載同一個目標檔案，並選擇相近時段比較下載表現，同時記錄 CPU 使用率。只有傳輸量提升，或在傳輸量相同時 CPU 使用率降低，才能支持「開銷減少」的判斷；單次延遲測試無法證明 Vision 比較快。
v2rayN 設定欄位：逐項對照伺服器參數
建議先匯入完整的訂閱或分享連結，再檢查重要欄位。不同版本的 v2rayN 桌面版選單文字可能略有差異，常見作法是複製分享連結，再透過「伺服器」→「從剪貼簿匯入批次 URL」匯入，接著開啟對應項目的編輯視窗。不要只因節點名稱包含 REALITY，就認定欄位已經完整。
VLESS 與傳輸欄位
- 協定
- VLESS
- 使用者 ID
- 伺服器端指派的 UUID
- 加密方式
- 常見組合為 none
- 傳輸方式
- TCP / RAW，依版本介面對應
- Flow
xtls-rprx-vision
本區說明常見的 REALITY + Vision 組合；若提供方另有說明，請以其設定為準。
REALITY 握手欄位
- 傳輸安全性
- reality
- SNI
- 伺服器端允許的伺服器名稱
- 公鑰
- 伺服器端提供的 REALITY 公鑰
- Short ID
- 伺服器端允許的十六進位識別碼
- Fingerprint
- 例如 chrome，請依原設定保留
不同版本可能會將公鑰標示為 Public key 或 Password 等名稱，請搭配核心版本與匯入結果確認。
VLESS 的 none 是這類組合中該欄位的常見值，不代表整段連線以明文傳輸。此處的保護來自所選用的傳輸安全機制。反過來說，手動改成 VMess 常見的 auto，並不是「加密更強」的升級方式，而是混淆了不同協定的欄位。
- 先確認位址、實際連接埠和 UUID，再核對傳輸方式、安全類型與 Flow；這些欄位決定連線能否進入預期的協定流程。
- 接著逐字核對 SNI、公鑰和 Short ID，並留意複製時是否多了空格。Short ID 若有填寫，必須包含偶數個十六進位字元，長度不得超過 16 個字元；是否允許留空則由伺服器端決定。
- 確認該項目實際使用支援 REALITY 與 Vision 的 Xray 核心，再將其設為作用中的伺服器。不要把「介面儲存成功」當成「核心已支援」。
- 在「設定」→「參數設定」中確認本機監聽連接埠，再選擇「系統代理」→「自動設定系統代理」。若目前版本的文字不同，請尋找對應功能項目。
效能比較：先固定條件，再討論協定差異
比較不同訂閱中的兩個節點，通常最先比較到的是線路和伺服器資源，而不是協定本身。負載較低的一般 TLS 節點，完全可能比壅塞的 REALITY 節點快。若要判斷 Vision 的影響，應盡量只變更流控方案，並確認兩組伺服器設定都有效。
| 測試項目 | 建議方法 | 可判斷的事項 |
|---|---|---|
| 建立連線 | 使用同一個 HTTPS 網址，分別建立 5 次新連線 | 觀察握手和首次回應是否穩定 |
| 持續傳輸量 | 使用同一個較大的檔案，每輪至少 60 秒，交替測試 3 輪 | 降低瞬間突發與時段差異造成的干擾 |
| 資源使用量 | 記錄測試期間用戶端與伺服器端的 CPU 使用率 | 判斷重複處理是否構成瓶頸 |
| 網路條件 | 固定使用相同的網路、路由規則和目標網站 | 避免將直連、代理或線路差異誤當成協定效益 |
上表是測試方法，並非本站實測結果。記錄速度時也要留意單位：100 Mbps 理論換算約為 12.5 MB/s，實際應用程式傳輸量會受協定開銷和線路狀況影響。如果路由規則讓測試網域採用直連，測試結果就無法用來評估 REALITY。
- 網頁第一次開啟較慢、後續下載較快：優先檢查 DNS、握手耗時和目標網站回應。
- 下載速度逐漸下降且 CPU 接近滿載：檢查核心資源使用量、裝置效能和其他背景工作。
- 尖峰時段所有節點都變慢：優先比較不同線路和時段，不要反覆修改公鑰或 Flow。
REALITY 連線失敗常見問答
連接埠測試正常，為什麼網頁還是打不開？
TCP 連接埠連通，只代表能與目標連接埠建立連線，不代表 REALITY 驗證已通過。先查看核心記錄，再依序比對位址、SNI、公鑰、Short ID 和 UUID 是否與原始訂閱一致；若出現驗證相關錯誤，繼續更換 DNS 通常無法解決。
記錄顯示 Flow 不受支援，要清空嗎？
先檢查實際執行的核心及版本，再確認伺服器端是否要求 xtls-rprx-vision。若伺服器端要求 Vision，清空 Flow 並不能取代正確設定。更新或切換核心後，請重新啟動核心並再次查看記錄。
Short ID 可以隨便填 16 個字元嗎？
不可以。16 個十六進位字元只是長度上限，相當於 8 位元組；填入的值也必須在伺服器端允許的範圍內。不要填入節點備註、UUID 片段或一般單字，最穩妥的作法是重新匯入提供方給的完整連結。
已選好節點，瀏覽器卻沒有透過代理連線？
先確認「系統代理」是否已設定，再檢查瀏覽器是否使用系統代理，以及目標網域的路由規則。若本機 HTTP 代理監聽連接埠設為 10808，手動設定瀏覽器時也必須指定相同連接埠；同時查看記錄中是否出現該次請求。
同一份設定在兩台裝置上的表現不同，該怎麼辦？
比對核心版本、裝置系統時間和實際網路。握手驗證可能受時間偏差影響，建議先啟用系統自動校時。接著在相同網路下重新測試，避免把單一裝置的網路阻擋誤判為 UUID 或公鑰錯誤。
設定順序：先連線，再確認最佳化效果
REALITY 和 Vision 分別作用於握手機制與資料處理流程。設定時先確保驗證參數相符，再確認應用程式請求確實經由代理，最後才比較效能。如此一來，就能分別處理握手失敗、路由分流問題和頻寬瓶頸，不必在一次排查中同時修改十幾個欄位。
- 完整匯入：保留提供方給的位址、身分識別和握手參數，避免從截圖拼湊資訊。
- 確認核心：使用支援此組合的 Xray 核心；若欄位無法識別，先檢查版本。
- 確認連線路徑：檢查系統代理、本機監聽和路由設定，確認目標請求確實經由該節點。
- 記錄比較結果：以相同目標、相近時段和多輪測試判斷效益，別把延遲數值當成下載速度。
若想了解訂閱匯入和系統代理的基本操作，可繼續閱讀使用說明；若要分辨協定、傳輸方式與路由規則，請參閱進階手冊的協定說明。理解這些差異，比只看節點名稱選擇「更新的協定」更有助於穩定設定。