協定與線路技術參考

了解架構

先釐清協定、傳輸與線路

協定名稱說明什麼

討論連線品質時，常有人把「協定」、「節點」和「網路」混為一談，排查時便容易找錯方向。協定主要規範用戶端與伺服器如何建立工作階段、表示目標位址及封裝資料。Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 都可用於代理連線，但握手方式、所依賴的傳輸機制及用戶端支援情況各不相同。協定不是實體線路：即使更換協定，資料仍可能經過相同的本地網路和遠端出口。

傳輸層則說明資料如何在網路上傳送。常見的基礎傳輸方式是 TCP 或 UDP；TLS、QUIC 等機制則會在其上負責加密、工作階段管理或多路傳輸。有些協定名稱指的是相對明確的組合，有些則必須搭配特定傳輸選項，才能完整描述連線。尤其是 VLESS，單說「使用 VLESS」不足以推斷實際連線方式，還得看它採用哪種傳輸。比較協定時，應一併列出這些條件，而不是從名稱直接推論速度。

線路決定資料經過的路徑

線路是裝置連到入口，再到出口的實際路徑。直連、中轉和專線描述的是路徑的組織方式，不是另一種協定。同一協定用在不同地區、不同入口或不同出口，連至目標網站的體驗都可能不同。距離會影響傳播時間，電信業者之間的互連會影響路徑是否繞行，出口所在區域也會影響目標服務判定的存取位置。因此，即使「節點名稱相近」，也不代表兩條連線經過同一段網路。

實用的拆解方式是依序記錄：裝置所在網路、用戶端選用的協定與傳輸方式、入口地區、線路類型、出口地區，以及正在存取的目標。如此一來，網頁開啟緩慢時，就能先確認問題出在建立連線、持續傳輸，還是目標服務本身的回應階段。如果用戶端連入口都無法建立工作階段，請優先檢查帳戶狀態、用戶端設定和入口是否可連；如果已順利連線，只有特定網站反應遲緩，則應留意出口地區與目標網站之間的路徑。

選型時先確定用途與出口地區，再比較線路類型，最後才調整協定。每次只更動一個條件，才能判斷差異是由哪個步驟造成。

「連線成功」也只是起點。用戶端顯示已連線，代表它與所選入口完成必要的協商，不表示目標網站一定能正常回應。目標服務可能有自己的地區判定、帳戶規則和服務狀態；本地瀏覽器快取、系統代理範圍與應用程式內部的連線策略，也會影響實際狀況。驗證連線時，先確認出口資訊，再開啟真正要使用的服務，並留意是否只有某一類請求失敗。不要只憑單一頁面的載入結果，就判定整條線路的表現。

本手冊後續會依相同架構展開：先看協定如何處理工作階段，再看 TCP 與 UDP 的行為；接著討論線路拓樸和尖峰時段壅塞，最後回到實際使用情境。初學者可搭配閱讀依情境挑選線路指南。該文著重快速判斷，本頁則說明判斷背後的原因，方便在網路環境變動時重新選擇。

協定介紹

Shadowsocks 與 VMess：封裝方式的取捨

Shadowsocks：協定層較精簡

Shadowsocks 的核心概念是讓用戶端將前往目標的請求交由代理伺服器處理，並以相應的加密方式保護用戶端與伺服器之間的資料。它的設定概念相對直接：連線目標、驗證資料和加密方式都必須與伺服器相符。現代用戶端應以伺服器實際提供的安全設定為準；不要為了看似降低負擔，就擅自改用舊式或不相符的選項。設定不一致時，可能會發生握手失敗、請求逾時，或顯示已連線卻無法正常存取。

協定層較精簡通常有助於釐清故障範圍，但不代表所有 Shadowsocks 連線都很輕量。用戶端實作、加密運算、裝置硬體和網路路徑都會影響資源使用情況。瀏覽網頁和使用一般應用程式時，應先確認用戶端能否穩定維持工作階段，再觀察線路連往目標地區的表現。如果某個應用程式需要大量平行連線，用戶端如何管理這些連線也很重要；只憑協定名稱就認定「省資源」或「適用所有應用程式」，容易忽略實作差異。

VMess：將工作階段納入協定設計

VMess 對工作階段建立和資料表示有自己的協定設計。部署時，除了驗證資訊，用戶端與伺服器的傳輸設定也必須一致。這提供更多組合彈性，也增加了排查時可能遇到的分支：名稱同為 VMess 的線路，實際承載連線的傳輸方式可能不同。比較兩條 VMess 線路時，如果入口、傳輸和出口都不相同，就無法將體驗差異單獨歸因於 VMess 本身。

裝置資源吃緊或網路頻繁切換時，連線如何重新建立，比協定標籤更值得留意。例如裝置從一種網路切換到另一種網路，原有工作階段可能中斷，用戶端需要重新連線，應用程式也可能重試請求。若這時只看到頁面一直轉圈，應先確認用戶端是否已重新建立工作階段，而不是立刻反覆切換出口。頻繁操作會讓短暫的網路切換和設定錯誤混在一起。

這張表是排查起點，不是效能排名。兩種協定都必須透過實際線路連到目標服務。如果某條連線在離峰時順暢、忙碌時變慢，請優先確認是否為共用路徑壅塞；如果無論何時都無法建立工作階段，則應先檢查設定和用戶端相容性。將問題分成「無法建立連線」、「連線後沒有回應」和「持續傳輸不穩」來記錄，會比一次更改多個協定選項有效。

伺服器未明確提供的協定，不建議自行拼湊用戶端參數。請從使用者面板取得目前可用的訂閱資訊和用戶端資料，再依實際顯示的選項操作；若用戶端不支援某項設定，也不要只因其他用戶端有同名按鈕，就推斷其行為相同。協定知識是為了協助理解選擇，不是用來取代伺服器提供的連線參數。

協定介紹

Trojan 與 VLESS：釐清握手與傳輸組合

Trojan：留意 TLS 工作階段

Trojan 通常以 TLS 連線安排用戶端與伺服器之間的通訊。TLS 不只是設定表上的一個開關；網域、憑證驗證和伺服器設定都必須互相配合。若連線在建立階段失敗，應先核對這些項目，再判斷線路是否壅塞。略過驗證或任意更換網域，或許能讓表面上的故障消失，卻也會改變原有的連線信任界線。可使用哪些選項，請以伺服器提供的設定為準。

TLS 握手會參與建立連線，因此比較使用體驗時，應區分首次建立連線與連線建立後的資料傳輸。網頁第一次開啟較慢，不一定代表整段持續傳輸都很慢；反過來說，握手很快也不代表之後播放影片一定流暢。瀏覽器通常會重複使用連線，各應用程式的請求方式也不盡相同。觀察時最好固定目標和操作順序，記錄是第一次開啟較慢、切換頁面時較慢，還是維持連線後仍頻繁停頓。

VLESS：協定本身不等於完整路徑

VLESS 負責代理工作階段中的身分和目標表示，傳輸層的選擇則必須另外說明。看到 VLESS 線路時，應進一步確認它使用哪種傳輸、如何建立安全連線，以及用戶端是否支援相應組合。若把「VLESS」直接等同於某種固定傳輸方式，設定核對就容易失焦：協定欄位即使完全正確，其他欄位不相符，仍然無法連線。尤其在不同用戶端之間移轉訂閱時，應逐項確認匯入結果，而不是只看清單裡有沒有出現線路名稱。

有些用戶端將協定、傳輸和安全設定分散在不同選單；有些則只顯示一行摘要。介面不同，不會改變底層設定必須相符的事實。如果匯入成功卻無法連線，先查看線路詳細資訊是否完整，再檢查系統時間、目前網路和目標入口是否可連。不要因選項名稱相似，就自行將一種傳輸改成另一種。用戶端與伺服器之間的協商，不能只求「差不多」。

TLS 相關故障先檢查網域與驗證設定；VLESS 相關故障則分別核對協定和承載它的傳輸方式。兩者都不能脫離入口與出口線路單獨評價。

從資源使用來看，TLS 與傳輸層的實作會消耗運算和連線管理資源，但不代表某種協定在所有裝置上都比較耗電。裝置的加密支援、用戶端背景執行策略、網路訊號品質和應用程式請求頻率，都會影響實際結果。網路不穩時反覆重新連線，比穩定維持連線更可能讓裝置持續喚醒。對行動裝置而言，先找到能穩定維持連線的組合，再比較細微的協定負擔，通常更符合實際使用情況。

如果要使用受地區因素影響的服務，協定只負責將請求送到出口，不能取代出口選擇。服務可能會綜合出口位置、帳戶紀錄和自身規則判斷存取環境。請先前往全球節點查看地區與線路類型，再依用戶端實際支援的連線方式選擇協定。將地區因素和協定因素分開考量，既能減少無效切換，也能避免把目標服務的回應問題誤認為「協定失效」。

協定介紹

Hysteria2 與 TUIC：了解 UDP 路徑上的變化

為什麼要談 QUIC

Hysteria2 與 TUIC 都和以 UDP 為基礎的 QUIC 傳輸密切相關。QUIC 將安全工作階段與傳輸控制結合，管理連線及並行資料流的方式也不同於傳統 TCP。因此討論這類協定時，不能只問「頻寬夠不夠」，還要確認目前網路能否穩定傳送 UDP 封包。如果本地網路、上游路徑或目標入口對 UDP 的處理不理想，協定設計上的優勢就未必能反映在實際連線中。

UDP 本身不像 TCP 那樣，會為應用程式提供可靠且依序傳送的位元組流；QUIC 則在自身層級處理相應的確認和重傳。因此，看到「以 UDP 為基礎」不能推論它不會遺失封包，也不能認為所有封包遺失都能自動化解且毫無代價。缺失的資料仍可能需要重新傳送，路徑波動仍會造成等待。實際表現取決於協定實作、用戶端、伺服器和經過的網路。

兩種實作都應以實際連線狀況為準

Hysteria2 與 TUIC 的設定和壅塞控制方式並不相同，不能把它們當成只是名稱不同的同一項設定。對使用者而言，更重要的是確認用戶端和伺服器是否支援相應協定與設定，再觀察連線是否穩定、持續傳輸時有無停頓，以及切換網路後能否正常恢復。某種協定在一種網路環境下表現良好，不代表在其他網路中也會有相同結果。

排查這類連線時，可先查看用戶端提供的連線狀態，確認是否已完成握手。如果一直卡在連線建立階段，請檢查目前網路對 UDP 路徑的實際支援情況，並以伺服器提供的其他可選線路作比較；如果可以連線，但持續傳輸時波動明顯，則應著重檢查線路是否有封包遺失，以及入口到出口之間是否壅塞。比較測試時，出口地區和使用情境應盡量保持一致，否則更換協定的同時也改變了地理路徑，無法得出有意義的結論。

在行動裝置上切換網路，也會改變裝置與入口之間的位址和路徑。應用程式可能繼續等待舊連線，也可能主動重新建立連線。這時先讓用戶端完成重新連線，確認出口資訊已更新，再判斷應用程式是否需要重新送出請求。連續按下連線開關只會增加尚未完成的連線嘗試，讓原本的故障更難判斷。如果某種網路環境下的 UDP 路徑一直不穩，改用服務實際提供的其他連線方式，比執著於協定名稱更實際。

不論是播放影片、傳輸檔案或使用互動式應用程式，都沒有一份只憑 Hysteria2 或 TUIC 名稱就能成立的通用排名。影片著重持續傳輸量和播放是否停頓；互動式應用程式更在意回應波動；檔案傳輸還會受到伺服器和目標網站處理能力影響。先依實際用途選擇觀察指標，再考慮協定，才能避免用一次下載測試取代所有情境的判斷。

裝置與用戶端

連線建立、資源使用與行動裝置耗電

把「速度」拆成不同階段

連線建立速度、網頁首次回應的等待時間，以及連線穩定後的傳輸速度，是不同問題。用戶端首先要解析入口位址並與入口通訊，接著完成協定所需的握手；代理連線建立後，目標服務還得處理自己的連線和請求。任何階段變慢，都可能讓人覺得「開啟很慢」。如果只有首次存取較慢，先檢查是否頻繁重新連線，或目標服務首次回應較遲；如果已建立的連線也持續緩慢，再檢查線路壅塞和目標服務狀態。

協定實作會影響握手過程，但路徑往返時間同樣重要。入口距離較遠，或裝置目前連上的網路不穩，往往會放大任何需要等待對端回應的步驟。不要只憑協定介紹，就推測某條連線實際需要多久才能建立。更好的方式是固定使用同一裝置、同一網路和相近的目標操作，逐一更換服務實際提供的連線選項。記錄問題發生在用戶端連線前、建立連線期間，還是應用程式載入期間，才能將協定因素和地理路徑區分開來。

耗電往往來自反覆喚醒

行動裝置的耗電表現不能簡化成「某種協定比較省電」。持續的網路活動、訊號不穩引發的重傳、頻繁重建工作階段，以及應用程式在背景不斷送出請求，都可能增加裝置喚醒次數。即使協定本身的運算負擔不大，只要入口路徑反覆中斷，用戶端仍得一次又一次重新握手。相反地，連線安排雖然稍複雜，但若能長時間穩定維持，在日常實際使用中未必比較耗電。

比較耗電狀況時，不要一邊播放影片，一邊讓另一組測試裝置閒置。應在相同應用程式、相近網路環境和類似使用方式下觀察趨勢；系統的背景限制和省電策略也應保持一致。耗電統計通常按應用程式分類，但代理用戶端會轉送其他應用程式的資料，因此不應把用戶端顯示的耗電量直接解讀為所有流量都由它自行產生。更有用的線索是：裝置待機時連線是否不斷重建，以及哪些應用程式在背景頻繁送出請求。

VPNZU 支援 Windows / macOS / iOS / Android / Linux，且裝置數不限；但各平台的介面名稱或協定選項不一定完全相同。跨裝置使用時，請先分別在各用戶端確認訂閱是否已更新、線路名稱和設定是否一致，再比較使用狀況。如果一台裝置正常、另一台失敗，應先排查該平台的用戶端和本機網路，而不是立刻判定整個出口故障。用戶端下載位置和訂閱取得方式請參閱使用教學。

資源有限的裝置也要留意同時執行的應用程式。大量頁面同時載入、背景同步和影片播放會共用裝置的運算、記憶體和網路資源。先關閉與測試無關、流量較大的工作，再重新觀察連線；如果恢復正常，問題可能出在本機資源競爭，而非線路容量。記錄測試條件比追求一個孤立的「最快協定」更有價值，因為真正需要解決的是日常使用時的負載。

路徑結構

直連、中轉、專線如何影響穩定性

直連：路徑概念簡單，但不保證最短

直連通常表示裝置連上的入口與最終出口之間，沒有另外安排中轉接入。其架構容易理解，但「直連」不代表實際網路路徑一定較短。封包仍須經過本地電信業者、跨網互連和出口端網路；網路實際選擇的路徑也可能與地圖上的直線不同。對距離較近、互連順暢的地區，直連可以作為合適的起點；若遇到跨網繞行或尖峰時段壅塞，就要評估其他拓樸是否能提供更穩定的路徑。

中轉：增加節點以調整接入路徑

中轉線路會在接入端與最終出口之間安排額外的轉送節點，通常是為了改變裝置通往目標出口的路徑。多一段轉送不代表一定較慢：如果新的入口比較容易連上，後續路徑也更穩定，整體體驗就可能改善。不過中轉也會增加需要維護的環節，其中任何一段壅塞都會影響最終結果。判斷中轉是否合適，應觀察整條路徑的連線建立和持續傳輸狀況，而不是只看「多了一個節點」。

專線：留意接入與交付界線

IEPL 專線描述的是線路組織與承載方式，不是加密協定。專線在可控路徑、容量規劃等方面，與一般互連路徑有不同安排，但實際體驗仍會受本地網路、伺服器處理能力和目標網站影響。看到「專線」標籤，不應推論延遲固定、永不壅塞，或適用於所有目標。需要存取哪個地區，就先確定出口地區，再比較該地區可選線路的拓樸。

可以將路徑想成連續的幾段：裝置到入口、入口到出口、出口到目標。連線建立失敗通常出在前段；只有特定目標較慢，可能與後段有關；所有目標在相近時段都變慢，則值得檢查共用的中間路段。這個架構能減少盲目更換協定的次數。即使用戶端顯示相同地區，入口與出口的安排也可能不同，因此比較前應仔細查看線路類型說明。

選擇出口時，也要考慮目標服務的地區規則。使用串流影音服務時，不同地區可能提供不同內容；使用 AI 工具時，目標服務也可能依出口位置和帳戶狀況處理請求。線路負責提供連線，不會改變目標服務本身的規則。建議先確認所需地區，再前往全球節點清單查看可選線路；若想建立一套快速判斷順序，可閱讀VPN 線路怎麼選。

VPNZU 的服務範圍為 100+ 個國家 / 160+ 條線路；這表示有不同地區與線路可供選擇，不代表每個地區都同時提供直連、中轉和專線。也不要把地區總數視為特定目標的使用體驗保證。實際選線仍應以節點頁說明和使用者面板提供的選項為準，並在自己的網路環境中完成測試。

故障排查

封包遺失與尖峰時段壅塞：從狀況判斷路徑

封包遺失不只一種原因

封包可能在本地無線連線、裝置到電信業者的接入段、跨網互連、中轉節點，或出口至目標服務的路徑上遺失。應用程式看到的是等待和重試，無法只憑一次頁面停頓判斷封包在哪裡遺失。TCP 連線遇到封包遺失時，會依自身機制重傳並調整傳送節奏；以 QUIC 為基礎的連線也會處理確認和遺失。兩者機制不同，目的都是盡可能維持傳輸，但重新傳送仍會占用時間與容量。

也要區分封包遺失和單純的高延遲。距離較遠但穩定的路徑，互動回應可能偏慢，卻未必頻繁停頓；偶爾遺失封包的路徑，平時回應正常，載入時卻可能突然卡住。持續傳輸還會暴露另一個問題：如果應用程式必須等待遺失的資料，即使後續資料已抵達，也不一定能立即交付。影片緩衝可以吸收部分波動，即時互動對這類波動則更敏感。因此測試時應使用真正要操作的應用程式，而不只是查看連線狀態標籤。

為什麼尖峰時段特別容易感到壅塞

尖峰時段是多位使用者同時增加網路需求的時候，瓶頸可能出現在家用網路接入、電信業者互連、共用中轉、出口或目標服務。當鏈路接近承載上限時，排隊等待時間會增加；佇列處理不及時，也可能造成封包遺失。更換協定有時能改變傳輸對波動的反應方式，卻無法憑空增加已壅塞實體路徑的容量。如果固定時段、多種協定都出現相近的延遲，應先比較入口和線路類型。

排查時可以逐步縮小範圍：先確認不使用代理時，本地網路存取常用服務是否也明顯變慢；再查看同一入口連往不同目標時是否都出問題；接著比較前往同一目標、使用同一出口地區時的其他可選線路。如果只有某個目標異常，也要確認目標服務本身是否正常。記錄這些不同情況，比只說「到處都很慢」更有參考價值，也能避免把應用程式伺服器的問題歸咎於線路。

在同一時段進行比較時，一次只更動一個變數：先換同一地區的線路，再考慮更換協定；不要同時更換網路、地區、用戶端和目標應用程式。

閱讀用戶端紀錄時也要考量前後脈絡。握手逾時指向連線建立階段；連線建立後反覆中斷，則值得檢查本地網路切換和入口穩定性；只有網頁部分資源無法載入，可能與目標網站的個別請求有關。紀錄文字沒有統一標準，不同用戶端可能用不同措辭描述相同情況。若無法判斷，保留故障發生時的操作順序、所選線路名稱和狀況即可，不要在公開場合貼出訂閱內容或驗證資料。

如果問題只出現在某台裝置，可先確認該裝置的系統代理是否涵蓋目標應用程式，並檢查訂閱更新狀態。如果多台裝置連著同一個網路且狀況相似，再考慮網路與入口路徑；若使用不同網路時表現不同，應優先比較本地接入條件。依裝置、網路、地區和應用程式分類觀察結果，比連續隨機嘗試大量線路更容易找出規律。需要回報具體故障時，可透過使用者面板的客服工單入口描述相關狀況。

選型流程

依使用情境選擇，並驗證結果

先選地區，再選路徑

選型應從用途開始。一般瀏覽網頁和處理檔案時，先確認實際要使用的服務位於何處，不必為了線路名稱好看，就選擇與目標無關的遠端出口。串流影音情境先確認需要存取的地區，再觀察播放是否持續流暢；使用 AI 工具時，也要考量目標服務本身的地區與帳戶規則。互動式應用程式則更應留意回應是否穩定，以及路徑波動是否影響實際操作。地區不等於速度，它首先決定請求從哪裡進入目標服務。

確定出口後，再比較直連、中轉和專線。選擇依據是在目前網路環境下，哪條路徑能穩定完成任務，而不是線路標籤的排列順序。如果某條線路能穩定開啟目標服務，持續使用也沒有明顯中斷，就不必只因看到另一種拓樸便頻繁更換。若故障只在特定時段出現，應保留正常與異常時段的狀況紀錄，著重檢查共用路徑壅塞，而不是從頭重設所有用戶端選項。

最後比較用戶端實際提供的協定

協定選擇同時受用戶端支援、伺服器設定和目前網路環境限制。使用 TCP 相關連線時，留意握手是否完成及持續傳輸是否穩定；使用以 UDP 為基礎的連線時，也要確認接入環境能否穩定傳送相應封包。Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 TUIC 都不能脫離傳輸設定、入口和出口獨立排名。面板未提供的協定選項，不必自行拼湊；現有線路的連線參數也不應憑猜測修改。

驗證時可採用固定順序：先確認用戶端狀態與出口地區，再開啟平時使用的目標服務；分別觀察首次載入、後續互動和持續傳輸是否正常；若發生異常，依連線建立、資料傳輸、目標回應三個階段分類。完成一輪觀察後只調整一個條件，再重複相同操作。這種方式看起來不如連續切換多條線路快速，但結論更可靠，也更容易在日後網路狀況改變時再次使用。

需要管理訂閱時，可在價格頁查看月訂閱和流量包的實際計費方式。月訂閱分別為 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB；流量依開通日每月重置，中途升級時的差額會折算為剩餘天數。流量包為 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完為止、永久不過期。VPNZU 支援支付寶 / 微信 / USDT，註冊無需電子郵件地址，只要使用者名稱和密碼即可完成。選擇方案與選擇協定是兩回事：先依用量決定計費方式，再依用途和網路環境選擇線路。

如果常用裝置涵蓋 Windows / macOS / iOS / Android / Linux，可分別確認各用戶端顯示的線路及匯入狀態；VPNZU 不限裝置數，但各平台的設定介面仍需分別核對。訂閱連結的取得和匯入方式請參閱訂閱連結新手指南。若要使用 Netflix 等特定服務，也應分開考量目標服務的地區差異與所選出口；Netflix 線路比較文章有相關說明。

最後保留一份可供查核的結論，而非追求永久適用的協定排名：記下用途、出口地區、線路類型、用戶端顯示的協定、所在網路和觀察到的狀況。線路或本地接入條件改變時，依照相同順序重新驗證即可。選擇服務方面，VPNZU 提供 60 天無理由退款；選擇技術方面，最有用的依據始終是能否在自己的裝置和實際目標上穩定完成任務。