協定與線路
技術指南

連線分層：先分清協定與線路

一次連線會經過哪些環節

瀏覽器開啟國際網站時，應用程式會先依目標網域名稱建立請求，再由系統或用戶端決定請求要走本地網路，還是使用所選線路。需要經過本服務的流量，會由用戶端依照訂閱中的協定與伺服器通訊，再從出口連線至目標網站。目標網站傳回的資料則沿著相應連線回到應用程式。這個過程涉及應用程式請求、網域名稱解析、代理傳輸與網路路徑；任何環節出問題都可能呈現為「網頁無法開啟」，但處理方式各不相同。

協定說明用戶端與伺服器如何交換必要資訊、驗證身分、封裝資料及傳遞目標位址；線路則說明資料經過的入口、骨幹路徑與出口安排。同一種協定可以部署在不同線路上，同一個出口地區也可能搭配不同入口。因此，看到 Trojan 不代表就是「專線」，看到香港也不代表延遲一定低。用戶端清單中的協定、地區與線路類型屬於不同面向，應分開判讀，而非合併成單一的品質等級。

分別測量解析、連線與應用程式回應時間

網域名稱解析會將網站名稱對應到可連線的位址，解析路徑也會影響網站選擇哪個內容傳遞網路節點。接著是建立連線、必要的安全交握，以及送出應用程式請求。網頁遲遲沒有內容，可能是解析等待、交握重試，也可能是網站已收到請求但仍在處理。已開啟的網頁圖片載入緩慢，則可能與持續傳輸或網站資源所在位置有關。只有分清「開始得慢」與「傳得慢」，才能判斷該更換協定、線路，還是檢查目標服務。

TCP 提供有序且可靠的位元組串流；UDP 負責傳送資料封包，本身不保證依序送達。使用 UDP 不代表應用程式只能接受資料遺失，也不代表一定更快：上層協定可以自行實作確認、重傳與壅塞控制。QUIC 就是在 UDP 之上實作安全連線與可靠串流。反過來說，TCP 的可靠傳輸也不代表「不會卡頓」，因為它需要等待遺失的資料補齊。比較協定時，應看可靠性由哪一層負責，以及該層機制是否適合目前的網路。

分開記錄「可連線」與「可使用」

用戶端顯示連線成功，通常只代表某個連線環節已完成，不等於所有網站和服務都已驗證。目標應用程式仍可能要求重新登入、驗證帳戶地區，或依特定出口套用自己的存取規則。測試時先確認一般網頁能正常載入，再檢查目標應用程式的具體操作；別只看見綠色圖示就認為測試完成。反過來說，網站顯示帳戶限制，也不應立刻判定是協定故障；請保留原始提示，繼續從應用程式層面判斷。

經典協定：驗證、加密與相容性

Shadowsocks 與 VMess 的設計重點

Shadowsocks 的基本做法，是讓用戶端與伺服器透過約定的加密方式交換代理資料，常用於以較直接的封裝方式轉送流量。實際安全性取決於採用的加密套件、憑證管理與實作方式，不能只看協定名稱。不同套件的金鑰處理方式和資料格式可能不同，用戶端也未必全都支援。匯入後若出現不支援加密方式的提示，請更新至相容的用戶端，或改用訂閱提供的其他可用項目，不要自行猜測並替換成名稱相似的選項。

VMess 將身分驗證與資料傳輸納入自己的協定架構，並常與不同傳輸封裝搭配使用。實際表現不只取決於 VMess 本身，也會受到底層傳輸、加密設定與實作方式影響。有些驗證模式涉及時間有效性，裝置時間若明顯不準，可能會出現不易判讀的驗證失敗。遇到這種情況，校準系統時間、重新更新訂閱並確認用戶端支援情形，比任意修改伺服器參數更合適。可組合的選項較多，部署彈性也較大，但手動填寫時也更容易漏掉欄位。

Trojan 與 VLESS 的安全界線

Trojan 通常透過 TLS 建立受保護的傳輸，再於其中進行代理驗證與轉送。TLS 的伺服器身分驗證不可省略：憑證有效性、伺服器名稱與系統信任狀態都可能影響連線。某個節點無法完成交握時，不應把關閉憑證驗證當成通用修復方式。應先檢查系統時間是否正確、訂閱是否完整，以及該線路是否確實可用。即使驗證資訊正確，若伺服器身分不受信任，仍不代表這是可以放心使用的正常連線。

VLESS 採用較精簡的代理協定架構，本身不會僅憑協定名稱提供完整的資料加密能力；安全傳輸取決於部署時搭配的保護機制。訂閱中的傳輸方式、伺服器名稱及相關參數會共同決定連線形式。把 VLESS 簡化成「輕量，所以一定快」，容易忽略實際交握與底層網路成本；把某種外層保護方式視為所有 VLESS 連線的預設特性，同樣不準確。一般使用者應保留服務提供的完整參數，不必逐項追求看起來更進階的選項。

連線成本不能只依名稱排序

評估連線建立速度時，應一併考量底層連線、安全交握、代理驗證與目標網站回應。若能重複使用既有連線，使用者的體感會與每次重新建立連線不同；用戶端進入背景後是否保留工作階段，也會影響結果。資源占用則受到加密實作、硬體加速、並行連線數與規則規模影響。在某台電腦上感覺流暢的組合，換到行動裝置上未必更省電。因此本頁不提供脫離裝置與線路條件的固定排名，也不以協定的新舊推斷性能優劣。

選擇時先確認訂閱可正常匯入、用戶端可持續維護，再比較同一網路下的實際服務表現。網頁瀏覽正常但長連線不穩，可進一步檢查閒置逾時與網路切換；所有應用程式都無法完成交握，則優先檢查入口是否可連及參數是否正確。協定的作用是提供適合不同情境的傳輸工具，而不是讓使用者蒐集名稱。VPNCross 實際支援的項目請以訂閱內容為準；本技術指南介紹的協定，不代表所有線路都會提供。

QUIC 協定：Hysteria2 與 TUIC

為什麼以 UDP 承載可靠傳輸

Hysteria2 與 TUIC 都運用 QUIC 相關能力來傳輸代理流量，但兩者在驗證、轉送方式與壅塞處理細節上並不相同。QUIC 運作於 UDP 之上，整合安全交握，並支援在同一連線中管理彼此獨立的資料流。某個資料流的封包需要重傳時，其他資料流不必因傳輸層要求依序交付而一同等待。不過，共用鏈路上的壅塞與共同的壅塞控制仍會影響整體吞吐量；這不代表封包遺失的影響就此消失，也不會增加網路容量。

理解這類協定時，可以先看「可靠傳輸由哪一層負責」。傳統組合通常依靠 TCP 在系統核心中處理可靠傳輸；QUIC 的許多處理則由使用者空間實作負責。這有助於協定更新與連線管理，但也會帶來不同的處理成本。用戶端實作、裝置效能、系統排程與資料流量都會影響資源占用。不能因為「使用 UDP」就推論耗電較低，也不能因為「使用者空間」就認定效能較差；最終仍取決於實際實作與工作負載。

Hysteria2 的頻寬與壅塞概念

Hysteria2 適用於網路品質不理想時的代理傳輸情境，其壅塞處理方式會影響資料傳送行為。某些模式需要使用者或部署方提供頻寬相關資訊，這些數值並非越大越好。若過度高估可用容量，傳送負載可能超出接取鏈路的承受能力，造成排隊、封包遺失，並影響其他應用程式的使用體驗。一般訂閱使用者不應為了追求速度，擅自將參數改成與本地接取條件無關的數值；請優先採用訂閱與用戶端已配合好的設定。

Hysteria2 在某些封包遺失情境下表現較佳，不代表它能改善無線訊號涵蓋不足、出口壅塞或目標伺服器忙碌等問題。若封包遺失發生在家中無線網路接取區段，終端裝置與路由器之間仍會互相競爭；若出口容量不足，協定也無法憑空變出資源。評估是否適用時，請觀察目標服務能否持續完成、其他裝置是否受到明顯影響，以及用戶端是否出現異常發熱。只看一次大型檔案傳輸的瞬間數據，容易把短暫突發表現誤當成長期能力。

TUIC 的連線共用與持續性

TUIC 利用 QUIC 連線進行流量轉送，並提供與代理服務相關的連線管理能力。共用連線可減少重複建立底層連線的需求，但不代表所有上層應用程式都能獲得相同效益。短暫的網頁請求、持續播放的影片與互動請求，各有不同的等待模式；用戶端也需要協調資料流管理與連線維持。QUIC 協定具備處理路徑變化的相關機制，但具體用戶端與代理部署是否完整支援，以及切換網路後服務是否真的持續，都需要個別驗證。不能只因底層協定具備相關能力，就宣稱應用程式一定不會中斷。

如果目前網路對 UDP 的處理不穩定，這類協定可能在開始連線時就遇到困難，而基於 TCP 的可用項目仍可正常運作。此時保留相容線路，比反覆調整同一個選項更實際。比較時請盡量維持相同地區、接取網路與應用程式，記錄連線是否成功、服務是否能完成，再討論協定差異。不要把不同地區、不同時段與不同用戶端的體驗混在一起下結論，否則無法分辨改善來自協定還是路徑。

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

地區名稱只說明出口，不代表完整路徑

用戶端中的地區通常用來識別出口位置，但資料進入服務網路的位置未必相同。存取請求可能先抵達某個入口，再沿著轉送路徑前往出口，最後連線至目標網站。出口靠近目標服務可能縮短後段路徑，入口靠近使用者則可能改善前段連線能力，兩者都要一併考量。單靠地理距離推測總延遲並不可靠；電信業者互連、路由策略與壅塞狀況可能使實際路徑繞行，地圖上較近不一定代表網路上較近。

直連通常指用戶端直接連線至相應的境外服務入口，路徑相對單純，也較仰賴使用者本地電信業者的國際互連品質。優點可能是鏈路安排簡單、額外轉送環節較少，但這不代表穩定性一定有保障。某個接取網路直連順暢，換到另一個接取網路後可能有明顯差異。選擇時應以實際服務是否順暢為準，不要把「少一段中轉」視為一定更快。直連適合作為可比較的路徑選項，而非天生的品質等級標籤。

中轉與 IEPL 專線如何影響使用體驗

中轉是在用戶端與最終出口之間加入轉送環節，目的是運用不同網路間的路徑組合。妥善安排入口與後段轉送，可能避開不理想的互連路徑，讓連線表現更穩定；但新增環節也需要考量容量、維護與故障切換。中轉不只是讓距離變長或變短，關鍵在於更換了哪一段網路。遇到異常時，可觀察同一入口的其他出口是否也受影響，藉此區分入口問題、轉送問題與個別出口問題。

IEPL 專線表示線路配置使用了相關專用連線資源，通常用於降低部分共用路徑所帶來的不確定性。不過，使用者到入口仍須經過本地接取網路，出口到目標網站也可能繼續使用公用網路，因此「專線」標示不能代表整條存取路徑。專線同樣會受到容量安排、入口品質、維護狀態與目標網站影響。將專線理解為線路中的一種資源配置，比將它視為「任何時候、任何網站都一樣快」的保證更準確。

如何權衡延遲與穩定性

互動應用重視往返等待是否平穩，大型檔案與影片則更在意持續傳輸是否有足夠餘裕。某條線路在閒置時的測試延遲較低，但忙碌時排隊明顯，實際會議體驗可能不如延遲稍高但波動較小的線路。選擇時先排除無法連線與明顯中斷的項目，再比較服務表現。若地區必須符合應用程式帳戶或內容規則，也不應只為追求更低的測試延遲而頻繁更換出口，否則網路問題尚未解決，應用程式端又多了新的變數。

VPNCross 提供 90+ 個國家 / 190+ 條線路，實際地區與線路類型請參閱線路清單及登入後的可用項目。清單可協助了解選擇範圍，但不代表每個地區都有完全相同的路徑架構。比較同一地區的線路時，請先分清直連、中轉與 IEPL 專線，再檢視協定及接取網路。若情況許可，保留平時使用的主要線路，以及拓撲不同的備用線路；發生問題時切換路徑，通常比只在相同入口更換協定名稱更有助於排查。

封包遺失與壅塞：為什麼尖峰時段會卡頓

延遲、抖動與吞吐量是不同指標

延遲描述請求與回應之間的等待時間，抖動描述等待時間隨時間的變化，吞吐量則表示一段時間內實際完成的資料傳輸量。三者彼此相關，但不能互相取代。閒置時回應迅速，不代表同時傳輸大量資料時仍然迅速；影片可以利用緩衝容忍部分等待，語音會議則更容易受到突發抖動影響。了解這些差異，有助於解釋為什麼測速結果看起來不錯，日常互動卻仍不順暢。

封包遺失可能來自無線訊號干擾、裝置處理能力不足、佇列溢位、路徑切換或某段鏈路異常。可靠傳輸通常透過確認與重傳補回遺失內容，但復原需要額外等待，也可能觸發傳送速率調整。應用程式可能因此出現網頁停頓、影片緩衝或請求逾時。協定可以改變復原方式，卻無法保證所有封包遺失都不會影響使用者。尤其持續壅塞時，一味增加重試只會進一步占用原本就吃緊的鏈路資源。

尖峰時段的瓶頸可能出現在不同位置

尖峰時段連線變慢，首先表示某些共用資源在繁忙時承受壓力，不能直接斷定問題出在服務出口。家中網路可能同時用於播放影片與備份；接取電信業者可能在匯聚區段發生排隊；線路入口與國際區段也可能繁忙；目標網站還可能自行限速。可透過範圍比較來判斷：本地一般網站是否也變慢、其他線路是否同樣變慢，以及同一線路上的不同目標是否都異常。每項比較都對應不同的故障邊界。

排隊時間過長會讓互動等待不斷增加，有時比平均吞吐量下降更明顯。背景上傳、雲端硬碟同步與系統更新都可能讓家用網路的傳送佇列持續繁忙，影響確認封包與互動請求及時送出。先暫停非必要的大量資料傳輸，再確認問題是否改善，是成本很低的檢查方式。若暫停後恢復正常，應從本地流量競爭與路由器佇列管理繼續檢查，而不是立刻將責任歸咎於某個協定。

如何解讀測試結果才不會誤判

一般測試工具的流量處理方式不一定與實際服務相同。中間設備可能降低測試封包的回應優先順序，因此某個中間節點沒有回應，不代表最終服務也以相同比例遺失資料。路由追蹤出現等待符號，也可能只是設備不回應測試封包。應一併檢視最終目標的連線能力、應用程式請求結果與持續傳輸狀況。不要只因路徑中間有一處沒有回應就判定線路故障，更不要將測試數據視為服務可用率保證。

比較線路時，請盡量維持測試條件一致，避免一邊在背景下載、一邊判斷另一條線路的互動品質。先以相同目標完成相同操作，記錄問題是初次連線緩慢、持續載入緩慢，還是執行中突然中斷；接著觀察切換線路類型後狀況是否改變。若只有某個應用程式異常，請保留其提示與發生情境；若多種應用程式同時異常，再擴大檢查接取網路、入口與系統層面。依影響範圍逐步排查，比不斷重新測速更容易得出有用結論。

若問題明顯發生在特定時段，可記錄接取網路、所選地區、線路類型、用戶端狀態與異常應用程式，並透過管理面板的客服工單提供資訊。無需公開訂閱網址或帳戶憑證。比起只說「晚上很卡」，說明「相同網路下網頁正常，但持續播放影片會中斷；切換不同入口後恢復」，更有助於定位，也能減少來回詢問。提供可重現的條件，比自行推測某段網路一定故障更有幫助。

平台與耗電：維持連線的成本

耗電來自運算，也來自喚醒

行動裝置耗電不只來自加密運算，也與無線通訊、背景喚醒、連線維持及應用程式本身的資料活動有關。某種協定在電腦上的資源占用不明顯，到了行動裝置上卻可能因頻繁重新連線或持續傳輸而發熱。裝置的硬體加速、系統網路介面與用戶端實作也會影響結果。因此，「協定越輕就越省電」過度簡化了問題。觀察時應分別測試待機、一般瀏覽、影片播放與持續下載，不要將不同負載下的電量變化一概歸因於協定差異。

維持連線的目的是避免路徑上的工作階段狀態過早失效，但越頻繁傳送維持封包不一定越好。這可能增加無線網路喚醒次數；維持封包太少，某些網路也可能回收閒置連線。合理設定須兼顧目前的接取網路與用戶端設計。一般使用者應先保留預設設定，只有明確遇到「閒置一段時間後第一次請求失敗」等情況，再依照用戶端說明調整；不要照抄與自己的裝置和網路都不同的參數清單。

系統背景管理會影響測試結果

行動作業系統會透過背景管理與省電機制限制應用程式活動，不同系統與裝置的行為不盡相同。螢幕關閉後連線狀態改變，可能與系統排程有關，也可能是網路切換或閒置工作階段逾時。排查時請分別觀察應用程式在前景正常運作、切換至背景、關閉螢幕，以及重新返回應用程式的過程，確認問題在哪一步出現。若只有背景情境異常，應優先檢查系統允許的背景執行設定與用戶端說明，而非直接判定出口無法使用。

從無線區域網路切換到行動網路時，裝置位址、路由與網路狀態都可能改變。即使底層協定具備連線遷移相關能力，上層應用程式也未必能保留原有工作階段。正在進行的上傳、會議或長時間請求仍可能需要重新建立連線。若需要維持連續服務，請盡量避免在重要操作期間主動切換網路；若必須切換，先確認用戶端已恢復連線，再繼續操作。介面顯示正在重新連線，不代表應用程式中尚未完成的工作一定會自動接續。

流量分流、規則與日誌也會增加執行負擔

智慧分流需要判斷目標請求應使用哪條路徑；規則規模、比對方式與網域名稱解析安排都會影響處理過程。規則不是越多越準確，也不是所有流量都走同一路徑就一定省事。有些桌面程式不會讀取系統代理，需要用戶端以合適方式接管流量；多個工具同時修改系統代理或網路介面，也可能互相衝突。排查時應確認只有預期的用戶端正在接管流量，避免將多套軟體疊加造成的問題誤認為協定表現。

用戶端的本機診斷日誌，與 VPNCross「不記錄日誌」的服務政策並非同一層面的概念。使用者為排查問題開啟本機日誌時，應留意其中可能包含網域名稱、訂閱識別資訊與連線資料，不要直接公開完整檔案。診斷結束後，請恢復日常日誌等級，減少無關資訊累積，也避免持續記錄增加額外處理負擔。VPNCross 支援 Windows / macOS / iOS / Android / Linux，用戶端請統一從管理面板的下載頁面取得；訂閱內容須登入後取得。

依使用情境選擇：先看服務，再看協定

網頁、開發與 AI 請求

一般網頁由許多短請求組成，初次連線、網域名稱解析與內容傳遞位置往往影響使用體驗。選擇時先確認常用網站能否順利開啟，再比較同一地區不同線路的等待時間是否穩定，不必為追求某個協定名稱而反覆切換。開發工具可能使用獨立的代理設定；瀏覽器正常，不代表終端機、程式碼編輯器與套件管理工具也走相同路徑。應在實際工作的工具中驗證，而不是只開啟一個網頁，就認定開發環境已連線。

AI 網頁與 API 呼叫也應分開檢查。網頁版涉及登入狀態、瀏覽器工作階段與介面資源；API 呼叫則須考量驗證、請求逾時、串流輸出與應用程式本身的重試機制。網路中斷可能使回應未完整送達，但伺服器可能已經處理請求，因此自動重試前應確認服務是否允許重複執行。若需要長期維持出口一致，還須考量線路與應用程式政策，不能只憑協定名稱推斷。更多開發情境請參閱AI API 線路選擇指南。

串流影音、會議與大型檔案

串流影音更重視持續傳輸與內容可用性。播放開始很快，但之後頻繁緩衝，可能是持續傳輸容量不足，也可能是內容傳遞路徑改變。不同平台也會依帳戶、著作權地區與出口辨識結果決定可播放的內容；連線成功不代表指定片庫一定可用。比較時請維持相同帳戶、內容與播放設定，觀察播放是否持續順暢，不要反覆更換影片與出口。若只有內容權限提示改變，應與網路傳輸故障分開處理。

語音會議與遠端協作對等待時間波動更敏感，即使總流量不大，也可能受到上傳占用與排隊影響。會議前請關閉非必要的大量資料同步，選擇表現穩定的線路，並避免會議期間頻繁切換地區。大型檔案傳輸則適合觀察長時間傳輸是否中斷、能否續傳，以及本機儲存空間是否成為瓶頸。協定能提供傳輸機制，但應用程式是否支援續傳仍由應用程式決定；不能將所有下載失敗都歸因於線路頻寬不足。

流量規劃與技術選擇應分開考量

適合的技術線路也須配合實際流量需求。VPNCross 月訂閱方案為 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量自啟用日起每月重置；中途升級時，差額依剩餘天數折算。流量包為 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完為止，永久不過期。詳細比較請參閱方案頁面。不要為了測試協定而長時間反覆傳輸大型檔案，測試用量也會實際扣除；不同協定也不能因此保證相同服務一定更省流量。

VPNCross 不限制同時連線的裝置數，但裝置越多，越需要妥善安排家中接取網路與套餐流量。無需電子郵件地址，以使用者名稱和密碼即可註冊；付款方式包括支付寶 / 微信 / USDT，並提供 60 天無理由退款。以上服務資訊與協定優劣沒有直接關係，不應將較大流量方案理解為用戶端會自動改用某種協定。先確認自己的服務需求、接取網路與用戶端相容性，再規劃流量用量，能減少混淆計費與技術問題。

驗證與排錯：依故障位置縮小範圍

先保留問題現況，再變更條件

開始排錯時，先記錄目前使用的用戶端、接取網路、線路地區、協定與應用程式提示，並確認問題是否能重現。不要同時更新用戶端、更換協定、修改解析模式又切換出口；即使最後恢復正常，也無法得知是哪項變更有效。較穩妥的做法是保留其他條件，只變更目前懷疑的因素，再重複相同操作。每次觀察都應回答具體問題，例如「是否能完成交握」或「長時間回應是否中斷」，而不是只記下「感覺變快了」。

如果所有線路都無法使用，先確認裝置本地網路能正常瀏覽一般網站，再檢查用戶端是否已啟用、訂閱是否成功載入，以及系統時間與權限是否正常。若只有某個節點異常，請改用路徑或入口不同的可用項目比較。若只有某個應用程式異常，請確認應用程式是否讀取系統代理、是否使用自己的網路設定，以及錯誤是否來自帳戶或伺服器提示。透過這些分支逐步排查，可將範圍從整台裝置縮小到線路或應用程式，避免不相關的修改越積越多。

訂閱完整性與憑證問題

訂閱連結是用戶端取得線路設定的入口，不應當成一般網頁網址任意公開。匯入失敗時，先分辨是下載訂閱失敗、解析格式失敗，還是線路連線失敗：前者應檢查網路與連結狀態，中間環節應檢查用戶端支援的格式，最後才檢查特定伺服器連線。不要為了強行匯入而手動刪改不熟悉的欄位，欄位缺漏可能讓明顯的匯入錯誤變成更難定位的交握錯誤。基礎概念請參閱訂閱連結的取得、匯入與更新指南。

出現憑證或身分驗證錯誤時，請保留原始錯誤訊息，檢查系統時間與訂閱更新狀況，並使用用戶端支援的正常驗證方式。不要長期設定為略過驗證，也不要將訂閱內容貼到公開討論區請人代為測試。如需提交資料，只提供必要的錯誤片段，並隱藏帳戶識別資訊、訂閱網址與驗證資訊。服務政策中的不記錄日誌，不代表使用者裝置上的截圖與診斷檔案可以不經處理就分享；使用者仍須自行控管這些資料的傳播範圍。

整理成可重現的診斷紀錄

有用的紀錄應說明：問題發生在前景還是背景、是否剛切換網路、一般網站是否正常、同地區其他線路是否正常，以及目標應用程式回傳了什麼。如果恢復後又再次發生，也可說明恢復前變更了哪項條件。無需貼出完整原始設定，也不必自行斷定是哪個網路環節故障。透過管理面板的客服工單提交整理過的資訊，通常比連續傳送測速截圖更容易判斷；本頁不提供公開訂閱網址或安裝檔直連。

連線恢復後，再依照日常用途進行一次驗證：一般網頁使用者確認資源是否載入，開發者在實際工具中送出請求，串流影音使用者觀察播放是否持續，會議使用者則留意聲音與互動是否穩定。接著清除排錯期間暫時新增的規則、恢復日常日誌等級，並保留確實有效的設定。恢復後不要繼續堆疊所謂的最佳化參數，避免新變數再次影響穩定狀態。能解釋、可還原的設定，比複雜但作用不明的設定更容易維護。

需要從頭開始操作，請返回使用教學；需要比較路徑，請查看線路清單；需要確認費用與流量重置規則，請參閱方案頁面。協定、線路、用戶端與應用程式各自負責不同工作，沒有單一開關能取代所有環節。掌握這套分層方法後，即使遇到新的協定名稱，也能用相同問題來判斷：採用什麼傳輸方式、如何保護連線、目前平台是否支援，以及實際服務是否因此更穩定。