線路與協定:選型技術參考

六種協定的設計取捨

這六種協定在用戶端裡通常是並列的選項。它們不是新舊替代關係,而是針對不同限制做出的不同取捨:有的把開銷壓到最低,有的把相容性做到最好,有的專門為丟包環境設計。理解取捨,比記住「哪個更強」有用得多。

Shadowsocks:輕量與直接

Shadowsocks 的設計目標很單純:用盡量少的開銷把 TCP 與 UDP 流量加密轉發出去。它用預共享金鑰派生工作階段金鑰,對每個資料封包做 AEAD 加密,不內建複雜的認證握手,也沒有伺服器端的使用者體系。結果是首包開銷小、伺服器端資源佔用低,適合單人或少量裝置使用。代價是它不具備偽裝層:流量形態就是一段加密的 TCP 流,和一般 TLS 網頁流量不同。需要額外一層 TLS 時,通常由用戶端外掛或外層轉發來做。

VMess:帶使用者體系的封裝

VMess 在協定標頭裡帶了使用者識別碼與時間戳,伺服器端據此判斷請求是否合法、屬於哪個使用者。這讓它天生適合多使用者與多裝置情境:同一個入口可以依使用者分流、分別計量。代價是標頭比 Shadowsocks 大一些,而且對時間敏感——用戶端與伺服器端的時間偏差超過允許範圍時會直接連不上,表現為「節點測試逾時」但網路本身正常。遇到這種提示,先把裝置時間設為自動同步,再重試。

Trojan:走標準 TLS 的那一類

Trojan 把認證資訊放在 TLS 握手之後的應用資料裡,連接埠通常用 443,握手過程與造訪一個 HTTPS 網站沒有差別。它的優勢是相容性好:中間設備看到的就是一條標準的 TLS 連線。代價是必須維護憑證與網域,憑證過期或被替換會直接導致連線失敗;TLS 握手本身也帶來一次往返的開銷,首包延遲比純 TCP 的 Shadowsocks 略高。

VLESS:把加密交給 TLS

VLESS 去掉了協定自帶的加密層,只保留輕量的標頭與認證,加密完全交給外層 TLS 或 REALITY。好處是伺服器端 CPU 開銷更小、標頭更短,在高吞吐情境下更容易跑滿頻寬;壞處是它必須搭配一個可靠的外層,單獨使用沒有意義。對一般使用者來說,VLESS 與 Trojan 的體感差異通常小於線路差異,不必為此反覆切換。

Hysteria2:為丟包環境設計

Hysteria2 以 QUIC 為基礎,跑在 UDP 上,自帶壅塞控制與頻寬協商。它的強項是高丟包、長距離鏈路:TCP 在這種鏈路上會因為丟包反覆縮小壅塞視窗,Hysteria2 則可以在使用者空間用更適合的演算法維持吞吐。代價有三點:UDP 在部分網路裡會被限速甚至丟棄;行動網路切換時連線需要重建;UDP 類流量對 MTU 更敏感,分片設定不對會表現為「能連上但大檔案傳不動」。

TUIC:QUIC 上的多工

TUIC 同樣以 QUIC 為基礎,重點在多工與連線遷移:一條 QUIC 連線裡可以並行跑多個請求,單一請求丟包不會阻塞其他請求;從 Wi-Fi 切到行動網路時,QUIC 的連線識別碼可以讓工作階段延續,不必重新握手。它的適用情境與 Hysteria2 接近,差異更多體現在用戶端的壅塞控制實作上。同樣受 UDP 可用性限制,網路不放行 UDP 時兩者都用不了。

如果只記一條:TCP 類協定決定「穩不穩」的下限由線路給出,UDP 類協定決定「丟包時還能不能跑」。選協定之前先看線路,順序反了會在錯誤的維度上反覆嘗試——把一條晚高峰壅塞的直連線路,從 Trojan 換到 VLESS 再換到 Hysteria2,體感通常不會有本質上的變化。

連線建立速度與資源佔用

開啟一個網頁很慢,多數人第一個反應是頻寬不夠。實際上更常見的原因是往返次數:每次新建連線都要走一遍握手,握手需要往返,往返時間由物理距離和路徑品質決定。頻寬決定「傳得多快」,往返決定「多久開始傳」。

一次完整的 TCP 加 TLS 連線大致是這樣:先解析網域(可能一次往返),TCP 三次握手(一次往返),TLS 1.3 握手(一次往返,工作階段重複使用時可以省掉),接著是協定本身的認證,最後才是 HTTP 請求。也就是說,冷啟動一個網域至少要好幾個往返;頁面裡引用了幾個不同網域,就要重複幾遍。這就是為什麼「頻寬很大但首屏很慢」的情況並不少見。

QUIC 把傳輸握手與 TLS 握手合併,首次連線一次往返,工作階段恢復可以做到 0 次往返就帶上資料。這是 UDP 類協定在「開啟網頁的第一下」感覺更快的主要原因,和頻寬無關。代價是 UDP 一旦被網路限制,這條路徑直接不可用,沒有降級空間。

資源佔用分兩端看。用戶端側,加解密是主要 CPU 開銷:AES 系列在支援硬體加速的處理器上開銷很低,在部分行動端處理器上 ChaCha20 更省。伺服器端側,主要開銷是並發連線數乘以每條連線的記憶體,以及 UDP 類協定需要維護的工作階段表。多工能減少連線數,但也意味著單條連線上要維護更多狀態,用記憶體換往返。

一個容易被忽略的重點:用戶端裡的「延遲測試」測的是到入口的一次探測往返,不是到落地的往返,也不是網頁載入時間。入口近、落地遠的時候,測試數字很好看,實際開啟網頁仍然慢。判斷真實體感要看完整載入與影片緩衝,而不是那一個數字。

行動端電量與流量開銷

手機上的耗電來自三處:無線電模組被反覆喚醒、加解密佔用 CPU、斷線重連。三者和協定、線路都有關,但權重不同。多數人以為是「加密太耗電」,實際上最常見的耗電來源是心跳與重連。

先看心跳。為了不讓網路位址轉換表項過期,用戶端會定期發一個小封包保活。間隔太短,無線電模組頻繁從閒置狀態喚醒,耗電明顯;間隔太長,連線被中間設備回收,下次要用時得重連,重連又觸發一次完整握手。合適的間隔取決於所在網路的表項逾時時間,家用寬頻、公司網路、電信業者網路各不相同,用戶端通常給一個保守預設值,並提供可調項目。拿不準就先用預設值,只在明顯異常時再調。

再看重連。行動網路下最貴的操作就是重連:從 Wi-Fi 切到行動數據、進出電梯、捷運隧道,都會觸發。TCP 類協定在網路切換後必須重新握手;QUIC 類協定可以靠連線識別碼遷移工作階段,但前提是新路徑可達、且中間設備沒有攔截 UDP。所以「行動端用 UDP 類更省電」這個說法只在一定條件下成立:切換頻繁且 UDP 可用時成立,反之重連更多、更耗電。

系統背景限制也要算進去。iOS 與 Android 都會在螢幕關閉一段時間後暫停背景應用程式,用戶端被暫停後連線自然斷開。這不是協定問題,任何協定都一樣。需要長期在線的情境,應該用系統的隨需連線類功能,讓系統在網路變化時喚醒用戶端,而不是讓用戶端自己一直跑著等。

流量開銷方面,協定標頭本身佔比很小,真正影響流量的是重傳與心跳。丟包嚴重的線路上,重傳會把實際消耗推高到遠超預期;心跳封包雖然小,一天幾百次也是量。流量包按用量計費時這兩項值得注意:VPNWu 的流量包用完為止、永久不過期,月訂閱的流量依開通日每月重置,兩種計費方式下都建議在用戶端裡看一眼實際用量,和自己估計的對一對。

怎麼自我檢查。用系統內建的電池用量統計,比較「連線狀態下待機一段時間」與「未連線狀態下待機同樣時間」的耗電差異;再看用戶端的連線日誌,統計這段時間裡重連了幾次。如果重連次數多,換線路類型通常比換協定更有效——先把路徑穩定下來,再談封裝方式。

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

線路是這一頁裡對體感影響最大、卻最少被討論的部分。協定決定封裝方式,線路決定資料實際走哪條路。同一條家用寬頻,接上不同線路,晚高峰的體驗可以差出一個量級,而用戶端的協定選項一個都沒變。

直連

直連指入口與落地在同一處,資料從使用者端直接到達落地機房。路徑最短,理論上延遲最低。它的短處是品質完全取決於這段公共鏈路的狀況:晚高峰壅塞時,直連線路和一般國際存取一起排隊,抖動會明顯變大。直連適合對延遲敏感、但對晚高峰穩定性要求不高的情境,例如白天辦公、臨時查資料。

中轉

中轉在使用者與落地之間加一個入口節點:使用者先連到離自己近的入口,入口再透過服務商自己的鏈路把流量送到落地。多了一跳,理論上多幾毫秒,但去程那一段被換成品質更可控的鏈路,晚高峰的抖動通常比直連小。中轉型線路之間的差異主要在中轉節點的頻寬與調度策略上,挑選時看的是營運方的容量,不是節點數量。

專線

專線指入口到落地之間走點對點的專有通道,不與公網流量共享壅塞。它的特徵是延遲穩定、抖動小、丟包率低,代價是成本高,通常只放在熱門落地上。對視訊會議、即時協作、長時間穩定連線這類情境,專線的價值不在峰值頻寬,而在於「晚高峰也不掉」。如果只是偶爾看影片,專線帶來的提升不一定能被感受到。

選線的順序建議是:先定落地地區(內容與服務在哪),再定線路類型(是否需要在晚高峰保持穩定),最後才是協定。反過來先挑協定,很容易在一條本來就壅塞的線路上反覆換封裝,花時間但沒效果。線路頁上每條線路帶一個類型標籤,標籤描述的就是上面三類之一;看到「中轉」不要理解成「多繞一圈所以更慢」,它最佳化的是去程那一段。

丟包與晚高峰壅塞的成因

丟包不是一種故障,而是一種常態。鏈路上任何一段的佇列滿了,後來的封包就會被丟掉;無線環境裡的干擾也會造成丟包。問題不在於有沒有丟包,而在於丟包發生在哪一段、持續多久、以及協定怎麼應對。

常見的來源有四類。本地無線:Wi-Fi 干擾、距離遠、頻道擁擠,表現是所有線路都慢,換線路無效。家用寬頻上行:上傳跑滿時下行也會受影響,因為確認封包送不出去,表現是下載時卡頓。國際鏈路峰值:晚間跨境方向流量集中,公共鏈路排隊,表現是固定時段變慢、其他時段正常。落地機房出口:落地側頻寬被佔滿,表現是某一條線路慢,換同地區的其他線路正常。

TCP 對丟包的反應很劇烈:偵測到丟包就把壅塞視窗減半,然後慢慢加回來。短連線受影響最大——一個網頁的十幾個請求都擠在一條連線上,一次丟包就讓整條連線一起等重傳。QUIC 把這個問題依流拆開:一條流丟包,其他流照常推進,所以 UDP 類協定在丟包環境下的體感通常更平順。

晚高峰的形態不是「完全不能用」,而是延遲上升、抖動變大、影片自動降低位元率。這個時段最有效的做法是換線路類型(直連換中轉或專線),而不是換協定。因為瓶頸在路徑的壅塞,不在封裝;換協定只是換了一種排隊方式,佇列本身沒變短。

分層排查的順序

從近到遠:先看本地閘道是否穩定,再看入口是否可達,最後看落地。三段裡哪一段開始出現持續丟包,問題就在那一段之後。命令列的 mtr 能把每一跳的丟包列出來,連續跑幾十次比跑一次有意義得多。

# 1. 先確認本地閘道穩定(把範例位址換成自己路由器的位址)
ping -c 20 192.168.1.1

# 2. 再看跨境路徑每一跳的丟包與延遲,連續取樣 50 次
mtr -rwzc 50 example.com

# 3. 換一條線路重複上面兩步,比較同一時段的差異

取樣方法也要統一:同一時段、同一目標、至少三輪,每輪 50 次;記錄平均值、最大值與丟包率。只看一次結果容易被瞬時抖動誤導。也不要拿不同時段的兩條線路直接比較——晚高峰與凌晨之間的差異,可能比兩條線路之間的差異還大。

依使用情境選協定

前面幾章拆開講,這一章合起來用。選型的順序是:情境 → 線路類型 → 協定 → 用戶端設定。順序顛倒會把簡單問題複雜化,例如先認定要用某個協定,再去找一條能跑它的線路,最後發現線路本身在晚高峰就撐不住。

網頁與辦公

網頁瀏覽的特徵是短連線多:一個頁面要開十幾個連線,每個都要握手。這時候首包延遲比頻寬重要,線路的往返時間比峰值速率重要。協定層面選標頭開銷小的(Trojan、VLESS),體感差異主要來自線路。如果辦公系統裡有大量小檔案上傳下載,再看一眼上行——上行壅塞會連帶影響下行。

視訊會議與即時語音

會議流量是雙向的、持續的,對抖動比對頻寬敏感。抖動大的時候聲音會斷斷續續、畫面會卡住再追上。UDP 類協定在丟包時的平順性更好,搭配專線或品質較好的中轉線路,是這一類情境的首選。如果所在網路不放行 UDP,退回 TCP 類協定也能用,只是丟包時更容易出現整段卡頓。

AI 工具的長連線

這類工具多數用串流回應:一次請求維持幾十秒到幾分鐘,中間持續回傳資料。連線一斷,回答就中斷,重來一次的成本很高。所以穩定性優先於峰值速度:選 TCP 類協定、選中轉線路,比選一個「測試數字更小」的 UDP 組合更實用。同理,這類情境不適合頻繁切換節點。

大檔案與備份

下載與備份看的是持續吞吐。協定標頭開銷在這個情境裡幾乎可以忽略,決定速度的是線路頻寬與兩端 CPU。VLESS 因為把加密交給 TLS、協定層開銷小,在高吞吐下更容易跑滿。同時要看清流量計算方式:月訂閱的流量依開通日每月重置,流量包用完為止、永久不過期,時間不固定的備份任務用流量包更合適。

常見迷思有三條。第一,新協定不一定更快:協定只決定封裝,瓶頸通常在路徑。第二,一個數字不能代表全部:用戶端延遲是到入口的探測值。第三,不同時段不可比:晚高峰與凌晨的差異可能大於兩條線路之間的差異。把這三條記住,能省下大量反覆試錯的時間。

自我檢查與驗證:連上之後

連上不等於走對。出口在哪個國家、網域解析有沒有走隧道、大封包能不能通過,這三件事都要單獨確認。它們對應三種完全不同的現象,混在一起排查會繞遠路。

出口位址與歸屬地

最簡單的驗證是看出口位址。連上之後開啟本站的網路檢測頁,頁面會顯示目前出口與歸屬地;斷開再查一次,兩次結果不同才說明流量確實走了線路。如果兩次一樣,說明用戶端沒有接管全域流量,或者目前應用命中了直連規則。這一步做完,再談速度才有意義。

網域解析與分流規則

解析是否走在隧道裡,決定了「解析結果」和「實際出口」是否一致。分流規則裡如果只代理了部分網域,解析可能仍然走本地,表現為部分網站打不開、部分正常。排查方法很簡單:暫時切到全域模式再試,如果問題消失,就是分流規則的問題,回去檢查規則清單即可,不必改協定。

MTU 與分片

UDP 類協定對 MTU 更敏感。典型表現是:網頁能開啟、聊天正常,但影片卡住、大檔案傳不動、某些應用一直轉圈。原因是大封包在路徑上被丟棄,而小封包正常。處理辦法是在用戶端裡調低 MTU 或開啟分片,具體項目名稱各用戶端不同,通常在協定設定裡。調完要重新測一次大檔案,別只看網頁能不能開。

# 查目前出口位址(把範例網域換成任意回顯位址的服務)
curl -s https://example.com/ip

# 看路徑 MTU:先按 1500 試,失敗再逐級下調
ping -c 3 -M do -s 1472 example.com

一份可以照著填的記錄表

排查最怕的是憑印象。把下面幾項記下來,連續記三天,問題基本上就自己浮出來了。

排查順序總結成一句:先確認出口對不對(是不是走了線路),再確認穩定性(同一時段多次取樣),最後才調協定。順序反了,會把線路問題當成協定問題,越調越亂。如果三條都不對,先回教學頁按主線把匯入流程重做一遍;仍然不對,帶著記錄表裡的資料聯絡客服,比只說「連不上」有用得多。

術語速查與常見問題

這一章是給回頭查閱用的。術語依出現頻率排序,後面的問答涵蓋最常被問到的五個問題,答案盡量給判斷依據而不是結論。

RTT往返時間

一個封包從送出去到收到回應的時間。多數互動式體驗由它決定,而不是由頻寬決定。

JITTER抖動

多次往返時間之間的波動幅度。會議與語音對抖動最敏感,對峰值頻寬反而不敏感。

LOSS丟包率

一段時間內被丟棄的封包佔送出封包的比例。短連線對丟包更敏感,因為一次丟包就要等一輪重傳。

MUX多工

一條連線裡並行跑多個請求。減少握手次數,代價是要維護更多連線狀態。

0-RTT零往返恢復

工作階段恢復時省掉握手的往返,第一個請求隨恢復封包一起送出。前提是之前建立過工作階段。

MTU最大傳輸單元

單次能傳輸的最大封包大小。UDP 類協定對它有額外要求,設定不對會表現為大封包傳不動。

QUIC

以 UDP 為基礎的傳輸協定,把傳輸握手與 TLS 合併,支援依流重傳與連線遷移。

AEAD認證加密

帶關聯資料的認證加密,同時保證機密性與完整性,是現代協定的基本構件。

CC壅塞控制

傳送端依丟包與延遲調整傳送速率的演算法。TCP 與 QUIC 的實作策略不同,弱網表現也不同。

EDGE入口與落地

入口是使用者連上的第一台伺服器,落地是最終存取外部服務的出口。兩者的距離決定了延遲的下限。

常見問題

相關頁面:第一次設定請看教學頁;依地區與線路類型挑線路請看線路頁;方案與流量包的具體價格請看方案頁;想自己重現測速流程,可以看加速器速度實測方法;完全從零開始,請看海外加速器新手完整指南。