協定與線路指南

協定、傳輸與線路的界線

將一次連線拆解為可觀察的環節

開啟網頁時，應用程式會先確認目標位址，再與目標服務建立連線，接著交換要求與回應。使用代理用戶端後，應用程式流量可能先進入本機代理連接埠，也可能由系統虛擬網路介面接管，再依規則轉送至遠端節點。遠端節點負責向目標服務發出後續要求。整個過程包含本機接管、網域名稱解析、代理驗證、線路傳輸及出口連線。任何環節耗時過久，最後都可能呈現為「網頁開啟很慢」，但對應的處理方式並不相同。

協定主要規範用戶端與伺服器如何辨識要求、驗證身分及封裝資料。傳輸方式負責承載這些資料，常見基礎包括 TCP 或 UDP；TLS 與 QUIC 則提供連線安全、可靠傳輸或串流管理等機制。線路則描述資料經過哪些網路與節點。混淆這些概念，便容易困惑於「換了協定還是卡頓」：協定可能已經變更，但跨網路的壅塞路徑與遠端出口並未改變，真正的瓶頸自然仍在。

連線建立慢，不代表持續傳輸也慢

第一次開啟網站時，可能同時需要等待名稱解析、傳輸連線、加密交握及目標網站回應。連線建立後若能重複使用，後續要求便不必重新走完所有流程。因此，第一次開啟頁面稍慢、接著瀏覽正常，較可能是建立連線所需的時間；若開始下載後長時間速度緩慢，則值得進一步檢查可用傳輸量、封包遺失復原及目標端限速。不要以下載進度取代網頁體驗，也別因網頁瞬間開啟，就推斷長時間傳輸一定穩定。

「已連線」通常只表示用戶端通道或代理工作階段已建立，並不代表所有應用程式都已透過代理連線，也不代表目標網站接受目前的出口。某個應用程式無法開啟，可能是分流規則未涵蓋、應用程式採用不同的解析路徑，或目標服務拒絕目前的連線條件。疑難排解時，應先確認用戶端是否收到該應用程式的要求，再判斷要求套用了哪項規則。只是不斷切換節點，容易把設定問題誤認為線路問題。

比較前，先固定比較條件

合理比較應盡量使用相同裝置、網路、目標任務及測試時段，每次只變更一項條件。如果同時從 Wi-Fi 切換到行動網路、從鄰近地區改用遠端地區，再更換協定，便無法判斷究竟是哪項調整產生影響。即使節點名稱相近，採用的入口與出口也可能不同。用戶端顯示的協定標籤只是紀錄的一部分，還應記下地區、線路類型，以及是否使用額外的傳輸封裝。

本頁探討的是各協定家族的一般設計，不代表 VPNLay 的每條線路都支援所有組合。實際支援範圍以控制台與用戶端訂閱為準。VPNLay 提供 120+ 個國家／地區、240+ 條線路；涵蓋範圍僅說明可選項目，不代表每個國家／地區都有相同拓撲，也不保證能連線至每個目標網站。需要查詢地區與類型時，請先查看全球節點，再回到本頁了解各標籤代表的技術意義。

Shadowsocks、VMess 與 Trojan

Shadowsocks：留意加密方式與實作

Shadowsocks 的核心概念是以相對精簡的方式轉送代理流量，並使用選定的加密方式保護用戶端與伺服器之間的資料。它並非某種固定線路，也不能只憑名稱推斷資源使用量。不同協定版本、加密方式及用戶端實作，會影響驗證方式、資料封裝與硬體加速的運用。匯入訂閱時，應完整保留服務提供的參數；若將其他教學中的加密選項套用到現有節點，往往只會造成兩端無法正確通訊。

在裝置支援相應的加密加速、網路路徑也相對穩定時，精簡封裝可能減少部分處理工作，但不能因此斷定它一定比其他方案省電或快速。若用戶端需要額外外掛或傳輸層，整體成本也會改變。使用行動裝置時，尤其要留意用戶端是否長時間維持連線、是否頻繁探測，以及背景網路政策是否限制執行。比較時應檢視完整組合，而非把協定家族當作獨立的效能開關。

VMess：設定完整性比標籤更重要

VMess 具有自己的驗證與資料封裝機制，實際部署時也可能搭配不同的底層傳輸方式。使用者看到相同名稱的節點，連線路徑未必相同：有些會直接建立傳輸連線，有些則會經過額外的應用層承載。增加封裝層可能讓部署方式更靈活，也可能增加交握、緩衝及故障檢查點。分析連線緩慢時，應區分是驗證失敗、底層連線建立失敗，還是外層承載已成功、後續轉送卻停滯。

這類設定通常包含伺服器位址、連接埠、使用者識別碼、傳輸類型及相關安全選項。各欄位彼此相依，不能只確認位址正確。若用戶端匯入後出現不支援欄位或解析警告，應先確認所用核心是否支援訂閱提供的組合，再考慮更新訂閱。隨意刪除看不懂的參數，有時會讓設定看似可以儲存，實際建立連線時卻失敗。訂閱的取得與更新方式，請參閱訂閱連結入門指南。

Trojan：TLS 參與連線建立與驗證

Trojan 通常會透過 TLS 保護的連線傳送驗證資訊與代理要求。TLS 憑證驗證、服務名稱比對及信任鏈狀態，都會直接影響連線能否建立。裝置系統時間不正確、設定中的服務名稱不符，或本機信任環境異常，都可能造成交握失敗。遇到這類錯誤時，應先檢查時間、訂閱與用戶端記錄，不應把關閉憑證驗證當成日常修復方式；略過驗證會改變原有的安全界線。

常見的 TCP 承載方式會依序傳送資料位元組。底層資料遺失時，後續抵達的資料可能必須等待遺失部分復原，應用程式因此感覺到停頓。重複使用連線能減少重複建立的成本，卻也可能讓多項工作受到同一條底層連線的限制。Trojan 這個名稱本身不代表低延遲或高傳輸量。若線路本身封包遺失嚴重，有序且可靠的傳輸機制仍需付出復原成本；更換驗證方式的外觀並不能消除這個過程。

這幾類方案沒有脫離使用環境的固定排名。較穩妥的做法是先確認設定受到支援，再以相同任務觀察連線成功率、首次回應與持續傳輸，並將結論限定在目前的裝置與網路條件下。

VLESS、Hysteria2 與 TUIC

VLESS：驗證層不等於完整安全防護

VLESS 採用較精簡的代理驗證與要求描述，本身不提供完整的資料加密保護，必須搭配外部安全傳輸組合才能建立保護界線。因此，看到 VLESS 名稱時，還要確認搭配了哪些傳輸方式與安全選項。不能因為協定名稱聽起來較新，就忽略憑證驗證與設定來源。組合能否使用，取決於用戶端核心、伺服器設定及訂閱參數是否一致，而非只看用戶端介面能否選取該名稱。

精簡的協定標頭可能降低部分封裝成本，但實際連線時間常受名稱解析、交握及路徑往返時間影響。若外層傳輸需要建立新的安全連線，驗證層減少的工作未必是主要因素。連線重複使用、工作階段復原及用戶端實作也會影響使用感受。評估時應分別記錄冷啟動與連續存取，不要拿已建立的工作階段與剛啟動的用戶端直接比較，更不要把某次網頁瞬間顯示歸因於協定本身。

Hysteria2 與 TUIC：以 QUIC 為基礎的設計

Hysteria2 與 TUIC 都採用以 QUIC 為基礎的傳輸方式，但兩者並非相同協定，驗證欄位也不能互換。QUIC 通常透過 UDP 執行，將加密、可靠傳輸與串流管理整合至連線設計中。不同串流不必完全受同一條有序位元組流的傳送限制，因此在某些封包遺失情況下，可以減少彼此無關的要求互相等待。不過，壅塞控制、線路容量與端點處理能力仍會共同影響最終表現。

UDP 只是基礎承載方式，不代表資料天然可靠，也不代表應用程式可以忽略資料遺失。QUIC 會為需要可靠傳送的串流提供確認與復原機制；代理協定如何處理資料報則另有規範。互動型工作可能更重視及時送達，檔案傳輸則必須確保內容完整。討論「抗封包遺失」時，應先釐清指的是復原效率、互動停頓還是持續傳輸量，而非誤以為資料遺失完全不會造成代價。

先確認網路是否允許，再調整傳輸參數

有些網路對 UDP 與 TCP 的處理方式不同，可能會限速、縮短工作階段保留時間、變更路徑或造成轉送不穩。此時，以 QUIC 為基礎的線路可能無法建立連線、閒置後失效，或一開始正常、之後停頓。若同一網路上的串流線路可以使用，可將其作為對照，協助辨別基礎承載方式的差異。不能只因 UDP 方案失敗就斷定帳戶異常，也不能因某個網路使用正常，就預期所有網路都一樣。

Hysteria2 與頻寬相關的壅塞控制設定，以及 TUIC 的連線管理與壅塞控制選項，都取決於具體實作。不要為了追求更高數字，擅自將可調頻寬設得遠高於實際網路能力。不相符的傳送行為可能加重本機排隊，讓網頁、通話及其他裝置一起變慢。若訂閱已提供參數，請先保留預設值；只有在問題能穩定重現、充分了解欄位意義且知道如何還原時，才進行小幅度比較。

如何選擇直連、中轉與專線

直連看路徑，中轉看入口與後續路段

直連通常表示用戶端直接連至遠端代理入口，但不代表網際網路中的實體路徑沒有中間設備。資料仍可能經過不同電信網路、交換節點及國際線路。入口距離近，不一定代表到目標網站的整體路徑較短；遠端出口與目標服務之間的互連也同樣重要。選擇直連時，應一併觀察連線是否順暢、持續存取是否穩定，以及常用時段執行目標任務的實際表現。

中轉線路會增加轉送環節。用戶端先連至較容易連上的入口，再由入口透過後續線路連至出口。中轉可能改善接入端與遠端之間的互連，也可能將壅塞點轉移至入口或中轉路段。增加環節不代表一定更慢，減少環節也不一定更好；結果取決於各路段的品質與排隊情況。如果入口接入穩定，後續路段選擇合適，中轉可能比繞行明顯的直連更適合長時間使用。

專線標籤不能取代端對端觀察

IEPL 專線描述的是線路採用的一種專用承載方式，但從使用者裝置到入口、從出口到目標網站，仍可能經過公共網路。線路中的某個路段品質較可控，不代表整個存取過程都與公共網路隔離。家用 Wi-Fi 干擾、本機上行頻寬占滿、目標服務回應緩慢等問題，不會因選用專線而自動消失。比較時應先判斷異常發生在接入端、承載路段還是目標端，再決定是否需要切換類型。

用戶端中的地區名稱通常用來標示節點或出口區域，不能據此推斷實際機房位置、沿途路由或各內容平台的判定結果。網站可能會依據出口位址、帳戶地區及自身資料庫共同判斷存取條件，因此地區標籤只能作為選線起點。需要使用特定地區服務時，應先閱讀目標平台規則，再實際確認所需功能；不要把「有該地區線路」直接理解成「該地區所有服務都能使用」。

依任務選擇路徑，保留可供判斷的備用選項

一般網頁瀏覽與訊息同步，可先選擇路徑較短、首次回應穩定的線路；長時間傳輸檔案，則應進一步觀察持續傳輸量及是否反覆重新連線；對互動反應敏感的任務，則更需留意延遲波動與封包遺失復原。備用線路最好與常用線路有明確差異，例如入口或承載類型不同，而非只更換一個相似名稱。如此一來，問題發生時，切換結果才有助於判斷故障位置，而不只是碰巧找到暫時可用的路徑。

選定線路後，簡單記下使用的網路、地區、線路類型、目標任務與異常情況。若白天正常、晚上停頓，且不同承載類型的表現有所差異，便可進一步觀察是否為共用線路壅塞；若所有線路在同一 Wi-Fi 網路下都異常，換用其他網路後便恢復，應優先處理本機網路。VPNLay 的地區與類型以節點頁面與用戶端清單為準；本頁不推測具體城市，也不保證某條路徑永遠優於其他路徑。

線路標籤只是描述，不代表評分。分開記錄「經過哪些路徑」與「使用哪種協定」，才能更容易判斷下次應更換路徑，還是更換傳輸方案。

延遲、抖動與尖峰時段停頓

回應時間、傳輸量與排隊情況是不同指標

延遲反映一次互動所需的等待時間，傳輸量反映持續傳送資料的能力，抖動則代表延遲隨時間變化的程度。網頁由許多彼此相依的要求組成，因此連線建立與短要求的回應速度十分重要；影片與大型檔案則更依賴持續傳輸量。某條線路下載表現不錯，但網頁仍明顯等待，並不矛盾。它可能有足夠容量，卻因往返路徑較長、頻繁建立連線，或目標服務本身回應緩慢而影響使用感受。

本機路由器或上游設備中的緩衝佇列，也可能使延遲增加。上傳檔案、同步雲端硬碟或其他裝置持續傳輸時，資料會在出口排隊，互動要求便得等待。這時使用者容易把所有問題都歸咎於遠端節點。可以先暫停背景大量傳輸工作，再觀察網頁與通話是否恢復；若改善明顯，瓶頸較可能在接入端。單純更換遠端協定，通常無法根治本機出口已滿載的問題。

封包遺失可能來自壅塞，也可能與接入環境有關

封包遺失可能是壅塞時佇列丟棄所造成，也可能與無線干擾、訊號微弱、裝置負載及路徑變動有關。可靠傳輸需要偵測缺失並進行復原，應用程式因此可能出現停頓。TCP 的有序傳送與 QUIC 的串流管理方式不同，但兩者都無法忽略底層容量。若接入網路本身持續不穩，優先改善無線環境、縮短裝置與無線基地台的距離，或改用較穩定的接入方式，通常比反覆微調協定參數更有效。

探測封包遺失，不一定代表應用程式資料也同樣遺失。有些網路設備會降低探測回應的優先順序，甚至完全不回應，但一般服務流量仍可能正常傳送。反過來說，探測結果穩定也不能證明連至特定網站的完整路徑穩定。應以實際任務為主：要求是否逾時、影音是否中斷、下載是否反覆降速，以及這些現象能否在相同條件下重現。不要只憑一張探測截圖判斷整體服務品質。

尖峰時段問題應透過時段與路徑交叉比對

尖峰時段速度變慢，常見原因是更多使用者共用接入、互連或出口資源，導致可用容量與排隊狀況改變。若某個地區的所有協定都一起變慢，應優先懷疑共用路徑；若同一入口下只有某種承載方式異常，則還需檢查該承載方式的網路處理情況。進行對照時，應維持相同目標與裝置，分別測試不同入口或類型。直接比較白天與晚上各一次的結果相減，無法得出可靠結論。

長時間傳輸時，應關注任務能否穩定持續，而非只擷取開始階段的峰值。短暫高速可能來自快取、初始突發傳輸或目標伺服器策略，之後速度下降不一定表示用戶端故障。若只有某個下載來源緩慢，可先嘗試其他合法來源的相似任務；若所有任務都慢，再從線路或本機接入端排查。遊戲情境還需區分伺服器距離、應用程式路由與代理支援情況，相關概念請參閱遊戲延遲與封包遺失說明。

遇到卡頓時，先暫停大量背景傳輸工作，再使用備用路徑進行比較。若問題消失，繼續確認是哪些條件造成差異；若沒有改善，保留錯誤訊息與任務狀態，再逐層排查，不要同時重新安裝用戶端並重設網路設定。

用戶端資源使用與行動裝置耗電

電量消耗來自整個處理流程

行動裝置耗電不只來自加密運算。應用程式發出要求後，用戶端需要接收流量、查詢規則、處理網域名稱、加解密並交由系統網路堆疊處理，無線模組也需要維持運作。持續下載時，這些工作都會增加；看似沒有操作時，背景同步、健康檢查與保持連線也可能喚醒裝置。因此，比較不同協定的耗電情況前，應先確認前景工作、背景應用程式、訊號環境與用戶端執行模式相近，否則結果很容易受到無關因素影響。

裝置是否支援相關加密硬體加速，會影響處理效率；用戶端核心的實作、記錄詳細程度及規則數量，也會改變處理負擔。協定封裝較少，不代表整個用戶端的資源使用量一定較低。若記錄持續寫入、探測過於頻繁，或規則反覆觸發複雜比對，額外工作可能超過協定標頭本身的差異。日常使用時，先保留用戶端建議的設定；遇到問題時才暫時提高記錄層級，找出原因後再恢復正常設定。

無線訊號與背景執行政策會影響判斷

訊號微弱時，可能需要更多重傳與無線活動；即使目標流量不大，耗電量也可能明顯增加。裝置在 Wi-Fi 與行動網路之間切換時，連線可能需要移轉或重新建立；部分以 QUIC 為基礎的實作具備連線移轉機制，但能否順利使用仍取決於用戶端、伺服器與網路狀態，不能因此保證切換時完全不中斷。觀察耗電情況時，最好先在穩定的網路環境下比較，再另外檢視移動情境。

系統節能模式可能限制背景執行，讓用戶端閒置後停止處理，螢幕重新開啟時又恢復。這看起來像是線路間歇中斷，實際上可能與執行權限或背景政策有關。應先檢查系統提供的網路權限、背景活動狀態與用戶端提示，不要直接歸咎於伺服器。企業管理裝置也可能設有額外網路政策，一般使用者不應擅自修改管理設定，應由裝置管理者確認允許的連線方式。

依平台確認接管方式，再觀察資源使用

在 Windows、macOS 與 Linux 上，系統代理不一定涵蓋所有應用程式；虛擬網路介面模式則可能接管更多流量，同時增加路由與解析處理。iOS 與 Android 的背景機制不同，用戶端可使用的系統功能也有差異。因此，不宜直接比較不同平台的資源讀數。更有參考價值的方式，是在同一裝置上維持相同任務，比較不同線路或承載方式，並同時記錄是否發熱、斷線及應用程式重試。

如果裝置閒置時仍持續發熱，先檢查是否仍有下載、備份或應用程式更新，再查看用戶端是否不斷重新連線。驗證參數錯誤、解析循環或網路無法連線，都可能導致持續重試。暫時關閉不必要的背景工作，比盲目關閉安全驗證更合適。VPNLay 支援 Windows / macOS / iOS / Android / Linux，裝置數量不限；用戶端入口位於使用者控制台，登入後即可取得訂閱；iOS 用戶端入口另需有效方案。

省電設定應以任務能穩定完成為前提。過度縮短背景活動時間，可能導致更頻繁重新連線；一味增加保持連線，也可能增加無線模組喚醒次數。先找出實際問題，再保留必要設定。

依應用程式需求整理線路清單

網頁與 AI 工具：先確認完整要求能否完成

瀏覽網頁、處理線上文件及使用 AI 工具，往往涉及短要求、持續回應與帳戶驗證。選擇線路時，先確認目標服務允許目前的地區與帳戶條件，再觀察首次回應、持續輸出及重新開啟頁面的表現。串流回應突然停止，可能是連線中斷、閒置逾時，也可能是目標服務限制了要求。不能只因頁面仍能開啟，就認為長連線一定正常；應將問題釐清至特定功能與要求階段。

這類任務通常更需要穩定且可重複使用的存取路徑，而不是頻繁追逐瞬間峰值。可以先選擇容易建立連線的線路，再保留採用不同承載方式的備用選項。使用分流時，應確認相關網域與必要的驗證要求都走預期路徑，避免頁面主體與驗證服務使用不同出口。若需調整規則，應先了解規則順序與預設處理方式，不要將所有未知網域一律加入臨時規則後就停止確認。

串流影音與檔案：留意持續傳輸及出口條件

串流影音播放需要穩定供應資料，也會受到片庫地區、帳戶權益、出口辨識及平台政策影響。節點地區名稱不能保證看得到特定內容，也無法保證畫質永遠固定且流暢。先確認內容與帳戶條件，再觀察播放開始、拖曳進度及持續播放是否正常。若只有特定平台無法使用，而網頁與其他任務正常，應優先檢查目標平台的限制，而非立刻修改整個用戶端設定。

檔案傳輸更容易受到持續傳輸量、來源端限速及本機出口競爭影響。選擇較穩定的路徑後，應觀察任務能否持續進行，以及是否影響其他互動工作。若下載正常、上傳時網頁卻明顯變慢，應先檢查上行排隊與背景同步。關於片庫與播放條件的進一步說明，請參閱Netflix 地區與頻寬選擇文章；若涉及特定服務能否使用，仍應以當下實際測試為準。

遊戲、線上課程與多裝置：分開確認各項服務流量

遊戲對延遲波動與及時傳送更敏感，但一般代理不等同於專為特定遊戲最佳化的加速服務。啟動器登入、遊戲資源下載與實際對戰可能採用不同連線方式，不能因更新下載順利，就推斷對戰路由合適。線上課程與會議也可能分別使用網頁驗證、音訊及視訊通道。檢查時應確認真正需要的功能，並確認用戶端已接管相關流量；不要只測試瀏覽器，就認定所有連線都正常。

多部裝置共用網路時，選擇線路還需考量家庭或辦公室出口的共同負載。VPNLay 同時連線的裝置數量不限，但不代表網路容量沒有上限，也不表示每部裝置都適合同時執行大量傳輸工作。讓需要互動的裝置維持穩定，並在合適時段安排下載，往往比所有裝置同時切換到相同節點更有效。如果只有某部裝置異常，應先在該裝置確認權限、規則與用戶端狀態。

流量需求與協定選擇應分開決定。月訂閱方案為 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB；流量自開通日起每月重設，中途升級的價差依剩餘天數折算。流量包用完為止，永久不會過期。請至方案頁確認適合的計費方式，不要因協定名稱推測額外權益。VPNLay 提供 30 天無理由退款，付款方式為支付寶／微信／USDT。

將連線問題鎖定在具體環節

無法建立連線：先檢查本機與設定

完全無法建立連線時，先確認裝置可以正常上網、系統時間正確、用戶端已取得必要權限，且訂閱已成功載入。查看記錄中失敗的階段：解析失敗、連線逾時、驗證失敗及憑證驗證錯誤，各自指向不同問題。不要把所有錯誤都歸為「節點無法使用」。如果訂閱連結剛重設，舊設定可能已失效；請從控制台重新取得並更新，避免反覆使用已過期的本機內容。

設定顯示正常卻持續逾時時，可維持原有網路，改用另一種已提供的承載方式；接著保留原設定，改用另一種可用網路。前者有助於判斷入口或傳輸方式的差異，後者有助於判斷本機接入條件。每次調整後，只測試同一項任務並記錄結果，再進行下一步。若同時更改解析、路由與協定，即使連線恢復，也無法判斷原因；下次再遇到問題時，仍只能從頭嘗試。

連線建立後異常：區分接管、解析與目標存取

用戶端顯示已連線，但只有部分應用程式異常時，先查看是否有該應用程式的要求紀錄。若沒有紀錄，優先檢查系統代理的涵蓋範圍、虛擬介面模式及應用程式本身的代理設定；若有紀錄但套用到非預期規則，應檢查規則順序與比對對象；若已轉交正確節點，則繼續查看解析及遠端存取錯誤。網域名稱解析可能在本機或遠端執行，不同模式會影響觀察結果，應以用戶端的實際設定為準。

頁面可以開啟但無法完成操作時，應記錄具體步驟，而非只寫網站名稱。例如登入後轉址失敗、檔案開始傳輸後停住，或閒置後重新要求失敗，都比「無法存取」更有助於定位。若部分網頁正常、大型回應卻停頓，網路路徑的封包大小與分片處理也可能有關，但不應先任意修改介面參數。先交叉測試不同接入網路與承載方式，確認確有相關證據後，再依用戶端說明處理。

整理紀錄，並保留明確的還原方式

回報問題前，請寫明平台、用戶端名稱、接入網路類型、節點地區、線路類型、協定及問題發生階段。記錄僅擷取與錯誤相關的內容，並遮蔽帳戶識別資訊、訂閱連結、驗證資訊及其他敏感欄位。訂閱連結等同可用的存取憑證，不適合公開討論或放入截圖。如果懷疑連結外洩，應在控制台重設並更新所有裝置，而不只是刪除已發出的訊息。

連線恢復後，保留一組已確認有效的設定，再逐步恢復先前暫停的規則與背景工作。不要因某次切換有效，就立刻讓所有裝置使用相同設定；應先確認問題能否重現，以及修復是否穩定。如需協助，請透過客服頁面建立服務單，並提供已去識別化的紀錄。建立帳戶不需電子郵件地址，使用者名稱與密碼即可；但處理連線問題時，不需向客服提供密碼或完整訂閱內容。

疑難排解的目標不是試遍所有選項，而是讓每次變更都能排除一種可能。若不熟悉操作流程，請返回使用教學確認主要步驟；需要帳戶、計費或一般連線說明時，請查看常見問題。將原理查閱與實際操作分開，既能減少誤改，也能加快下次判斷。