協定與線路值班手冊

協定與線路技術參考

從握手方式、傳輸特徵、裝置資源到線路拓撲,建立一套可核對的選擇與排錯方法。這裡不是快速操作教學,而是說明連線為何變快、變慢或產生抖動,以及應從哪一層開始判斷。

90+ 個國家 200+ 條線路 Windows / macOS / iOS / Android / Linux 7 天可退款
判斷框架 MODEL

先釐清層次,再討論協定速度

連線體驗並非由協定單獨決定

討論網路加速時,最常見的誤區是把所有體驗差異都歸因於協定名稱。實際上,從應用程式發出請求到目標服務回傳內容,中間至少會經過本機裝置、接取網路、用戶端處理、入口線路、跨區傳輸、出口線路與目標服務本身。協定只負責其中一部分:規定用戶端與伺服器如何建立工作階段、封裝資料,以及處理丟包或壅塞。若入口本身無法連線、接取網路持續抖動,或目標服務正在限制連線,單純更換協定往往無法帶來穩定改善。

更可靠的判斷方式,是將問題拆成「裝置層、工作階段層、線路層、目標層」。裝置層關注系統權限、背景執行、電量策略與用戶端是否正常;工作階段層關注握手能否完成、連線是否頻繁重建、傳輸方式是否適合目前網路;線路層關注入口距離、跨區路徑、壅塞與丟包;目標層則關注網站、串流影音或 AI 工具是否為目前出口地區提供服務。先確認問題所屬層次,後續調整才不會變成無方向的反覆切換。

速度、延遲與穩定性是不同指標

速度通常描述持續傳輸資料時的吞吐能力,延遲描述一次請求往返所需的等待時間,而穩定性描述這些表現能否在連續使用期間維持。下載大型檔案更依賴持續吞吐,網頁與遠端操作更在意請求往返,視訊會議與即時語音則同時受不了延遲波動與丟包。某條線路即使能在短時間內傳輸大量資料,也可能因排隊變化而出現互動卡頓;另一條線路峰值不突出,卻可能因路徑固定、抖動較小,更適合辦公與通話。

因此,「最快協定」並不是脫離使用情境後仍然成立的結論。協定採用的傳輸方式、系統網路堆疊、用戶端實作與線路品質都會改變結果。相同協定放在不同入口上,體驗可能差異明顯;同一入口在有線網路、公共無線網路與行動數據環境下,也可能有不同表現。判斷時應固定裝置、目標服務與入口線路,只改變一個變數。一次同時更換協定、地區與用戶端設定,雖然可能暫時恢復連線,卻無法說明究竟是哪項調整發揮作用。

建立可複查的測試順序

一次有效的判斷應留下簡單紀錄:使用的裝置與網路環境、選擇的入口地區、協定名稱、目標服務、問題發生在連線前還是連線後,以及切換某一項後現象是否改變。這裡不需要複雜的監控工具,重點是讓前後條件一致。例如頁面無法開啟時,先確認用戶端是否顯示工作階段已建立,再造訪穩定的公共網站;公共網站正常而特定服務異常,問題更可能位於目標層,而不是協定本身。

LeeVPN 覆蓋 90+ 個國家與 200+ 條線路,入口選擇空間較大,但選項越多,越需要明確的方法。優先選擇地理位置接近目前接取位置、路徑較短的入口,再依目標服務需求選擇出口地區。若要查看不同地區與線路類型,可前往節點與線路頁面;若仍在比較月訂閱與流量包,則應先查看方案規則,避免將流量週期問題誤判為用戶端故障。

分層判斷還有另一個好處:能減少無效操作。清除全部設定、反覆安裝用戶端或持續切換大量線路,都會讓原有線索消失。更合適的做法是從影響範圍最小的檢查開始,先驗證帳戶與訂閱是否有效,再確認入口可達,接著觀察目標服務,最後才考慮更換協定與調整系統網路設定。只要每一步都能回答「現象是否改變」,排錯就能從猜測變成可複查的過程。

協定檔案 PROTOCOL

常見協定的設計取捨

Shadowsocks:結構直接,取決於實作品質

Shadowsocks 的核心概念相當直接:用戶端先將流量加密封裝,再交由遠端伺服器轉發。其實作生態成熟,設定概念相對少,桌面與行動裝置都容易理解。由於處理鏈路不複雜,在裝置資源有限、希望減輕用戶端負擔的情境中通常適應性良好。它也常用於一般網頁、檔案傳輸與日常應用程式連線,不必為大量擴充欄位付出額外管理成本。

它的限制在於,實際表現高度取決於用戶端與伺服器實作、加密方式、底層傳輸與線路本身。看到相同的協定名稱,不代表兩條線路具備相同能力。若某個用戶端對系統網路延伸功能支援較弱,或背景恢復機制處理不佳,仍可能出現裝置休眠後需要重新連線的情況。選擇時應將它視為簡潔、通用的工作階段方案,而不是把「簡潔」直接等同於所有網路環境下都更快。

VMess:資訊完整,處理環節較多

VMess 在工作階段中包含較完整的驗證與傳輸資訊,能配合不同承載方式運作。它的優勢是生態中有許多成熟的設定組合,對需要兼顧相容性與多種傳輸路徑的環境較友善。由於參數較多,用戶端匯入訂閱時應盡量保留服務端下發的內容,不建議在不了解欄位作用時手動改寫。某些看似無關的傳輸選項,實際上會決定用戶端如何建立連線,修改後可能直接在握手階段失敗。

相較於結構更精簡的方案,VMess 的工作階段處理通常需要用戶端完成更多步驟。現代桌面裝置一般不會將這種差異放大到明顯影響使用,但在頻繁重新連線、背景受限或裝置負載較高時,額外處理仍可能表現為連線恢復較慢。判斷它是否適合,不應只看單次連線能否成功,也要觀察網路切換、裝置喚醒與長時間背景執行後能否穩定恢復。

Trojan:依託標準加密工作階段的相容性思路

Trojan 通常透過標準加密工作階段建立連線,設計重點是讓驗證與資料傳輸在成熟的加密通道中完成。它適合網路環境對標準加密連線相容性良好,且希望用戶端設定保持清晰的情境。握手階段需要完成相應的加密協商,因此系統時間、憑證驗證、網域解析與伺服器設定都會影響結果。若表現為連線一開始就中斷,應先檢查這些基本條件,而不是直接將問題歸因於線路頻寬不足。

標準加密通道帶來良好相容性的同時,也意味著握手與憑證相關問題會更加明顯。裝置時間異常、解析結果錯誤或中間網路未完整處理工作階段,都可能導致連線無法建立。它更適合基礎網路品質正常、希望使用穩定通用傳輸方式的使用者;若接取網路本身丟包嚴重,應先改善線路路徑,協定名稱無法消除底層資料反覆重傳的成本。

VLESS:精簡驗證,能力取決於組合方式

VLESS 將驗證部分做得更精簡,具體傳輸能力更多由外層組合決定。它本身不能脫離承載方式、加密通道與用戶端實作單獨評估。這種設計方便依情境組合,但也更要求兩端設定一致。伺服器使用哪種傳輸方式,用戶端就必須以相同方式發起工作階段;只複製位址而遺漏其他欄位,通常無法取得可用連線。

從選擇角度來看,VLESS 適合希望採用較輕量工作階段結構,同時由服務設定統一管理傳輸組合的情境。一般使用者不必逐項理解訂閱中的所有欄位,維持訂閱自動下發即可。進階使用者比較時,應將「VLESS 加上某種承載方式」視為完整方案,而不是只根據 VLESS 名稱判斷速度。外層組合不同,握手路徑、資源占用與故障表現都會改變。

Hysteria2 與 TUIC:面向波動鏈路的傳輸策略

Hysteria2 與 TUIC 都更重視在網路波動、丟包與行動切換環境下維持傳輸連續性。它們通常基於現代資料報傳輸能力,在壅塞控制、多路資料與連線遷移方面,採用不同於傳統可靠位元組流的處理思路。面對偶發丟包時,它們可能比依賴連續位元組流的方案更快恢復有效傳輸,尤其適合行動網路、跨區路徑與即時互動情境。

這項優勢並非在所有網路中都能成立。部分接取網路對資料報流量的處理較保守,公共無線網路也可能為長時間資料報工作階段設定較短的狀態保留時間。此時可能出現握手失敗、連線建立後很快失效,或背景恢復不穩定。Hysteria2 與 TUIC 也依賴用戶端網路堆疊與系統排程;若用戶端實作尚未成熟,理論上的傳輸優勢可能被背景策略抵銷。

協定 設計重點 較適合的條件 優先檢查項目
Shadowsocks 簡潔加密轉發 日常連線、裝置資源有限 用戶端實作與底層線路
VMess 完整驗證與多種承載組合 重視生態相容性與設定管理 傳輸欄位是否完整一致
Trojan 標準加密工作階段 基礎網路相容性良好 時間、解析與憑證驗證
VLESS 精簡驗證與外層組合 由訂閱統一管理傳輸方式 用戶端與伺服器組合的一致性
Hysteria2 波動鏈路與壅塞恢復 行動網路、跨區互動 資料報可達性與背景恢復
TUIC 現代資料報與多路傳輸 低等待互動與網路切換 系統網路堆疊與接取網路策略

協定表適合用來縮小範圍,不適合視為固定排名。實際選擇應同時考慮裝置、接取網路、線路拓撲與目標服務。若某個協定在目前環境中連線穩定、切換網路後能夠恢復,且目標應用程式表現正常,就沒有必要只因另一種協定較新而頻繁遷移。成熟的選擇追求可重複與可維護,而不是追逐名稱變化。

工作階段建立 SESSION

連線建立與資源占用

從點擊連線到應用程式可用

用戶端顯示「已連線」之前,通常要依序完成系統網路權限確認、網域解析、入口可達性檢查、傳輸層工作階段建立、協定驗證與本機路由接管。不同協定會將驗證、加密與資料通道安排在不同階段,因此連線失敗的位置也不一樣。若用戶端長時間停留在「連線中」,可能是入口沒有回應;若很快回傳驗證錯誤,表示網路已抵達伺服器,但帳戶或訂閱資訊未被接受;若顯示已連線卻無法存取目標服務,則要繼續檢查本機路由、解析與出口條件。

連線建立速度不應只靠點擊一次後的主觀等待來判斷。系統可能重用解析快取,也可能保留先前的工作階段狀態;用戶端剛啟動與從背景恢復時,路徑也不相同。更有價值的是觀察多種日常狀態:首次啟動能否連線、裝置休眠後能否恢復、無線網路切換後是否需要手動重新連線,以及行動數據與無線網路交替時應用程式是否中斷。能在這些狀態下穩定恢復的方案,通常比單次測試中建立較快的方案更適合長期使用。

可靠位元組流與資料報的差異

基於可靠位元組流的傳輸會維持資料順序,並在發現遺失時安排重傳。這對檔案完整性與多數網頁請求很重要,但當底層出現丟包時,後續資料可能需要等待前面的缺口補齊。若網路只是偶發抖動,這種等待通常很短;若跨區路徑持續丟包,等待就會反覆出現,表現為頁面載入階段性停住或影片緩衝突然下降。

現代資料報傳輸允許上層更靈活地組織多個資料流,並依壅塞狀態決定恢復方式。一個資料流的遺失不一定會阻塞其他資料流,因此在即時互動與多路請求中可能更有韌性。但它仍無法憑空修復不良線路:底層遺失的資料需要重傳,壅塞視窗也必須依網路容量調整。若接取網路對資料報支援不佳,建立工作階段本身就可能成為問題。選擇時應區分「恢復方式更靈活」與「任何網路都更快」。

處理器、記憶體與系統網路堆疊

協定的資源占用來自加密計算、資料複製、緩衝管理、規則比對與日誌記錄。桌面裝置通常有更充足的處理能力,差異多半體現在高吞吐傳輸或大量並行連線時;行動裝置則還要考慮背景排程與溫度控制。設定複雜的分流規則、長期保留詳細日誌、同時啟用多個網路延伸功能,都可能比協定本身消耗更多資源。排查資源問題時,不要只比較協定名稱,也應檢查用戶端是否載入過大的規則集、是否存在重複的本機代理,以及系統中是否有其他同時接管網路的應用程式。

記憶體占用通常與連線數量、緩衝區與規則資料有關。大量開啟的瀏覽器分頁、雲端同步、系統更新與媒體應用程式會同時產生連線,讓用戶端需要維護更多工作階段。若裝置明顯發熱或應用程式被系統回收,可先關閉不必要的背景傳輸、減少除錯日誌,再觀察現象是否改變。直接切換協定有時看似有效,實際上只是重新啟動工作階段並釋放舊連線,問題之後仍可能再現。

該如何理解加密開銷

加密必然需要計算,但在現代裝置上,影響體驗的往往不是「是否加密」,而是實作能否運用系統能力、資料是否反覆複製,以及線路是否造成大量重傳。一次有效傳輸只需完成必要處理;一條丟包嚴重的線路會讓相同內容被多次傳送,額外消耗處理器、網路與電量。因此,降低資源占用的首要方法通常是選擇穩定線路,而不是削弱連線保護。

不同用戶端實作之間也存在差異。有些實作直接呼叫系統網路框架,有些則自帶使用者空間網路堆疊;前者通常與系統權限及省電機制結合更緊密,後者可能提供更一致的跨平台行為。兩種路線沒有脫離環境後的絕對優劣。Windows、macOS、iOS、Android 與 Linux 對網路延伸功能、背景服務和路由管理的方式不同,同一協定在不同平台上的資源曲線自然不會完全一致。

若要比較資源占用,建議固定同一入口與同一目標應用程式,依序觀察啟動、持續使用、裝置休眠與網路切換。不要同時執行多個會接管系統網路的用戶端,也不要在比較期間不斷重新整理大型下載。目標不是取得脫離實際情境的峰值,而是確認協定在自己的裝置上能否穩定建立、持續傳輸並正常恢復。這樣的結果才具備選擇價值。

終端行為 MOBILE

行動裝置電量與背景恢復

耗電通常來自喚醒與重新連線

行動裝置網路工具的耗電不只來自加密計算,更常見的來源是頻繁喚醒、重建連線、弱訊號下的重複傳輸,以及背景應用程式持續連網。螢幕關閉後,裝置會降低應用程式活動頻率;如果工作階段需要不斷傳送維持連線的訊息,或接取網路頻繁變更位址,系統就可能反覆喚醒網路延伸功能。單次喚醒未必明顯,但持續發生會讓裝置難以進入低功耗狀態。

重新連線頻率與協定狀態管理有關,也直接受到無線網路品質影響。訊號在可用與不可用之間擺動時,用戶端可能不斷判斷舊工作階段是否仍然有效,並嘗試建立新的工作階段。此時改用恢復機制更靈活的協定可能改善體驗,但若根因是接取訊號不穩定,任何協定都必須承擔重新傳送與重新建立連線的成本。觀察耗電時應同時查看系統訊號、背景同步工作與用戶端連線紀錄,而不是只看協定名稱。

iOS 與 Android 的背景差異

iOS 通常透過系統網路延伸功能管理通道,應用程式介面進入背景後,實際處理流量的是受系統約束的延伸程序。系統會控制可用記憶體、執行時機與網路切換行為,因此用戶端是否正確實作隨選連線與狀態恢復非常重要。若應用程式介面被清除但連線仍存在,不代表用戶端異常;反過來,介面顯示舊狀態也不一定代表底層工作階段仍然有效,應以實際網路存取結果為準。

Android 裝置的背景策略因系統客製化而有所不同。省電模式可能限制用戶端的背景活動,系統也可能在記憶體壓力下結束相關程序。使用者應允許所用用戶端維持必要的背景執行,並避免多個 VPN 類應用程式同時爭用系統介面。若每次鎖定螢幕後連線都會中斷,優先檢查系統電量管理與背景權限;若只有從無線網路切換到行動數據時中斷,再檢查協定是否支援工作階段遷移,或能否快速重建連線。

行動切換時的位址變化

從無線網路切換到行動數據時,本機位址、出口位址與可用路徑都會改變。傳統工作階段通常會將連線綁定在原有路徑上,路徑變更後需要重新建立;支援連線遷移的現代傳輸可以嘗試保留工作階段脈絡,但仍要確認新網路允許相同類型的流量。遷移成功的好處是應用程式層不必重新發起全部請求;遷移失敗時,用戶端則應快速退回完整重新連線,而不是長時間維持已失效的舊狀態。

影片播放對短暫切換較寬容,因為播放器通常會保留緩衝;語音、遠端桌面與即時訊息更容易暴露切換問題。若使用情境以移動中的即時互動為主,可以優先測試 Hysteria2 或 TUIC,並確認所在接取網路能正常傳輸資料報。若主要是在固定無線網路中瀏覽網頁,Shadowsocks、Trojan、VMess 或 VLESS 的成熟實作也可能更省事。關鍵是依行動模式選擇,而不是預設新協定一定適合所有裝置。

減少背景負擔的實際方法

先關閉用戶端中不必要的詳細日誌與持續診斷,再檢查是否啟用了過於複雜的應用程式分流。規則越多,新連線到來時需要比對的條件就越多;規則更新也會增加網路與儲存活動。對只需要穩定連線的使用者而言,維持服務下發的預設設定通常更容易維護。若需要分流,應先依少量明確的應用程式設定,再逐步增加,不要一次匯入來源不明、長期未維護的大型規則集合。

其次,避免讓多個應用程式重複執行相同工作。系統級連線已接管流量時,瀏覽器中的另一層代理、開發工具裡的獨立代理,以及應用程式自帶的網路加速功能,可能形成多層轉發。多層轉發不一定更穩定,反而會增加解析、握手與故障定位難度。發現行動裝置發熱時,可暫時關閉額外網路工具,只保留一個用戶端與一個一般目標應用程式,觀察裝置待機與恢復情況。

現象 較可能的來源 優先動作
鎖定螢幕後連線消失 背景策略或程序被回收 檢查系統電量管理與背景權限
切換網路後長時間沒有流量 舊工作階段未遷移,也未及時重建 重新連線並比較其他協定
弱訊號環境下明顯發熱 重傳、重新連線與無線模組持續運作 先改善接取訊號,再比較線路
固定網路中仍頻繁喚醒 維持連線機制、背景同步或重複代理 減少日誌、規則與額外網路工具

LeeVPN 支援 Windows、macOS、iOS、Android 與 Linux,用戶端入口統一位於使用者面板。各平台應共用同一帳戶與訂閱規則,但不應期待背景行為完全相同。定位行動裝置問題時,最好先在另一台裝置或桌面系統驗證同一入口是否可用:若其他平台正常,重點檢查行動系統權限與背景管理;若所有平台在同一入口出現相似故障,再轉向線路與服務狀態判斷。

線路結構 TOPOLOGY

直連、中轉與專線如何改變體驗

拓撲描述的是路徑,不是協定

協定規定資料如何封裝與傳輸,線路拓撲則描述資料會經過哪些網路與節點。兩者經常被混為一談,但所處理的問題不同。相同協定可以運作於直連、中轉或專線線路上;同一種拓撲也可以提供多種協定入口。協定會影響握手、壅塞恢復與用戶端相容性,拓撲則影響實際路由、電信商互聯、跨區出口與故障範圍。判斷速度波動時,先區分是協定工作階段不穩,還是路徑本身發生變化。

線路名稱也無法完全代表每一段實體路徑。使用者到入口、入口到出口、出口到目標服務,可能由不同網路承載。所謂直連,通常是指入口直接抵達目標地區的服務端,不額外經過業務中轉節點;中轉則先進入較近或互聯品質較好的節點,再由該節點送往出口;專線則強調中間關鍵路徑採用更可控的承載方式。最終體驗仍會受到本地接取與目標服務影響。

直連:路徑簡潔,但取決於公網互聯

直連線路的優勢是結構簡單,少一次業務中轉就少一組排隊、處理與故障點。在公網互聯順暢、入口距離合適時,直連可以提供較自然的延遲與較高的傳輸效率。它適合網路條件穩定、目標地區路由品質良好的使用者,也適合作為排錯基準:如果直連與中轉都無法建立連線,問題可能位於裝置、帳戶或接取網路;如果只有直連出現波動,則更值得檢查公網路徑。

直連的限制是對電信商互聯與跨區路由較敏感。公網路由可能隨網路策略與壅塞狀況調整,同一地區不同接取網路前往入口的路徑也可能不同。某位使用者表現良好的直連線路,換到另一種接取網路後不一定維持相同結果。因此,直連不等於品質低,也不等於始終擁有最低延遲,它只是減少了業務中轉,剩餘路徑仍由多個網路共同完成。

中轉:以額外一跳換取更可控的入口

中轉線路通常會先將使用者流量送到接取品質較好的中轉節點,再從中轉節點前往目標地區。這麼做會增加一個處理環節,卻可能避開不理想的公網互聯。對使用者來說,中轉的價值不在於「路徑更短」,而在於可以分別選擇入口段與跨區段。若本地到遠端的直連品質波動明顯,而本地到中轉節點穩定,中轉就可能提供更平順的連線。

中轉也會引入新的容量限制。所有經過同一中轉節點的流量都要共用其計算資源、介面與上游路徑,壅塞可能發生在使用者到中轉、中轉內部,或中轉到出口的任一位置。出現問題時,可比較同地區的不同線路類型:若多個出口都在同一中轉入口上波動,問題可能集中於中轉段;若只有特定出口異常,則更可能位於後半段或目標服務附近。

專線:強調路徑控制與穩定邊界

專線線路通常會將關鍵跨區段置於更可控的網路承載上,減少公網路由變化帶來的不確定性。其主要價值是路徑穩定、壅塞管理更明確,而不是保證每次測試都得到最高峰值。對遠端辦公、長時間會議、持續傳輸與對抖動敏感的應用程式而言,穩定路徑往往比短時間速度更重要。專線仍需透過本地公網接取入口,也仍會受到使用者裝置與目標服務影響。

專線資源通常需要容量規劃。當大量需求同時集中於同一方向時,即使中間路徑可控,入口、出口或目標服務連線仍可能排隊。選擇專線時應關注使用時段內是否持續穩定,而不是只在閒置時測試一次。若專線連線穩定但特定應用程式仍然很慢,應繼續檢查目標服務地區、出口選擇與應用程式本身,不要預設專線能改變所有外部條件。

線路類型 路徑特徵 主要價值 常見限制 適用情境
直連 入口直接連接出口 結構簡潔、處理環節少 受公網互聯變化影響 網頁、下載、路徑基準判斷
中轉 先到中轉節點,再前往出口 最佳化入口與跨區路徑 中轉容量可能形成瓶頸 跨區存取、日常綜合使用
專線 關鍵區段採用可控承載 減少路徑變化與抖動 入口、出口與目標仍可能壅塞 辦公、會議、持續穩定傳輸

入口距離與出口地區要分開考量

入口決定使用者先連線到哪裡,出口決定目標服務看到流量從哪裡抵達。為降低前半段等待,通常優先選擇接近目前接取位置、互聯品質良好的入口;為符合內容地區或業務部署需求,再選擇適合的出口。若為了目標地區而直接選擇距離很遠的入口,可能讓整段路徑都承受跨區波動。中轉與專線的意義之一,就是將「容易接入」與「需要抵達」拆開處理。

查看 LeeVPN 的節點頁面時,可以依地區、城市與線路類型縮小範圍。不要在短時間內遍歷全部 200+ 條線路,而應先確定目標地區,再比較鄰近入口與不同拓撲。線路越多,越需要有條理地篩選。保留一條表現穩定的常用線路,再準備拓撲不同的備用線路,通常比每次隨機選擇更容易獲得一致體驗。

拓撲選擇的最終原則是「對實際路徑負責」。直連適合作為簡潔基準,中轉適合改善跨網與跨區入口,專線適合對抖動與路徑變化敏感的任務。任何類型都不是脫離時間、地點與目標服務後的固定優勝者。記錄同一情境下的連續表現,才能判斷額外中轉是否值得,以及專線路徑是否真正解決目前問題。

異常成因 LOSS

丟包、抖動與尖峰時段壅塞

丟包不只發生在遠端

資料封包可能在無線接取、本地路由裝置、電信商網路、入口介面、中轉路徑、出口網路或目標服務附近遺失。無線干擾造成的丟包通常伴隨訊號波動,離開目前無線環境後現象會明顯改變;本地裝置佇列過滿時,上傳工作可能讓其他請求等待;跨區路徑丟包則更容易同時出現在多台裝置與多個應用程式上。定位時應先判斷影響範圍,而不是一看到卡頓就切換遠端地區。

可靠傳輸會重傳遺失內容,因此使用者未必會看到明顯錯誤,更常見的表現是速度呈鋸齒狀變化、頁面偶爾停頓、語音出現斷續,或連線長時間使用後變慢。資料報傳輸可以採用更靈活的恢復策略,但同樣需要重新傳送關鍵內容。協定可以決定如何應對丟包,卻不能讓丟包本身沒有成本。持續丟包時,優先改善路徑通常比繼續增加並行連線更有效。

抖動比平均延遲更容易影響即時應用程式

抖動是指連續請求的等待時間變化。即使平均等待時間看似可以接受,若部分請求突然變慢,語音與遠端操作仍會出現明顯停頓。應用程式通常會用緩衝吸收變化,但緩衝越大,即時性越差;緩衝越小,又越容易暴露網路波動。隨選影片可以預先載入內容,因此對短暫抖動較寬容;即時會議與雲端互動則沒有足夠時間等待。

造成抖動的常見原因是佇列長度不斷變化。網路閒置時,請求可以快速通過;大量流量同時進入時,後續請求必須排隊。若路由裝置或線路採用過大的緩衝,資料雖然沒有立即遺失,卻會在佇列中等待很久,形成「速度還在,操作卻變遲鈍」的現象。此時只查看下載是否仍在進行,並不能說明線路是否適合即時應用程式,也應同時觀察語音、互動與小型請求的回應。

尖峰時段壅塞發生在哪裡

尖峰時段不是單一節點的固定故障,而是多項共享資源同時承受壓力的時段。家庭接取、電信商互聯、入口節點、中轉頻寬、出口線路與熱門目標服務都可能排隊。若同一接取網路存取多個方向都變慢,本地接取或電信商互聯更值得懷疑;若只有某一地區線路出現波動,問題可能集中在該方向的中轉或出口;若其他網站正常而某個熱門服務很慢,則要考慮目標服務本身的容量。

壅塞也會改變協定表現。可靠位元組流在丟包與排隊增加時會主動降低傳送速率,恢復需要一定時間;現代資料報協定可能採用不同的壅塞控制策略,更積極地探測可用容量。積極探測有時能更快恢復,也可能在共享網路中造成波動。沒有任何策略能繞過實際容量上限,差別只在於如何發現容量、如何退讓,以及何時恢復。

本地上傳為何會拖慢下載

在家庭網路或無線網路中,當上傳佇列被雲端同步、相片備份或檔案傳送占滿時,下載請求所需的確認資訊也必須排隊。結果看起來像遠端下載線路變慢,根因卻在本地上傳。視訊會議更容易受影響,因為同時需要穩定的上傳與下載。排查時應暫停大規模同步與備份,再觀察互動是否恢復;如果恢復,表示應處理本地佇列與背景工作,而不是繼續更換協定。

同樣情況也可能出現在區域網路的其他裝置上。LeeVPN 支援不限台數的同時在線裝置,但「不限台數」描述的是帳戶同時在線規則,不代表本地接取頻寬會隨裝置增加。多台裝置同時更新、備份或播放高位元率內容,仍會共用目前的網路容量。判斷線路前,應先確認區域網路中是否存在持續占用上傳或下載的工作。

如何區分短暫波動與持續故障

短暫波動通常會自行恢復,影響集中在某段傳輸或某次網路切換;持續故障則會在條件不變時重複出現。記錄「能否建立連線、一般網頁是否正常、即時應用程式是否受影響、切換拓撲後是否改變」,比只記錄一次速度結果更有意義。若重新連線後短暫恢復又反覆變慢,可能存在佇列或路徑壅塞;若始終無法完成握手,則應回到入口可達性與工作階段設定檢查。

還要避免將目標服務的內容載入策略誤判為線路丟包。串流影音會依緩衝與出口地區調整內容品質,AI 工具可能因服務端工作複雜度而等待回應,檔案站點也可能針對單一連線進行流量管理。可使用多個性質不同的目標交叉判斷:公共網頁、檔案傳輸與即時互動若同時異常,線路問題的可能性較高;只有單一服務異常,則應先檢查目標服務狀態與地區支援。

面對持續壅塞,合理的做法是縮短路徑、改變入口或選擇更可控的拓撲,而不是不斷增加並行請求。並行請求在閒置線路上可以提高利用率,在已經排隊的線路上卻可能進一步增加競爭。穩定連線的目標,是讓應用程式持續取得足夠的傳輸能力,而不是在短時間測試中把佇列塞滿。

選擇紀錄 SELECT

依使用情境組合協定與線路

日常網頁與綜合使用

網頁存取由許多短請求組成,既需要連線建立順暢,也需要解析與小型資料回應穩定。這類情境不必追求最複雜的傳輸組合,優先選擇用戶端支援成熟、在目前裝置上能正常恢復的協定。Shadowsocks、Trojan、VMess 與 VLESS 都能承擔日常連線,差異更多來自具體承載方式與線路品質。入口應先靠近目前接取位置,再依目標網站選擇出口地區。

如果網頁偶爾停住但檔案下載仍能繼續,應關注抖動、解析與佇列,而不只是吞吐量。若每次開啟用戶端都要等待很久,可比較握手路徑較簡潔的方案;若裝置經常在不同網路之間切換,則應觀察重新連線能力。最後保留一條常用線路與一條拓撲不同的備用線路,通常比維護大量隨機選擇更容易。

遠端辦公、會議與雲端協作

遠端辦公更重視連續性、低抖動與上行穩定。專線或品質穩定的中轉線路通常值得優先測試,因為它們能減少關鍵跨區段的路徑變化。協定方面,應選擇用戶端長時間運作可靠、網路切換後能快速恢復的方案。若接取網路正常支援資料報,可用 Hysteria2 或 TUIC 比較即時互動;若企業網路與標準加密連線相容性較佳,Trojan 或成熟的 VLESS 組合可能更容易建立連線。

辦公情境也應避免一邊工作一邊進行大規模測速。測速會占用共享線路容量,使會議與遠端桌面表現變差。更合適的驗證方式是觀察實際工作應用程式:登入是否穩定、語音是否連續、螢幕操作是否及時,以及檔案同步能否在背景完成。若即時應用程式異常而一般網頁正常,應優先更換拓撲或入口,不必先改動所有用戶端設定。

串流影音與長時間傳輸

串流影音對出口地區、持續吞吐與穩定緩衝較敏感。先確認目標內容在所選地區提供,再選擇對應出口。協定只要能穩定持續傳輸即可,線路容量與出口品質通常比握手差異更重要。公網路徑良好時,直連線路結構簡潔;中轉或專線則可能在跨區路徑波動時提供更平順的緩衝。可結合觀影解鎖頁面了解目標服務與地區選擇的關係。

長時間檔案傳輸還需要考慮工作階段中斷後的恢復。裝置休眠、無線切換或用戶端被系統回收,都可能讓傳輸重新開始。桌面端應避免在工作進行中讓系統進入深度休眠,行動裝置則要確認背景執行權限。若工作時間較長,選擇持續使用時表現平穩的線路,比追求短時間峰值更實際。

AI 工具與互動式開發

AI 工具同時包含短請求,也可能包含持續回傳內容、檔案上傳與網頁互動。使用者感受到的等待時間不完全來自網路,模型處理與服務端排隊也會占用時間。因此,應先確認一般網頁與帳戶登入正常,再判斷某次回應等待是否屬於線路問題。若只有生成過程很慢而介面操作正常,切換協定未必有幫助;若上傳、登入與串流回應都頻繁中斷,則應比較更穩定的線路拓撲。

出口地區需要符合目標工具的服務範圍與帳戶設定,頻繁在相距很遠的地區之間切換,可能觸發重新登入或工作階段確認。建議固定常用地區,保持瀏覽器與用戶端環境一致。更多情境說明可查看AI 工具專題。選擇時應重視連線連續性與出口一致性,而不只是比較單次頁面開啟速度。

行動使用與公共無線網路

行動使用最需要觀察網路切換與背景恢復。資料報環境正常時,可優先測試 Hysteria2 與 TUIC;Shadowsocks、Trojan、VMess 與 VLESS 則可作為相容性對照。公共無線網路的解析、工作階段維持與資料報支援可能不同於家庭網路,因此在一種網路中表現穩定的協定,換到另一種網路後仍需重新驗證。連線失敗時先更換協定類型,再更換入口,避免同時改變過多條件。

公共網路還可能要求先完成網頁驗證。若用戶端在驗證前接管全部流量,驗證頁面可能無法開啟。遇到這種情況,應先暫停連線,完成網路提供方的正常接入流程,再重新建立工作階段。驗證完成後仍無法連線,再檢查入口可達性與協定相容性,不要重複開啟驗證頁面。

情境選擇紀錄表

使用情境 優先觀察 協定方向 拓撲方向
網頁與綜合使用 握手、解析、小型請求回應 成熟的通用實作 鄰近入口,直連與中轉對照
辦公與會議 上行、抖動、持續連線 恢復穩定或支援遷移 穩定中轉或專線
串流影音 出口地區、持續吞吐 優先考慮穩定傳輸 目標地區出口
AI 工具 工作階段連續性、出口一致性 相容性與恢復能力 固定常用地區
行動網路 切換、背景、資料報可達性 現代資料報與通用協定對照 鄰近入口與備用路徑

帳戶與流量規則也是選擇條件

協定與線路解決的是連線方式,方案決定可用流量與重置規則。LeeVPN 月訂閱為 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB,流量依開通日每月重置,中途升級的差額會按剩餘天數折算。流量包為 ¥158/300GB、¥358/1000GB、¥658/3000GB,用完為止,永久不過期。使用頻率穩定可比較月訂閱,需要長期備用則可查看流量包。

所有方案支援不限台數的同時在線裝置,並提供 7 天無理由退款。付款方式為支付寶、微信與 USDT。建立帳戶不需要電子郵件地址,使用使用者名稱與密碼即可註冊。上述規則與協定選擇彼此獨立:更換協定不會改變方案流量,切換線路也不會延長週期。詳細差異請以方案頁面為準。

選擇的完成標準,不是找到理論上最先進的協定,而是確定一組可維護的組合:常用裝置能穩定運作,主要目標服務可存取,常用入口在實際時段表現一致,並且有拓撲不同的備用方案。完成這些條件後,應減少不必要的調整。頻繁追逐新組合會增加設定差異,也會讓故障發生時缺少穩定基準。

值班流程 DIAGNOSE

驗證連線與逐層排錯

先確認帳戶、訂閱與系統狀態

排錯應從最容易核對的條件開始。先確認帳戶能正常登入、方案狀態有效,以及用戶端使用的是最新取得的訂閱內容。若剛升級方案或調整訂閱,應在用戶端重新取得設定,而不是繼續使用舊的本機副本。接著確認系統已授予用戶端必要的網路權限,並關閉其他同時接管系統網路的應用程式。多個用戶端並行執行會導致路由互相覆蓋,表現可能是連線成功但流量走向不確定。

如果所有線路都無法建立連線,優先檢查本地環境;如果只有單一入口異常,再轉向該入口或路徑。若桌面端正常而行動端異常,應檢查行動系統的背景與網路延伸功能權限;若所有平台在同一接取網路都異常,但換到另一網路後恢復,問題更可能位於原接取網路。透過影響範圍縮小層級,比無序切換大量節點更有效率。

使用基礎指令驗證請求路徑

命令列工具適合確認網域能否解析、加密網頁是否回傳回應,以及問題是否只存在於某個瀏覽器。以下範例會存取公開測試網域,不包含帳戶、憑證或真實訂閱位址。指令成功只能表示目前請求取得回應,不能單獨證明所有應用程式與線路都正常;指令失敗時,則可根據錯誤訊息判斷問題出現在解析、連線還是憑證階段。

curl -I https://example.com
ping example.com

curl 回傳回應標頭,表示網域解析、建立連線與網頁加密工作階段至少完成了基本流程。若瀏覽器無法開啟而指令可以回傳,應檢查瀏覽器代理、擴充功能與快取。ping 使用的探測方式可能被目標或中間網路忽略,因此沒有回覆不一定表示網頁無法連線;它更適合作為觀察路徑變化的輔助工具,不應成為唯一判斷依據。對於不回應探測但網頁正常的目標,應以實際應用程式請求為準。

已連線但無法存取時的分支

用戶端顯示已連線,只代表協定工作階段已建立,不代表系統中每個應用程式都一定經過該工作階段。先造訪一般網頁,確認是否所有目標都失敗。若全部失敗,檢查本機路由與解析;若只有特定應用程式失敗,檢查該應用程式是否使用獨立代理、是否快取舊網路狀態,或目標服務是否支援目前出口地區。關閉並重新開啟目標應用程式,可以讓它重新建立連線,但不應先清除所有用戶端設定。

解析問題通常表現為網域無法開啟,而直接存取已知服務或其他網域正常。此時可先斷開再連線,讓系統重新套用用戶端提供的解析設定。若系統中曾手動設定固定解析服務,需確認它與目前網路路徑相容。不要同時疊加多個加密解析工具與系統級連線,否則請求可能沿不同路徑傳送,增加判斷難度。

連線一段時間後變慢

開始正常、之後變慢通常與佇列、丟包、背景工作或工作階段狀態有關。先暫停下載、雲端同步與系統更新,觀察互動是否恢復;再切換到同地區但拓撲不同的線路,判斷問題是否集中在某條路徑。若重新連線後立即恢復,過一段時間卻再次出現,應查看用戶端日誌中是否有頻繁重新連線、網路切換或工作階段逾時,而不是將短暫恢復當成問題已消失。

若只有晚間固定時段出現,使用前述方法比較直連、中轉與專線。不同拓撲的結果差異明顯,表示路徑容量可能是關鍵;所有拓撲同時下降,則還要檢查本地接取與目標服務。不要在壅塞時同時執行大規模測速與實際工作,測速本身會占用容量,使排查結果偏離日常使用。

協定切換應遵循固定順序

協定切換不是隨機嘗試。若目前協定無法完成握手,先選擇底層傳輸方式不同的方案進行對照;若握手正常但網路切換後無法恢復,可測試更擅長遷移或快速重建的方案;若固定網路持續穩定,則不必只因名稱更新而更換。每次切換都應保持入口地區與目標服務不變,確認現象後再繼續。如此才能知道變化來自協定,而不是路徑。

從可靠位元組流方案切換到 Hysteria2 或 TUIC 後仍無法建立連線,可能表示目前接取網路不利於資料報傳輸;反向切換後恢復,則可將通用協定作為該網路的常用方案。若所有協定在某個入口都失敗,但其他入口正常,更可能是入口或線路問題。若所有入口與協定都失敗,則回到帳戶、權限與接取網路層重新核對。

何時應提交工單

完成基礎排查後仍無法定位問題,可透過使用者面板提交工單。有效描述應包含裝置平台、用戶端使用的協定、入口地區、問題發生階段、目標服務類型、開始出現問題的環境,以及已完成哪些對照。不要提交帳戶密碼、訂閱位址或其他敏感憑證。若能說明「同一裝置更換接取網路後恢復」或「同一入口切換協定後現象不變」,服務支援就能更快判斷應檢查用戶端、入口還是線路。

若問題只發生在特定應用程式,也應註明一般網頁是否正常;若表現與使用時段有關,應說明是否在其他時段恢復;若行動裝置鎖定螢幕後中斷,應註明前景使用是否穩定。相較於「無法使用」這類籠統描述,明確的階段與對照結果更具診斷價值。工單入口位於使用者面板,用戶端取得與訂閱更新也應透過面板完成。

故障判斷速查

所有協定、所有入口都失敗
檢查帳戶狀態、訂閱更新、系統權限、接取網路與重複的網路工具。
只有某種協定失敗
檢查底層傳輸相容性、握手條件與用戶端對該協定的實作。
只有某個入口失敗
切換同地區的其他拓撲,判斷入口或路徑是否異常。
一般網頁正常,特定服務失敗
檢查出口地區、應用程式獨立設定與目標服務本身的狀態。
鎖定螢幕或切換網路後失敗
檢查背景策略、工作階段遷移與用戶端重新連線行為。
固定時段出現波動
比較不同時段與不同拓撲,判斷共享路徑是否壅塞。

想進一步了解桌面平台差異,可閱讀Windows VPN 推薦與軟體相容性比較macOS 網路延伸功能與相容性比較;行動端初次設定可查看Android VPN 新手完整指南。這些文章負責具體平台情境,本頁則保留協定、拓撲與排錯之間的統一判斷框架。

協定與線路選擇沒有脫離環境的固定答案。先確定問題層級,再以同一裝置、同一入口、同一目標進行單一變數比較;確認協定能穩定建立與恢復後,再比較線路拓撲;最後以實際應用程式的持續表現決定常用方案。依這個順序處理,連線問題就能從模糊感受轉化為可記錄、可複查的技術判斷。