V2Ray 協定
與核心參考

VMess 的驗證與傳輸取捨

VMess 是 Project V 生態系中較早發展的代理協定，設計包含使用者身分、請求封裝與資料保護等機制。由於歷史應用廣泛，許多舊訂閱與部署說明仍以它為基礎。理解 VMess 時，要區分「協定仍可使用」與「舊教學仍適用」這兩件事。早期設定中出現的驗證方式與輔助欄位，可能已不適用目前的核心。選擇時應先確認伺服器實際採用的實作，不能只根據教學年份或節點名稱推斷相容性。

使用者 ID、加密方法與時間

「使用者 ID」通常填入 UUID，用於身分驗證，不是可任意取用的備註名稱。用戶端產生新的 UUID，不會因此自動取得伺服器授權，必須與伺服器的使用者設定相符。「加密方法」同樣有協定上的定義，不能與 TLS 開關混為一談。常見的自動選擇方式會由實作決定合適的方法；手動指定演算法前，應先確認雙方都支援。處理器是否具備對應的硬體加速，也會影響實際成本，單看名稱無法排出穩定的速度名次。

VMess 的驗證包含時間相關檢查，系統時鐘若嚴重偏差，可能導致驗證失敗。排除故障時，先啟用系統時間同步，並確認日期、時間與時區顯示是否合理。時區只影響顯示方式，真正需要準確的是系統時間基準。若只修改介面顯示，卻未修正實際時間，問題仍會存在。尚未檢查時鐘前，不要連續重建訂閱或更換加密方法，以免增加變因，讓錯誤更難重現。

舊分享資訊中常見 alterId。目前常見的 VMess AEAD 設定通常使用零值，或由用戶端依相應方式處理；它不是數值越大就越安全的調整項目。遇到保留舊欄位的訂閱，應確認伺服器是否已採用相應驗證方式，以及用戶端如何解讀該欄位。不要照搬多年前的非零設定。若伺服器說明與匯入結果不一致，應以伺服器實際部署及所用核心文件為準，不要讓雙方各改一項碰運氣。

為什麼 WebSocket 常與 TLS 搭配

VMess 可以透過不同傳輸方式承載。WebSocket 搭配 TLS 常見於需要反向代理的部署：用戶端先完成 TLS 交握，再送出正確的 HTTP 升級請求，最後進入 VMess 工作階段。因此，連接埠可連通不代表路徑正確。WebSocket 的 path 與 Host 必須符合部署要求，反向代理也必須將請求轉送至對應後端。路徑拼錯、結尾斜線不符，或選錯目標網站，都可能造成交握失敗或收到一般網頁回應。

這種組合多了幾層封裝與交握步驟，但不代表每次瀏覽都要重新承擔完整成本。長連線重複使用、連線池、應用程式的存取方式，以及中間代理的逾時設定，都會影響結果。反過來說，直接使用 TCP 的封裝較少，也不代表在所有環境下網頁載入時間都較短。若伺服器位置、連線品質或 DNS 不同，單憑兩種不同部署的結果，無法可靠判斷 VMess 本身的速度。

保留既有部署，還是遷移

若現有 VMess 設定在持續維護的用戶端與伺服器上運作正常，協定名稱較早並不是必須遷移的理由。更值得檢查的是是否仍使用舊驗證方式、設定能否穩定匯入、傳輸參數是否明確，以及伺服器是否持續維護。遷移至 VLESS 時，伺服器必須建立對應的入站並提供新參數，不能只把用戶端下拉選單改成 VLESS。兩種協定的驗證與請求格式不同，沒有只改名稱就能相容的捷徑。

建立新部署時，若目標功能仰賴 Xray 的 VLESS 與 REALITY 組合，可依相應方案設定；若需繼續連線至既有 VMess 服務，應優先維持協定與傳輸一致。遇到「匯入成功但連線失敗」，先比較原始分享內容與編輯視窗中的加密方法、傳輸、安全層及路徑，再查看記錄。其他常見問題可參考常見問題，避免將本機系統代理問題誤判為 VMess 協定不相容。

Trojan 與 Shadowsocks 的差異

Trojan 與 Shadowsocks 是另外兩種常見選擇，但設計重點不同。Trojan 的常見部署以 TLS 連線與密碼驗證為核心，憑證與伺服器名稱是重要設定。Shadowsocks 則透過較精簡的代理轉送與驗證加密機制，形成廣泛的實作，且協定方法有不同世代。比較時，不能把「只需要密碼」理解為安全層完全相同，也不能將所有標示 SS 的節點視為採用相同演算法與功能的協定實作。

Trojan：除了密碼，還有憑證與名稱

在 v2rayN 或 v2rayNG 中新增 Trojan 時，通常需要設定位址、連接埠、密碼與 TLS 相關選項。密碼必須維持原樣，避免輸入法替換其中的符號；備註名稱不參與驗證。伺服器名稱須符合部署要求與憑證驗證方式。位址可以是 IP，而驗證使用網域名稱，但前提是伺服器確實如此部署。若憑證名稱不符，先檢查 SNI 與伺服器憑證，不要歸咎於密碼長度。

Trojan 初次連線通常會經過 TCP 建立連線與 TLS 交握。存取大量短請求時，連線是否重複使用會影響體驗；長時間持續傳輸時，連線吞吐量與伺服器資源則更重要。TLS 是成熟的通用安全基礎設施，但實際表現仍受實作、憑證部署、中間代理與交握恢復影響。不能只因為使用 TLS 就斷言一定較慢，也不能因常見設定欄位較少，就認為排除故障時只需檢查一組密碼。

Shadowsocks：加密方法必須完全相符

Shadowsocks 常見設定包括伺服器、連接埠、密碼與加密方法。較新的 AEAD 方法與早期的串流方法屬於不同世代設計；AEAD 除了加密，也會驗證資料。伺服器指定的方法必須同時受到用戶端與執行核心支援，不能把下拉選單中名稱相近的項目視為等價。方法選錯時，即使密碼正確也無法正常通訊。舊設定可以匯入，只代表用戶端辨識了分享格式，不代表目前的核心仍接受相應演算法。

AEAD 2022 等方法也可能對金鑰格式有明確要求，不能憑一般文字密碼的直覺任意輸入。部分部署採用多使用者金鑰等延伸形式，分享資訊必須完整保留。遇到這類設定時，先確認伺服器使用的方法與用戶端支援範圍，再逐字複製金鑰。若截掉含分隔符號的內容，或讓訂閱轉換工具重新解讀為傳統密碼，都可能改變其含義。金鑰格式是協定條件，不是可自由選擇的顯示格式。

基礎 Shadowsocks 設定中的 TCP 與 UDP 支援，也須搭配用戶端接入方式判斷。伺服器允許 UDP，不代表透過系統 HTTP 代理連入用戶端的程式就能透明轉送 UDP。部分分享連結也包含外掛參數；若本站使用的用戶端與核心未實作該擴充，只保留伺服器與密碼並不等同於完整設定。此時應要求提供雙方都支援的完整方案，而非刪除無法辨識的欄位後繼續使用。

依既有部署選擇，而非看欄位數量

若伺服器已提供妥善維護的 Trojan 設定，且用戶端完整支援其傳輸與 TLS 選項，就沒有必要只為了減少幾個參數而改用另一種協定。若伺服器採用 Shadowsocks，則應優先確認正確的方法與金鑰格式，尤其留意不同世代的差異。兩者都不應透過關閉安全檢查或刪除未知參數來「提高相容性」。保留錯誤提示，比把設定改成不再報錯、但含義已經改變，更有助於排除故障。

實際選擇還須考量管理成本：憑證更新是否有可靠流程、金鑰變更是否會同步至訂閱，以及目標核心是否支援所需擴充。對只需連線至既有服務的新手而言，最重要的是配合現有部署，而不是自行重設協定。若密碼或訂閱內容可能已外洩，應在伺服器端撤銷並重新發送，不能只修改本機備註。用戶端記錄與分享連結也可能包含敏感參數，提交問題前請先移除身分資訊與完整訂閱網址。

連線成本、資源使用與行動裝置耗電

「哪種協定最快」必須先定義測量項目。首次連線要看解析、建立連線與安全交握；網頁體驗還受目標網站、連線重複使用與資源數量影響；持續下載更看重吞吐量、封包遺失與伺服器容量；語音或即時應用則更在意抖動與 UDP 路徑。這些指標可能彼此獨立。用戶端顯示的單一延遲測試，不足以代表所有應用的表現，更不能用不同伺服器的兩個數字推導協定本身的速度差異。

分開看交握成本與持續傳輸

DNS、TCP 建立連線、TLS 或其他安全交握都會增加連線前的等待時間；WebSocket、gRPC 等承載方式也有各自的建立流程。不過，連線重複使用與交握恢復可能減少重複成本，網路重傳則可能放大單次失敗的耗時。對頻繁建立新連線的應用而言，減少不必要的往返可能有幫助；對已維持長連線的資料流來說，初始交握佔總耗時的比例會降低。測試時應保留這項差異，不能用一次長時間下載取代短連線體驗。

CPU 使用量與加密演算法、硬體指令、資料複製及實作最佳化有關。某種演算法在桌面處理器上成本較低，換到不同架構的手機上未必如此。記憶體使用量則受連線數、緩衝區、路由資料、DNS 快取與記錄規模影響，不只由協定決定。發現用戶端資源使用量上升時，先確認是否正在下載規則、保留大量連線或輸出詳細記錄，再判斷是否需要更換協定。

為什麼行動裝置不能只比加密成本

手機耗電的重要來源包括無線模組喚醒、訊號微弱時的重傳、背景連線、頻繁重新連線與其他應用程式活動。協定加密確實會消耗運算資源，但不一定是主要因素。連線穩定、喚醒次數少的組合，可能比理論封裝較精簡、卻不斷重試的組合更省電。行動網路與無線區域網路的耗電條件也不同，不能把不同網路與螢幕亮度下的電量變化直接歸因於 Xray 或 V2Fly。

Android 透過 VPN 介面接入流量時，用戶端也要負責讀取與轉送封包。桌面版 TUN 同樣會增加虛擬網卡、路由與 DNS 的配套處理。這些功能改變的是流量接入範圍與處理路徑，不是伺服器協定的升級方式。若系統代理已涵蓋目標程式，啟用 TUN 未必能提升速度；若目標程式不遵循系統代理，TUN 才可能解決流量接入範圍不足的問題。具體設定方式請參閱v2rayN TUN 模式設定。

Mux、連線保活與 UDP 的實際限制

多路複用會嘗試讓多個邏輯請求共用較少的底層連線，在特定短連線情境下可能減少重複建立連線的成本。但共用連線若遇到壅塞或封包遺失，也可能讓多個請求互相影響。某些協定與流控組合對 Mux 有使用限制，不應預設啟用。保活也有取捨：頻率過高會增加背景活動，間隔過長則可能無法維持部分網路中的閒置連線映射。優先使用相容的預設值，確認遇到具體問題後再調整。

即時應用若使用 UDP，應確認整條路徑都支援，包括本機流量接入、核心轉送、伺服器與目標網路。將 UDP 流量送進代理，不代表抖動一定會降低；伺服器繞路或連線壅塞也可能讓體驗變差。DNS 解析方式會影響目標位址與路由選擇，因此測試時也應保持一致。FakeDNS 涉及網域映射與快取行為，不能當成通用加速功能；相關原理可參閱FakeDNS 適用情境筆記。

比較時每次只變更一項條件，分別記錄啟動、首次請求、持續傳輸與待機表現，重複觀察，不要只保留最好的一次結果。若無法在可控條件下使用同一台伺服器，就將結果描述為「目前兩份設定的體驗差異」，不要進一步推論協定排名。日常使用中，連線穩定、功能完整且容易還原，通常比細微的測試差異更重要；這也是選擇方案時應先確認相容性，再比較效能的原因。

依使用情境選擇協定與核心

選擇方案應從使用限制出發，而非從協定排名開始。先確認裝置平台、伺服器實際提供的組合、需要代理的應用程式類型，以及是否依賴 UDP。接著選擇能完整呈現這些參數的用戶端與核心，最後再比較管理成本與執行表現。沒有伺服器端配合時，使用者通常無法自由更換協定，只能從已提供的設定中選擇。用戶端的協定下拉選單是設定入口，不是能將遠端服務自動轉換成另一種協定的工具。

桌面版與 Android 的入門方式

桌面版優先推薦 v2rayN。先前往安裝套件頁，依作業系統與處理器架構選擇，再確認協定所需的核心。Windows 桌面版與傳統 WPF 版是介面與執行環境的選擇，不代表遠端協定不同；macOS 與 Linux 也要核對架構與系統條件。若系統代理已涵蓋一般瀏覽器的流量，可先不啟用 TUN，以較少變因建立基準，再決定是否擴大接入範圍。

Android 端應依伺服器功能優先選擇 v2rayNG，尤其需要 Xray 相關功能時。若部署明確要求 V2Fly 路徑，且設定位於支援範圍內，可考慮 v2flyNG。首次啟動時須授予系統 VPN 權限，並確認是否有其他 VPN 連線占用相同接入位置。接著檢查背景限制與網路切換狀況。應用程式切換至背景後斷線，不應立即歸因於協定；系統電源管理、背景權限與訊號變化都需要分別檢查。

既有服務、新部署與即時應用

連線至既有服務時，最穩妥的做法是維持原有協定與傳輸，先確認能完整匯入。現有 VMess + WebSocket + TLS 運作正常，就不必只為更換名稱而遷移；既有 Trojan 應優先維護憑證、名稱與密碼；既有 Shadowsocks 則要精確配對方法與金鑰格式。需要 VLESS + REALITY 時，選擇支援完整組合的 Xray 路徑，並依伺服器提供的值填入流控與交握參數，不要挪用其他設定的欄位。

新部署較適合從維護能力反推選擇：是否能管理憑證與名稱、是否需要透過反向代理承載、目標裝置是否都支援相同安全方案，以及訂閱工具能否完整輸出參數。把這些問題列成清單，比追求理論上的傳輸成本更實際。若需要即時語音或其他 UDP 應用，應優先驗證端對端 UDP 與路由，不能只因網頁能開啟就結束測試；應用程式本身的區域、目標線路與伺服器位置也會影響體驗。

以最精簡設定建立可復原的基準

首次驗證時，使用單一伺服器、清楚的路由方案與預設相容設定。先確認核心能啟動，再確認請求進入本機連接埠，接著檢查伺服器交握與目標存取。以下 JSON 僅展示原生設定中 routing 物件的最小規則結構：將私人位址交由名為 direct 的輸出端處理。這不是完整連線設定；使用前必須先有對應標籤的直連輸出端，並檢查現有規則順序。圖形用戶端使用者建議透過路由設定完成相同操作。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

這類規則也說明了協定之外的另一個限制：即使節點未變更，路由仍能決定請求是否經由節點傳送。規則會依實作的比對方式處理，前方較寬泛的條件可能先符合，後方的精確規則就沒有機會生效。實際使用時也要考慮地理資料檔是否可用。不要直接套用範例覆寫整個 routing 物件；應先了解現有規則，再新增明確條件，並分別測試區域網路與目標網路的連線。

發生問題時，根據線索還原設定

核心無法啟動時，檢查設定產生方式與連接埠占用；交握失敗時，檢查身分、安全層與時間；連線已建立但應用程式沒有回應時，檢查本機接入、DNS 與路由。本機監聽衝突可參閱連接埠占用與修改監聽連接埠筆記。每次只修改一項並保留上一個可用狀態；要還原時，先關閉新加入的進階功能，不要把所有協定欄位重新填一次。

最後可將選擇結果整理成一行完整組合：用戶端、核心、代理協定、傳輸、安全層、接入方式與路由方案。更換裝置時便能逐項核對，遇到問題也能清楚描述差異。選擇協定的目標不是讓名稱看起來越複雜越好，而是讓伺服器功能、用戶端實作與實際應用需求相符。建立這份基準後，再依效能章節的方法進行控制變因的比較；日常操作請返回快速入門文件，具體問題則可從常見問題繼續查閱。