協定與線路技術參考

選型導讀

本頁是 NZVPN 的協定與線路技術參考，面向正在選擇訂閱方案、或已經訂閱但想了解背後原理的使用者。相比教學頁 setup.html 的「跟著做就能完成」主線，本頁更偏向系統查閱：每章可以獨立閱讀，也可以按目錄跳轉到關心的議題。

在開始之前，先明確兩個基本維度。協定（Protocol）決定了資料如何被封裝、加密和傳輸；線路拓撲（Topology）決定了資料物理上走哪條路徑。兩者共同決定了連線的建立速度、傳輸速率、穩定性和行動裝置耗電量。很多使用者遇到「連不上」「速度慢」「看 4K 卡頓」的問題，根源往往不在服務本身，而在協定與線路的搭配沒有針對目前網路環境做最佳化。

協定層解決的是「資料以什麼形式過網」的問題。傳統 TCP 代理在弱網下容易因為握手重傳而拖慢速度，而基於 UDP 的協定則能在高丟包環境裡保持更平穩的傳輸。線路層解決的是「資料走哪條路」的問題。同樣一個新加坡節點，走直連、中轉還是 IEPL 專線，延遲與穩定性可能相差數倍。理解這兩層，才能在看線路列表時做出有效判斷。

NZVPN 的訂閱服務涵蓋 120+ 國家 / 220+ 線路，支援 Windows、macOS、iOS、Android、Linux 五大平台，不限裝置台數。訂閱採月付 ¥9.9 起（60GB 流量）的三檔方案，另有永久不過期的流量包可選，並提供 30 天無理由退款。本文所有關於本服務的描述均與上述事實一致，不引入任何未經證實的資料。

需要說明的是，本頁不討論任何網路管制話題，也不提供具體的節點設定命令。協定與線路是服務商在後台已經設定好的基礎設施，使用者端能做的選擇集中在訂閱方案與客戶端設定上。但了解原理有助於判斷：為什麼某些協定在某些網路環境下更快，為什麼專線線路值得更高的月費，以及當連線出現問題時應該檢查哪個環節。

本頁按「協定 → 對比 → 拓撲 → 場景」的順序組織。前五章逐一介紹六種協定，第六章給出橫向對比表，第七章討論線路拓撲，第八章解釋丟包與壅塞的成因，第九章按使用場景給出選型建議。你可以從頭讀到尾，也可以直接跳到最關心的章節。

Shadowsocks：輕量代理協定的取捨

Shadowsocks（簡稱 SS）是目前使用最廣泛的輕量代理協定之一。它的設計目標非常明確：在不可靠的網路環境下，以盡可能低的資源開銷建立一條加密隧道。SS 的加密方式基於 AEAD（認證加密）串流密碼，常見的組合包括 AES-256-GCM 和 ChaCha20-Poly1305。前者在主流 CPU 上有硬體加速，後者在行動裝置 ARM 處理器上表現更好。

SS 的傳輸層預設走 TCP，資料被封裝成標準的 SOCKS5 代理流量。正因為它在協定層面上「看起來像普通代理」，所以部署非常輕量，不需要額外的握手與身分驗證開銷。連線建立時，客戶端與伺服器之間只需要一次 TCP 握手加一次加密握手，整個過程通常在幾十到幾百毫秒內完成。對於網頁瀏覽、即時通訊這類短連線場景，SS 的響應速度非常理想。

SS 的侷限也很明顯。首先是單埠多使用者能力較弱：早期的 SS 一個埠只能服務一個使用者，後來的實作雖然支援多使用者，但需要在伺服器端維護使用者表，遇到大規模併發時會增加管理複雜度。其次是協定特徵相對固定，某些深度封包檢測（DPI）系統可以透過分析流量統計特徵來識別 SS 流量，儘管這需要一定的運算資源。對於普通使用者來說，SS 仍然是最「順滑」的選擇——客戶端生態成熟、設定簡單、資源佔用低。

在行動裝置上，SS 的電量表現值得單獨說明。由於 SS 基於 TCP，系統可以進入低功耗模式，不需要像 UDP 協定那樣頻繁喚醒無線電模組。在 iOS 和 Android 上，SS 的背景保活相對容易，長時間掛機不會顯著增加耗電。對於主要用手機刷社群媒體、看網頁的使用者，SS 是省電的首選。

在實際使用中，SS 適合以下場景：輕度至中度跨境存取、行動裝置長時間掛機、對連線建立速度敏感的應用（如即時通訊）、以及網路環境相對穩定的情況。如果網路丟包率較高，SS 的 TCP 重傳機制會導致明顯的速度下降，這時更推薦後面要講的基於 QUIC 的協定。

NZVPN 的線路列表中，大多數普通線路預設採用 SS 或相容 SS 的傳輸方式。這些線路適合日常使用，配合中轉拓撲可以在晚高峰保持基本穩定。如果你追求更極致的速度表現，可以在客戶端中切換到其他協定，或在套餐頁選擇包含專線線路的方案。

VMess 與 VLESS：完整協定框架的演進

VMess 是 V2Ray 家族的核心協定，設計上比 SS 更注重「看起來不像已知協定」。VMess 在應用層引入了 UUID 作為使用者識別碼，並在請求頭中加入時間戳記，配合可選的抗重放機制，使得同一份請求在網路上不會被輕易重放或識別。VMess 的加密同樣基於 AEAD，但它在中繼資料（如目標位址、埠）上也做了加密，不像 SS 那樣把目標位址暴露在明文頭部。

VMess 的代價是連線建立速度相對較慢。每次連線都需要完成一次「客戶端發起 → 伺服器端驗證 UUID → 返回響應」的握手流程，在弱網下這個流程可能被重傳拖長。此外，VMess 的頭部帶有固定前綴，這個特徵在 DPI 系統中可以被識別。為了規避這一點，後來的實作引入了 mKCP、WebSocket、gRPC 等傳輸層變體，把 VMess 流量偽裝成 WebSocket 或 gRPC 流量。

VLESS 是 VMess 的繼任者，它的核心改進是去掉了 VMess 中冗餘的加密層。VLESS 本身不加密資料，只負責傳輸中繼資料，真正的加密由傳輸層（如 TLS）完成。這樣做的好處是連線建立速度明顯提升——不需要先做一次應用層加密握手，直接透過 TLS 建立安全通道即可。VLESS 保留了 UUID 使用者識別碼和抗重放能力，並增加了對 XTLS 等新傳輸特性的支援。

在資源佔用方面，VLESS 比 VMess 更輕量。由於省去了一層應用層加密，CPU 佔用率下降，這在低階裝置或行動裝置上尤為明顯。VLESS 配合 TLS + WebSocket 或 gRPC 傳輸時，流量特徵與正常的 HTTPS 網站存取幾乎無法區分，適合對流量特徵敏感的環境。

需要說明的是，VLESS 本身不加密資料，因此必須搭配 TLS 使用才安全。NZVPN 的客戶端在設定 VLESS 線路時，會預設啟用 TLS 加密，使用者無需手動干預。VLESS 與 CDN 的配合也更好：因為 VLESS 的握手過程簡潔，CDN 回源時不容易因為逾時而斷線。

從選型角度看，VMess 適合對相容性要求較高的舊客戶端，或需要 mKCP 等特殊傳輸的場景；VLESS 則更適合追求連線速度和現代傳輸特性的使用者。兩者在 NZVPN 的線路中都有部署，客戶端會根據線路設定自動選擇合適的協定，普通使用者不需要手動區分。

Trojan：偽裝成正常 HTTPS 流量

Trojan 的設計思路與 SS、VMess 都不同。它的核心思想是「讓流量看起來與普通的 HTTPS 網站存取完全一致」。Trojan 在 TLS 隧道之上疊加了一層自訂協定，客戶端與伺服器端之間先完成一次完整的 TLS 握手，然後透過一個類似 HTTP 的頭部來傳遞實際請求。從網路流量上看，Trojan 連線與瀏覽器存取一個啟用了 HTTPS 的網站幾乎無法區分。

正因為這種偽裝特性，Trojan 在需要「看起來像普通存取」的場景下非常有效。它的連線建立過程與普通 HTTPS 相同：一次 TCP 握手加一次 TLS 握手，之後才開始傳輸資料。這個流程比 VMess 少了一層應用層握手，所以連線建立速度與 VLESS 相當，但比 SS 略慢（因為 TLS 握手本身需要 1~2 個 RTT）。

Trojan 的加密完全依賴 TLS，因此對憑證管理有較高要求。伺服器端必須持有有效的 TLS 憑證，否則連線會在握手階段失敗。NZVPN 的客戶端內建了憑證校驗邏輯，當線路設定了 Trojan 協定時，會自動完成憑證驗證，使用者只需要在訂閱匯入時選擇對應的線路即可。如果憑證過期或網域變更，客戶端會提示連線失敗，此時重新取得訂閱連結即可更新。

在資源佔用方面，Trojan 的開銷主要來自 TLS 加解密。現代 CPU 都有 AES-NI 等硬體加速指令，所以 TLS 加解密的 CPU 佔用率並不高。在行動裝置上，Trojan 的電量表現與 VLESS 接近，因為兩者的傳輸層都是 TCP，系統可以正常進入低功耗模式。但需要提醒的是，如果網路丟包嚴重，Trojan 的 TCP 重傳同樣會拖慢速度，這是所有 TCP 協定的共性。

Trojan 的適用場景：需要穩定通過複雜網路環境、希望流量特徵盡量不顯眼、以及需要與 CDN 配合做網域分流的使用者。Trojan 與 TLS + WebSocket 的組合可以很好地相容 CDN，讓流量從 CDN 節點回源到真實伺服器，進一步隱藏後端位置。

在 NZVPN 的線路體系中，Trojan 通常部署在專線或高品質中轉線路上。因為 Trojan 的偽裝特性需要穩定的 TLS 連線，如果線路本身品質差，頻繁的 TLS 重連反而會降低體驗。對於追求「連上就能用、不折騰」的使用者，Trojan 線路是省心的選擇。

Hysteria2 與 TUIC：基於 QUIC 的新一代協定

Hysteria2 和 TUIC 都是基於 QUIC（Quick UDP Internet Connections）的代理協定。QUIC 是 Google 主導開發的傳輸層協定，底層使用 UDP，但內建了 TCP 的可靠傳輸、壅塞控制和多路復用能力。與 TCP 相比，QUIC 最大的優勢是連線建立快——它把 TLS 握手合併進了傳輸握手，通常只需要 1 個 RTT 就能建立加密連線。

Hysteria2 的獨特之處在於它使用了名為 Brutal 的壅塞控制演算法。傳統 TCP 壅塞控制（CUBIC、BBR 等）在偵測到丟包時會主動降低傳送速率，這在有丟包的網路裡會導致頻寬使用率下降。Brutal 則相反：它允許使用者設定一個目標速率，然後持續以這個速率傳送資料，不因丟包而退縮。這在高丟包、高延遲的鏈路上非常有效，可以讓視訊串流、大檔案下載保持穩定速度。

TUIC 的設計更偏向「簡潔」。它同樣基於 QUIC，但取消了伺服器端的使用者表，改用類似 VLESS 的 UUID 識別碼。TUIC 的連線建立速度與 Hysteria2 相當，但它的壅塞控制演算法更接近標準 QUIC 的預設實作，因此在極端高丟包環境下，速度表現不如 Hysteria2 激進。不過，TUIC 的資源佔用更低，在低階裝置上執行更流暢。

行動裝置電量是選擇 QUIC 協定時最需要權衡的因素。QUIC 基於 UDP，而 UDP 在行動網路下需要更頻繁地喚醒無線電模組，以維持 NAT 對映和連線狀態。這意味著在同等使用時長下，QUIC 協定的電量消耗通常比 TCP 協定高 10%~20%。不過，QUIC 的快速重連能力也意味著網路切換時能更快恢復，減少了「重新連線」帶來的額外耗電。

Hysteria2 和 TUIC 適合以下場景：行動網路（4G/5G）下高丟包環境、需要看 4K 串流媒體或進行視訊會議、以及網路頻繁切換（如地鐵、高鐵）的情況。在丟包率超過 5% 的鏈路上，基於 QUIC 的協定往往比 TCP 協定快 2~3 倍。

NZVPN 的客戶端對 Hysteria2 和 TUIC 做了全面支援。在訂閱匯入時，如果選擇了支援 QUIC 的線路，客戶端會自動設定對應的埠與傳輸參數。需要注意的是，某些老舊網路裝置（如部分企業防火牆）可能禁止 UDP 流量，這種情況下 QUIC 協定無法運作，需要回退到 TCP 協定。

連線建立速度與資源佔用橫向對比

把六種協定放在同一張表裡，可以更直觀地看出它們的設計取捨。需要說明的是，下表的資料是基於典型網路環境（丟包率 1%~3%、RTT 40~80ms）的經驗值，實際表現會因線路品質、裝置效能、網路壅塞程度而有所不同。

從表格中可以提煉出幾條選型規律。第一，如果你的網路環境穩定（家庭寬頻、辦公網路），TCP 協定（SS、VLESS、Trojan）已經足夠，它們省電且相容性好。第二，如果你經常在行動網路下使用，或者所處網路丟包率偏高，基於 QUIC 的協定（特別是 Hysteria2）能顯著提升速度體驗。第三，如果你對流量特徵有顧慮，Trojan 和 VLESS 是更穩妥的選擇。

資源佔用方面，SS 和 VLESS 的 CPU 佔用率最低，因為它們省去了額外的加密層。VMess 因為多了一層應用層加密，CPU 佔用略高。Hysteria2 和 TUIC 的 CPU 佔用取決於 QUIC 的實作品質——TUIC 的程式碼更精簡，在低階裝置上更有優勢。

連線建立速度是很多人忽略的指標。短連線場景（網頁瀏覽、API 呼叫）對連線建立延遲非常敏感，每多一次 RTT 都會讓使用者感知到「卡一下」。QUIC 協定把 TLS 握手合併到傳輸握手，將連線建立壓縮到 1 個 RTT，這是它在行動裝置體驗上的一大優勢。而 VMess 因為需要額外的應用層握手，在弱網下連線建立可能超過 1 秒。

需要注意的是，協定的橫向對比不能脫離線路品質單獨看。一條高品質的 IEPL 專線配合普通 TCP 協定，可能比一條劣質中轉線路配合 QUIC 協定更穩定。協定解決的是「資料怎麼傳」，線路解決的是「資料走哪條路」，兩者需要結合評估。

線路拓撲：直連、中轉與專線

線路拓撲決定了資料從使用者裝置到目標伺服器之間經過多少跳、走哪條實體路徑。常見的拓撲有三種：直連、中轉和專線。理解它們的差異，是判斷一條線路「值不值」的關鍵。

直連（Direct）

直連意味著使用者裝置與目標節點之間沒有中間轉發伺服器，資料直接透過公網路由到達節點。直連的優點是延遲低——路徑最短，沒有額外的跳數開銷。但缺點是穩定性完全取決於公網路由品質。晚高峰時，公網國際出口頻寬緊張，直連線路可能出現明顯的丟包和抖動。此外，直連線路在跨營運商（如行動存取聯通出口）時，路由可能繞路，導致實際延遲遠高於理論值。

中轉（Relay）

中轉線路在使用者與目標節點之間插入一台或多台轉發伺服器。這些轉發伺服器通常部署在骨幹網或國際出口的關鍵位置，能夠最佳化路由路徑、規避壅塞路段。中轉的優點是穩定性好：即使公網某段出現壅塞，中轉伺服器也能透過備用路由繞行，保證連線不斷。代價是延遲增加——每經過一跳，大約會增加 5~15ms 的延遲，具體取決於實體距離。

中轉又分為「普通中轉」和「智慧中轉」。普通中轉固定走某一台轉發伺服器，路徑相對固定；智慧中轉會根據即時網路狀況動態選擇最優路徑，類似 BGP 選路。NZVPN 的中轉線路普遍採用智慧選路，在晚高峰時會自動切換到延遲更低的路徑。

專線（IEPL）

IEPL（International Ethernet Private Line）是營運商提供的點對點專線服務，實體上獨享頻寬，不走公網。專線的延遲極低（通常比公網直連低 20~40%），而且幾乎沒有丟包——因為整條鏈路是獨享的，不會受到其他使用者流量影響。專線的缺點是價格昂貴，因此通常只部署在少數熱門節點上。

三種拓撲的選擇邏輯可以概括為：追求極致速度選專線，追求穩定選中轉，追求低延遲且網路環境好選直連。NZVPN 的線路列表中，每條線路都會標註類型標籤——IEPL 專線、中轉、直連。在客戶端中，你也可以按線路類型篩選。

NZVPN 的 220+ 線路中，專線、中轉和直連按比例搭配，涵蓋 120+ 國家。熱門地區（香港、新加坡、美國）通常同時提供三種拓撲，使用者可以根據使用場景選擇。比如，看 Netflix 建議選專線，日常瀏覽選中轉，玩遊戲選直連。

丟包與晚高峰壅塞的成因與應對

丟包是跨境網路中最常見的效能殺手。理解丟包的成因，才能判斷一條線路是否值得長期使用。丟包的原因大致可以分為三類：實體鏈路損耗、路由器佇列溢位、以及路由繞路。

實體鏈路損耗

海底光纜、陸上光纜在長距離傳輸中會產生訊號衰減，電訊號或光訊號經過中繼器時可能出現誤碼。誤碼率在正常範圍內時，由鏈路層的糾錯機制處理，不會影響上層協定。但當鏈路老化或受天氣影響時，誤碼率上升，超出糾錯能力的資料封包會被直接丟棄。這類丟包通常是持續性的，表現為某條線路長期不穩定。

路由器佇列溢位

這是晚高峰丟包的最主要原因。網際網路上的路由器都有緩衝區（佇列），當某個方向的流量超過鏈路頻寬時，資料封包會在佇列中排隊等待轉發。如果佇列滿了，新到達的資料封包就會被丟棄。晚高峰時，國際出口頻寬被大量使用者共享，佇列溢位機率顯著上升，導致丟包率從平峰的 0.1% 飆升至 3%~10%。

壅塞控制演算法的作用就是讓傳送端感知到網路壅塞，並主動降低傳送速率，避免持續丟包。TCP 的 CUBIC 演算法會在丟包後把壅塞視窗減半，這雖然緩解了壅塞，但也導致吞吐量驟降。BBR 演算法透過測量瓶頸頻寬和最小 RTT 來動態調速，在丟包環境下能保持更高的吞吐量。QUIC 預設採用類似 BBR 的壅塞控制，因此在高丟包環境下表現更好。

路由繞路

路由繞路不是丟包，但會間接導致丟包。當公網路由因為故障或壅塞而切換到一條更長的路徑時，RTT 顯著增加，資料封包在佇列中停留的時間變長，更容易觸發逾時重傳。逾時重傳會進一步加劇壅塞，形成惡性循環。中轉線路的一個核心價值就是規避繞路：透過骨幹網上的轉發節點，把路徑「拉直」，減少不必要的跳數。

應對晚高峰壅塞，使用者端能做的選擇有限，但仍有幾個有效策略。第一，優先選擇 IEPL 專線線路——專線獨享頻寬，不受公網壅塞影響。第二，在客戶端中啟用基於 QUIC 的協定（Hysteria2/TUIC），它們對丟包的容忍度更高。第三，避開最繁忙的時間段（通常為當地晚間 20:00~23:00），或切換到負載較低的節點。

NZVPN 的線路列表會即時顯示每條線路的延遲與頻寬。如果某條線路在晚高峰持續出現高延遲或低頻寬，可以嘗試切換同地區的其他線路。客戶端內建的自動選線功能也會在連線品質下降時提示使用者切換。

按使用場景選協定與線路

最後，把協定與拓撲的討論落到具體場景。不同用途對網路特性的側重不同，選型時應該優先滿足最核心的需求。

上表的推薦不是絕對的，實際使用中還需要結合具體線路的即時狀態。比如，一條直連線路在晚高峰可能比中轉線路更慢，此時就應該臨時切換到中轉線路。NZVPN 客戶端支援按協定和線路類型篩選，使用者可以根據當時的網路狀況靈活調整。

對於大多數使用者，一個實用的策略是：預設使用 VLESS + 中轉線路，這套組合在穩定性和速度之間取得了較好的平衡。如果發現某條線路在晚高峰速度下降明顯，切換到 Hysteria2 或專線線路。如果裝置電池續航緊張，改用 Shadowsocks 以節省電量。

關於訂閱方案，如果你經常看 4K 串流媒體或使用 AI 工具，建議選擇 250GB 或 500GB 的月訂閱檔位，流量更充裕；如果只是日常瀏覽，60GB 的基礎檔已經足夠。流量包適合用量波動大的使用者，購買後永久不過期，可以按需補充。

最後，無論選擇哪種協定與線路，30 天無理由退款都提供了試錯空間。你可以先訂閱一個月，在實際網路環境中測試不同線路的表現，再決定長期使用哪個方案。