線路與協定技術參考

01 · 分層

先把問題放回四層裡

同樣一句「線路不好用」，可能指向四個完全不同的位置。把它們分開，後面的判斷才不會互相打架。本頁是一份依選型順序組織的技術參考：先看路徑，再看協定，最後看裝置與用戶端。第一次使用建議先讀教學頁的主線步驟，把用戶端裝好、連上；遇到「為什麼這樣選」「為什麼時快時慢」再回到這裡查閱。

四層各自負責什麼

實體與路由層決定資料從本地到出口經過哪些城市、哪些電信商、在哪個交換點互連。它決定延遲的下限，也決定晚間尖峰時哪一段最容易排隊。換用戶端、換協定都改不了這一層的路徑。

傳輸層是 TCP 或 QUIC（UDP），以及它們背後的壅塞控制。它決定丟包之後怎麼補、視窗怎麼漲、多條請求怎麼共用一條連線。體感上的「忽快忽慢」，很大一部分來自這一層。

代理協定層是 Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC 這些名字。它決定認證方式、外層是否套 TLS、是否多工、額外標頭有多少。協定不改變實體路徑，但會改變握手次數、重傳策略與 CPU 開銷。

用戶端與裝置層包括系統版本、權限、Wi-Fi 訊號、路由器 NAT 表、省電策略、DNS 設定和 MTU。這一層最容易被忽略，因為換一台裝置後，前面的設定看起來完全一樣，表現卻不同。

幾個容易混淆的詞

節點是一台可連線的伺服器或入口；入口是用戶端先連到的位址；出口是存取目標網站時對方看到的位址；落地是出口所在的地區。線路是從入口到出口的路徑組合，可能直連，也可能經過中轉或專線。協定只描述用戶端到入口這一段怎麼通訊，入口之後走什麼路，由線路決定。

這張表只用於定位，不取代實際測試。每次只改一個變數，否則無法判斷是哪一項起了作用。

02 · 協定

六種協定的設計取捨

協定不是品牌，也不是越新越好。它是一組關於認證、加密、傳輸與多工的約定。下面依設計取捨來說明，不貼設定碼；具體用戶端裡的選項名稱可能不同，但判斷邏輯一致。

輕量轉發型：Shadowsocks 與 VLESS

Shadowsocks 的核心是簡單：用預共享金鑰做 AEAD 加密，把 TCP 與 UDP 請求轉發到出口。它沒有內建的多工，也沒有原生的 TLS 偽裝，開銷小、實作成熟，適合路由器、舊裝置或只需要穩定轉發的情境。代價是外層特徵不明顯，需要額外的外掛或中轉來補足；UDP 轉發是否可用，取決於伺服器與用戶端的具體實作。

VLESS 更像一個輕量的傳輸載體：本身不負責加密，把安全邊界交給外層 TLS 或 REALITY；協定標頭小、狀態少，搭配 XTLS 一類流量控制可以減少重複加密。它的優勢是高吞吐與低 CPU，適合長時間大流量；前提是外層設定正確。如果外層沒有可靠的 TLS，VLESS 並不會自動提供加密。

TLS 偽裝型：Trojan 與 VMess

Trojan 把認證放進 TLS 連線裡，外部看起來就是一次普通的 HTTPS 存取。它的強度取決於憑證、TLS 版本與伺服器設定，而不是協定名稱本身。適合有網域、有憑證、需要與一般網站共用入口的情境；設定不當時，握手失敗會比輕量協定更難排查。

VMess 使用使用者 ID 與時間戳做認證，請求標頭裡帶較多欄位，支援多工。它的相容性好，舊用戶端也能用；代價是標頭開銷與實作複雜度略高，對系統時間敏感。裝置時間偏差較大時，可能出現「設定沒錯但就是連不上」的情況。

QUIC 型：Hysteria2 與 TUIC

Hysteria2 基於 QUIC（UDP），把壅塞控制做得更積極，在丟包較多、RTT 較高的鏈路上更容易把頻寬跑起來。它支援連線遷移，手機從 Wi-Fi 切到行動網路時，連線不必完全重建。代價是對 UDP 品質敏感：如果本地網路或電信商對 UDP 有限速或丟包，體驗會明顯下降；QUIC 在使用者空間處理，CPU 與電量開銷通常高於輕量 TCP 協定。

TUIC 同樣走 QUIC，強調 0-RTT、多工與連線遷移，適合頻繁切換網路、需要快速恢復的情境。它相對較新，不同用戶端的實作差異更大；遇到問題時，先確認用戶端版本與 UDP 是否可達，再判斷線路。

選擇時的三個誤區

只看協定名稱，不看外層。VLESS 沒有 TLS 就沒有加密；Trojan 的強度取決於憑證與 TLS 設定；Shadowsocks 的外掛決定它在外網看起來像什麼。協定名稱只是入口，安全邊界在外層。

把多工當萬靈丹。多工減少握手，但一條 TCP 連線上的隊頭阻塞會影響所有流；QUIC 的多工沒有 TCP 隊頭阻塞，卻受 UDP 品質影響。互動式瀏覽與大檔案下載，適合的連線策略並不相同。

忽略用戶端實作。同一個協定在不同用戶端上的壅塞控制、緩衝區、日誌等級與電量策略都不同。遇到「同一線路，換用戶端就正常」，問題往往在實作，不在協定本身。

03 · 握手

連線建立與首包時間

「開啟網頁要等幾秒」和「下載大檔案很慢」是兩件事。前者多半卡在連線建立，後者才看吞吐。把首包時間拆開，能快速判斷慢在哪一段。

一次存取要經過幾次握手

用戶端先做 DNS 解析，把網域換成 IP；然後與入口建立 TCP 連線，完成三次握手；如果外層是 TLS，再做 TLS 握手；接著是代理協定自己的認證與請求標頭；入口把請求轉發到出口，出口再與目標網站做一次 DNS、TCP 與 TLS。使用者看到的「首包」，是這些步驟疊加後的結果。

其中，本地 DNS 與到入口的 RTT 通常較短，入口到出口、出口到目標的路徑更長。也就是說，首包慢不一定是你到入口慢，也可能是出口到目標那一段在排隊。反過來，如果入口就在附近、出口也在目標附近，首包會明顯更短。

連線重用與 0-RTT

瀏覽器和用戶端都會重用連線：HTTP/2 在一條 TCP 上跑多條請求，HTTP/3 在一條 QUIC 連線上跑多條流，代理用戶端也可能把多個請求多工到一條隧道。重用減少了握手次數，但把多條流綁在同一條連線上；一旦底層丟包，TCP 上的所有流都要等重傳，QUIC 則只影響具體的那條流。

TLS 1.3 與 QUIC 支援工作階段恢復，第二次連線可以用 0-RTT 提前發送資料。它確實能減少一個往返，但不是無條件更快：伺服器可能拒絕 0-RTT 資料，部分網路也會對重放保護更謹慎。把 0-RTT 當成「一定更快」，容易誤判。

時間、DNS 與 MTU

時間同步影響 VMess 的時間戳認證，也影響 TLS 憑證有效期判斷。裝置時間偏差較大時，表現為「設定正確但握手失敗」。開啟系統自動時間，是最省事的排查。

DNS 決定第一次解析要等多久，也決定解析到哪個入口。瀏覽器自己的 DoH 可能繞過系統 DNS，導致用戶端與瀏覽器看到不同的位址；排查時先確認是誰在解析。

MTU 是封裝後仍能通過的最大封包長度。代理會在原始資料外再加一層標頭，如果路徑 MTU 較小，大封包可能被丟棄，表現為「小頁面能開、大檔案卡住」或「TLS 握手完成、資料不動」。這類問題常被誤判成線路慢。

curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' https://example.com

這條指令只測一個公開範例站，不包含任何帳號資訊。dns 是解析耗時，connect 是 TCP 握手，tls 是 TLS 握手，first 是首位元組，total 是整體。多跑幾次取中間值，比單次結果更有參考意義。

04 · 資源

資源佔用與行動端電量

協定比較裡常寫「輕量」「高效」，但資源佔用不是一個單一數字。它至少包括 CPU、記憶體、網路喚醒次數與電量策略。同一款協定，在桌上型電腦和舊手機上的表現可能完全不同。

CPU 花在哪裡

第一是加密。支援 AES 硬體指令的裝置，跑 AES-GCM 的代價很低；沒有硬體加速時，ChaCha20 一類串流加密通常更省。第二是 TLS：握手、憑證驗證、記錄層加解密都要算力。第三是 QUIC：它在使用者空間實作，包含壅塞控制、重傳、流管理，CPU 開銷通常高於核心裡的 TCP。第四是多工與日誌：連線越多、日誌越詳細，開銷越大。

因此，「VLESS 比 Trojan 輕」只在特定外層與特定用戶端上成立；「Hysteria2 在弱網更快」也不等於它在所有裝置上都更省電。判斷時要看完整鏈路，而不是只看協定名稱。

電量花在哪裡

行動端電量主要不是被加密算力吃掉的，而是被無線模組的喚醒次數吃掉的。每一次心跳、每一次重連、每一次 DNS 查詢，都會讓行動網路或 Wi-Fi 模組從低功耗狀態醒來。心跳間隔太短，裝置頻繁醒來；間隔太長，又可能被 NAT 逾時切斷，下一次請求要重建連線。用戶端的預設值通常是折衷，不建議為了「保持在線」把心跳調得很積極。

網路切換也會耗電：手機從 Wi-Fi 走到行動網路，再走回 Wi-Fi，TCP 連線可能中斷，用戶端要重連；QUIC 的連線遷移可以減少重建，但遷移本身也要處理加密狀態與路徑驗證。省電策略、背景限制、低電量模式都會影響用戶端能否在背景維持連線。

依裝置與情境取捨

VPNVL 的月訂閱不限裝置數，可以在多台裝置上同時使用；但每台裝置的電量與效能仍是獨立問題，不能互相替代。

減少無謂消耗的幾個習慣

第一，按需分流：只讓需要的應用走代理，其餘直連，減少不必要的加密與轉發。第二，避免雙重代理：代理套代理會讓每個封包多走一次加密與轉發。第三，關閉詳細日誌：排錯時再開，平時保持預設。第四，別把「始終開啟」當成唯一目標：插電裝置可以常開，電池裝置更適合按需開啟。第五，定期更新用戶端：壅塞控制、重連策略與電量優化都在版本裡迭代，但不要盲目追新，穩定版本優先。

05 · 拓撲

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

線路拓撲描述的是「從入口到出口怎麼走」。它比協定名稱更直接地決定延遲、抖動與晚間尖峰表現。VPNVL 的節點頁把線路標成直連、中轉與 IEPL 專線三類，原因就在這裡。

直連：路徑最短，但依賴互連品質

直連是用戶端直接連到出口節點，入口與出口是同一台伺服器或同一個機房。它的優點是路徑短、握手少、實作簡單；缺點是中間段完全依賴本地電信商與目標機房之間的互連品質。互連好時，直連很乾淨；互連差或晚間尖峰排隊時，直連也會抖。直連適合距離較近、目標網站與出口地區匹配的情境。

中轉：多一跳，換更穩的中間段

中轉是用戶端先連到入口，入口再把流量轉到中轉節點，最後由中轉節點到出口。它比直連多了一跳，理論上會增加一點延遲；但中轉節點通常選在互連更好的位置，可以把「本地電信商到國際段」這一段換成品質更可控的路徑。中轉的價值不在最短，而在穩定：當直連在晚間尖峰抖動時，中轉往往更平順。

中轉也有前提：入口要離使用者近，中轉段要有足夠頻寬，出口要符合目標網站的要求。任何一段壅塞，都會把優勢抵消。所以「中轉」不是一個固定品質，而是一套路徑設計。

專線：固定通道，穩定優先

IEPL 專線是在入口與出口之間走一條相對固定的通道，不與其他一般流量爭搶同一段公共互連。它的優勢是抖動小、晚間尖峰更穩，適合長時間會議、跨境辦公、對斷線敏感的業務。代價是成本更高，而且它只覆蓋「入口到出口」這一段：使用者家裡的 Wi-Fi、本地電信商、目標網站都不在專線範圍內。

因此，專線不是魔法。如果本地寬頻已經壅塞，或者 Wi-Fi 訊號很差，專線也救不了最後一段。正確的預期是：專線把中間段的不可控性降下來，把問題收斂到本地與目標兩側，便於排查。

為什麼同一線路在不同城市表現不同

因為「最後一哩」不同。不同電信商、不同社區、不同接取方式，到同一個入口的路徑與互連品質都不同；同一座城市裡，光纖與行動網路的表現也可能相反。節點頁給出的是線路類型與覆蓋地區，不是每個使用者家裡的保證值。選線時，先看入口是否離自己近，再看中間段是否穩，最後看出口是否符合目標網站的地區要求。

06 · 壅塞

丟包與晚間尖峰壅塞

延遲、抖動、丟包、吞吐是四個不同指標。延遲是資料走一趟要多久；抖動是延遲的波動；丟包是封包沒有到達；吞吐是單位時間能送多少。晚間尖峰最常見的不是「伺服器壞了」，而是某一段鏈路排隊，導致延遲上升、丟包增加、吞吐下降。

丟包為什麼會拖慢一切

TCP 把丟包當成壅塞訊號：一旦偵測到丟包，就減小壅塞視窗，降低發送速度，然後慢慢再漲回去。鏈路 RTT 越長，恢復越慢；丟包越頻繁，視窗越難漲起來。QUIC 也會重傳，但它把每條流分開處理，一條流丟包不會讓所有流一起等；不過在 UDP 被限速或丟包嚴重的網路裡，QUIC 的優勢也會被抵消。

所以，「1% 丟包」對不同業務的影響完全不同：即時語音可能只是偶爾卡頓，大檔案下載卻可能明顯掉速，互動式網頁則表現為「點一下等半天」。不要用一個 ping 結果概括全部體驗。

晚間尖峰的常見成因

第一，國際段壅塞：晚間尖峰跨境流量集中，公共互連排隊，延遲與丟包一起上升。第二，家庭上行被佔滿：家人看影片、上傳備份、下載更新，都會讓路由器佇列變長。第三，Wi-Fi 干擾：鄰居頻道重疊、距離遠、牆體阻擋，表現為丟包與抖動。第四，路由器 NAT 表或工作階段數吃緊：舊裝置在大量連線下會變慢。第五，MTU 不匹配：大封包被丟，小封包正常。第六，UDP 被限速：QUIC 類協定在部分網路裡反而不如 TCP。

還有一種常被忽略的情況是緩衝區膨脹：路由器的緩衝區很大，排隊時延遲升高，但封包沒有丟，測速看起來還行，體感卻很卡。這類問題要靠路由器上的佇列管理或限速來緩解，換協定幫助有限。

怎麼判斷是不是晚間尖峰壅塞

先記錄時間：只在 19:00 到 23:00 變差，白天正常，更像共享鏈路壅塞；全天都差，更像本地網路、入口選擇或裝置問題。再換變數：同一時間換一種線路類型，如果中轉或專線明顯更穩，說明問題在中間段；如果所有線路都一樣，優先查本地。然後換介質：有線對比 Wi-Fi，排除無線干擾。最後換協定：TCP 與 QUIC 各試一次，判斷是不是 UDP 被限速。

排查時可以用系統內建的網路診斷、路由追蹤工具觀察路徑是否變化，但不要把單次 ICMP 延遲當成結論：ICMP 可能被限速或走不同佇列，只能作為參考。更重要的是「同一時間段、同一目標、不同線路」的對比。需要確認目前出口位址，可以用網路檢測頁查看。

07 · 選型

依情境選協定與線路

沒有一套設定適合所有情境。選型順序建議是：先定線路，再定協定，最後調用戶端。線路決定路徑與穩定性，協定決定握手、開銷與弱網表現，用戶端決定這些能力能不能發揮出來。

AI 工具與長連線

ChatGPT、Claude、Gemini 這類工具的共同點是「長時間保持一條連線，然後持續接收串流回應」。它們對首包不算極端敏感，但對中途斷線、重新認證很敏感。選型時優先穩定：中轉或專線 + Trojan/VLESS over TLS，減少連線重建；不要在對話中途頻繁切換節點。出口地區要符合服務要求，否則可能遇到地區限制。更多細節可以看ChatGPT 用 VPN 推薦這篇。

串流媒體與 4K

串流媒體看的是持續吞吐與出口 IP 的信譽。直連或中轉都可以，關鍵是出口地區與目標平台匹配，且線路在晚間尖峰有足夠餘量。Hysteria2 在丟包較多的鏈路上可能更穩，但如果平台對 UDP 或機房 IP 有限制，換回 TCP 類協定更省事。VPNVL 的解鎖支援頁依平台列出了可用地區，選之前先對照。

跨境辦公與會議

會議對抖動最敏感，對絕對延遲反而沒那麼敏感。IEPL 專線的價值在這裡最明顯：固定通道減少排隊，長時間連線不容易斷。協定選 TCP 類的 Trojan 或 VLESS，搭配用戶端的分流，把內網與本地服務排除在代理之外，減少不必要的轉發。出差情境可以看出差 VPN 推薦裡的用量估算與核對清單。

行動端與遊戲

手機經常在 Wi-Fi 與行動網路之間切換，支援連線遷移的 QUIC 協定更省心；但如果不確定 UDP 是否被限速，先準備一套 TCP 備用。遊戲看延遲與抖動，選離自己近的入口、出口與遊戲伺服器同區，優先有線或 5GHz Wi-Fi；不要在背景同時跑下載。

預算與方案怎麼配合

選型不只發生在用戶端裡，也發生在購買時。VPNVL 的月訂閱依開通日每月重置流量：¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB；流量包是用完為止、永久不過期，¥158/300GB、¥358/1000GB、¥658/3000GB。用量穩定就選月訂閱，用量忽高忽低或想留餘量就配流量包。預算有限時，可以先看十元價位能買到什麼，再決定組合方式。

什麼時候該換服務商

如果所有線路、所有協定、所有裝置在同一時間都不可用，先查本地網路與帳號狀態；如果只有某一條線路長期不穩，換線路；如果只有某一個協定在特定網路下不行，換協定；如果所有線路在晚間尖峰都長期壅塞，而其他時間段正常，才需要考慮服務商的容量。把「換服務商」當成第一反應，通常會錯過更簡單的修復。

08 · 排查

分層排查流程

排查的目標不是「把所有設定都試一遍」，而是用最少的變數定位問題。下面五步依序走，每一步都留下記錄；如果五步之後仍未解決，帶著記錄聯絡支援，比一句「連不上」有效得多。

1. 界定範圍。是單一裝置還是所有裝置？是單一網站還是所有網站？是全天還是晚間尖峰？把這三個問題答完，問題已經縮小一半。
2. 檢查本地。有線與 Wi-Fi 各試一次；確認系統時間自動同步；確認沒有同時開兩個代理；確認 DNS 沒有被瀏覽器或安全軟體改寫；確認路由器沒有跑滿上傳。
3. 只換一個變數。先換線路，再換協定，再換裝置。每換一次，記錄結果。不要同時改線路、協定和 DNS，否則無法判斷哪一項起了作用。
4. 看日誌。用戶端日誌裡的握手失敗、DNS 逾時、TLS 錯誤、連線重置，比「打不開」更有資訊量。截圖或複製日誌前，先遮掉訂閱位址與權杖。
5. 帶資訊求助。時間、裝置與系統、線路名稱、協定、錯誤提示、已經嘗試過的步驟。資訊越具體，定位越快。

常見現象與處理

連上但打不開網頁。先看 DNS：瀏覽器自己的 DoH 可能繞過用戶端；再看系統代理是否只開了一半；最後看 MTU，尤其是小頁面能開、大頁面卡住的情況。

只有某個應用不行。檢查分流規則是否把這個應用排除了；有些應用使用憑證綁定，不接受代理憑證；有些應用只走 UDP，而目前線路的 UDP 不可用。

頻繁斷線。手機省電策略、Wi-Fi 漫遊、NAT 逾時、心跳間隔都可能是原因。先關掉省電限制，再換網路對比；如果只在行動網路斷，優先考慮連線遷移能力更強的協定。

速度慢。先分清首包慢還是吞吐低；再看裝置 CPU 是否跑滿；再看 Wi-Fi 訊號與路由器；最後換線路類型。不要只盯著協定名稱。

安全與隱私邊界

排查時不要把訂閱位址、權杖、完整日誌原樣發到公開群組或截圖裡。VPNVL 不記錄日誌，但訂閱位址本身就是存取憑證；把它當作密碼看待。需要協助時，只提供線路名稱、協定、錯誤類型與時間，不提供憑證。

常見問題