協定參考:六種協定與三種線路拓撲

六種協定各自解決什麼問題

一個代理協定要同時處理三件事:把 TCP 與 UDP 流量封裝進一條隧道、讓這條隧道在中間設備看來不像隧道、在兩端完成身分驗證與加密。這三件事的優先順序怎麼排,就分出了不同的協定。理解這一點之後,再看那些協定名稱就不會覺得是在挑「哪個更強」,而是在挑「這條鏈路缺什麼」。

Shadowsocks:最輕的一層封裝

Shadowsocks 是最早的輕量設計之一。核心是一條加密的 SOCKS5 隧道,用 AEAD 類演算法(AES-256-GCM、ChaCha20-Poly1305 等)對酬載加密。它不做協定偽裝,不假裝自己是 HTTPS,只保證流量本身沒有明文特徵。

好處是實作簡單、用戶端支援面最廣、握手開銷最小。代價是流量形態固定:一條持續的雙向隨機位元組流,連接埠也不一定是 443。在網路設備對「非標準連接埠的持續加密流」做分類時,它缺少一個可以依附的外殼。它的 UDP 支援也依賴具體實作,不同用戶端的表現並不一致。

VMess:把協定與傳輸拆成兩層

VMess 帶 UUID 身分與時間戳記校驗,傳輸層可插拔,可以套 WebSocket、gRPC、HTTP/2、mKCP 等外殼。這是它最大的結構性優勢:同一套認證邏輯可以掛在不同外觀上,一種外觀不合適就換另一種。

代價是協定本身複雜。時間戳記校驗要求用戶端與伺服器的時間偏差落在允許視窗內,裝置時間不準會直接認證失敗,而失敗提示往往只是「連線逾時」,很難一眼看出原因。舊版本裡的 AlterID 機制為相容性保留了額外的身分衍生,現在通常建議設為 0,以減少不必要的開銷與重播面。

Trojan:把自己偽裝成一次標準 TLS

Trojan 的思路最直接:用戶端先與伺服器完成一次真正的 TLS 握手,密碼在 TLS 通道內作為認證憑據。對中間設備來說,這條連線與造訪一個普通 HTTPS 網站沒有區別,因為它在協定層面就是。

代價是必須有憑證、必須佔用 443 連接埠、憑證過期或設定錯誤時整條線路直接不可用。它也是最依賴「伺服器維運品質」的一種協定:憑證鏈、SNI、HTTP 回應偽裝任何一處沒設好,都會讓外觀露餡或者連線失敗。

VLESS:VMess 的減法版本

VLESS 去掉了協定層自帶的加密與部分校驗,把安全性交給外層的 TLS 或 Reality,自己只做輕量的身分傳遞。因為少了一層封裝,它的握手更快、CPU 開銷更低,配合 XTLS 思路可以做到很低的轉發耗損。

代價是它自身不提供加密。設定裡如果 TLS 沒開好,安全性完全取決於外層,這一點和 Trojan 的「預設就走 TLS」不同。選 VLESS 的前提是確認外層傳輸已經設好,而不是把它當成一個可以裸奔的協定。

Hysteria2:為高丟包鏈路準備的 QUIC 方案

Hysteria2 基於 QUIC(UDP),自帶壅塞控制。它針對的是 TCP 系協定在高丟包鏈路上的短處:QUIC 在使用者空間實作壅塞控制,可以採用對隨機丟包不敏感的演算法,不必像 TCP 那樣把每一次丟包都當成壅塞訊號。

代價是 UDP 特徵明顯。部分網路會對 UDP 做限速或降級,這時候它的表現會突然變得很差,而且這種變差是環境造成的,換參數解決不了。另外使用者空間通訊協定堆疊的 CPU 佔用高於核心 TCP,在低功耗裝置上這一點會被放大。

TUIC:更極簡的 QUIC 代理

TUIC 同樣基於 QUIC,設計更接近「極簡的 QUIC 代理」,支援 0-RTT 恢復握手。連線建立來回次數少,重連快,適合頻繁斷線重連的行動場景。

代價是生態比 Hysteria2 窄一些,部分用戶端與面板尚未支援。選它之前先確認手邊的用戶端版本能辨識,否則會出現「設定寫對了但用戶端不認」的情況。

握手、開銷與連線建立速度

協定之間第一個可量測的差異是「建立一條連線要幾個來回」。這個數字直接決定首屏速度,尤其在跨境鏈路上,每一個來回都是一百多毫秒。

一次連線的來回次數

從按下「連線」到第一個位元組送出,中間有幾個不可避免的步驟:

1. 網域名稱解析:如果用戶端用網域名稱連伺服器,先要解析出位址。用 IP 直連可以省掉這一步。
2. TCP 三次握手:一個來回,沒有例外。
3. TLS 握手:TLS 1.3 是一個來回,TLS 1.2 是兩個來回。這一層只有 Trojan、VLESS over TLS、以及套了 TLS 的 VMess 才有。
4. 代理協定本身的認證:多數協定把認證放在首個封包裡,不額外佔來回。
5. 目標網站自己的握手:代理只負責把位元組送到,目標網站的連線開銷照樣存在。

在一個來回 150 毫秒的跨境鏈路上,光是 TCP 加 TLS 1.3 就要 300 毫秒。這不是軟體慢,是物理距離決定的。任何用戶端優化都只能省掉軟體層的開銷,省不掉光在光纖裡跑的時間。

各協定在這條時間軸上的位置

Shadowsocks 沒有 TLS 層,認證與首個封包合併,理論上是 1 個來回之後就能送資料。VMess 同樣把認證放在首包,來回上不增加,但首包要解析時間戳記與 UUID,CPU 上多一點。Trojan 與 VLESS over TLS 必須走完整的 TLS 握手,比 Shadowsocks 多一個來回,換來的是「看起來像 HTTPS」。

Hysteria2 與 TUIC 走 QUIC。QUIC 把傳輸握手與加密握手合併,首次連線 1 個來回;TUIC 支援 0-RTT 恢復,在工作階段票證有效期內重連不需要額外來回。這是 QUIC 系在「頻繁斷線重連」場景下的真實優勢,而不是行銷話術。

CPU 與記憶體的真實開銷

加解密不是免費的,但在現代 CPU 上很便宜:

• AES-GCM 在支援 AES-NI 的 x86 處理器上有硬體加速,吞吐可以到數 GB/s 量級,單條代理連線根本壓不滿。
• ARM 裝置(手機、路由器、電視盒子)上 AES 指令集支援不齊,ChaCha20-Poly1305 通常更快,這也是行動端推薦 ChaCha20 的原因。
• QUIC 系協定在使用者空間實作通訊協定堆疊,每個封包都要進出使用者空間一次,CPU 佔用明顯高於核心 TCP。低功耗裝置上這一點會被放大成「風扇轉起來」或者「電量掉得快」。
• 記憶體方面,主要開銷是每條連線的緩衝區。多路複用可以把多條連線壓進一條隧道,減少握手與緩衝,但代價是隊頭阻塞。

為什麼握手開銷會被放大

握手耗時只在「開啟新連線」時付一次。瀏覽器對同一個網站會重複使用連線,但現代網頁往往跨多個網域:統計、字型、圖片、介面各在一個網域下,一次頁面載入可能觸發十幾條新連線。這時候握手來回會被放大十幾倍,也是「協定看起來影響首屏速度」的真實原因。

反過來說,影片播放、大檔案下載這類長連線場景,握手只發生一次,協定之間的握手差異幾乎看不出來。所以同一個協定在不同場景下的體感可以完全不同,討論「哪個協定快」之前要先說清楚是什麼場景。

行動裝置的電量帳

手機上的耗電由四塊構成:CPU 加解密、射頻收發、系統喚醒次數、螢幕與硬體解碼。協定影響的是前三塊,而大多數使用者感受到的「開了代理掉電快」,其實是第三塊——喚醒次數。

射頻喚醒的代價

行動網路的射頻狀態機有若干個檔位:閒置、低功率、高功率。從閒置切到高功率要幾百毫秒,並且在這段時間裡功耗是峰值的數倍。如果一條連線每十秒送一次心跳封包,射頻就被迫每十秒醒一次,一整天下來是八千多次喚醒。

• TCP 系協定的保活通常可設定,系統層級 TCP keepalive 預設間隔很長(以小時計),應用層完全可以不送心跳。
• QUIC 系協定為了維持 NAT 對應,預設會有週期性 keep-alive,間隔通常在十幾秒到幾十秒。這是 QUIC 在行動端更耗電的主要原因之一,而不是加解密本身。

所以「換協定能省電」這句話,準確的說法是「換掉週期性心跳能省電」。同樣一條 QUIC 連線,把心跳間隔從十幾秒調到兩分鐘,耗電差異會非常明顯。

加解密的實際佔比

在支援 AES 指令集的手機上,AES-GCM 的吞吐遠高於行動網路的頻寬上限,加解密佔用的 CPU 時間可以忽略。真正吃 CPU 的是 QUIC 的使用者空間通訊協定堆疊:每個封包都要經歷一次使用者空間與核心之間的複製,在持續滿速下載時,CPU 會長時間維持在較高頻率。

反過來說,如果你的使用場景是瀏覽網頁、看訊息,流量本身很小,QUIC 的 CPU 開銷也就無從體現,耗電差異會被其他因素淹沒。

背景保活與「看起來還連著」

iOS 與 Android 都會回收背景應用。代理類應用通常藉助系統的 VPN 框架運作,這條通道相對穩定,但應用內的計時器仍會被系統節流。表現是:鎖屏一段時間後重新解鎖,連線看起來還在,但第一個請求明顯變慢——這是隧道需要重建或重新協商。

這種「看起來還連著」的狀態比徹底斷開更麻煩,因為它不會觸發用戶端的自動重連邏輯。如果經常遇到解鎖後第一次開網頁空白幾秒,可以在用戶端裡把「斷線自動重連」打開,或者乾脆在長時間不用時手動斷開。

省電的幾項實務做法

• 手機優先使用 TCP 系協定,把 QUIC 系留給弱網場景。
• 選擇延遲更低的近端線路:握手來回越短,射頻處於高功率的時間越短。
• 關閉不必要的分應用代理:只讓需要的應用走隧道,減少常駐連線數。
• 把心跳間隔調長,前提是網路環境不會因為 NAT 逾時把對應表清掉。
• 長時間看影片時,電量差異主要來自螢幕與硬體解碼,協定之間的差距會被稀釋。

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

協定決定「怎麼封裝」,拓撲決定「走哪條路」。在跨境場景裡,拓撲對體驗的影響通常大於協定。同一個協定換一條拓撲不同的線路,體感差異可能比換三次協定都明顯。

直連

用戶端直接連到海外機房的公網位址,流量走電信商的國際出口。

• 結構最簡單,沒有中間環節,基準延遲最低。
• 但國際出口是共享資源。晚高峰時出口佇列變長,丟包與延遲一起上升,而且這種壅塞不受服務方控制。
• 適合:輕量網頁瀏覽、非高峰時段、對成本敏感的場景。

直連的問題不在於「慢」,而在於「不可預測」。離峰時它可能比中轉還快,晚高峰時它可能完全不可用,而這兩種狀態之間沒有任何過渡提示。

中轉

用戶端先連到本地區的中轉入口,再由中轉入口連到海外落地。

• 把「最後一哩」的不確定性收斂到一段可控鏈路:用戶端到中轉入口走本地骨幹,通常穩定;中轉入口到落地走優化過的跨境路由。
• 代價是多了一跳,基準延遲增加。中轉節點本身的處理能力也會成為瓶頸,頻寬不夠的中轉比直連還差。
• 關鍵指標不是「有沒有中轉」,而是「中轉段的跨境路由是否被優化過」。同樣叫中轉,走公網出口和走優化路由是兩件事。

這也是為什麼不同服務商的中轉線路體驗差距可以很大:名字一樣,背後的路由策略完全不同。判斷方法只有一個——在晚高峰實際用一次。

專線

端對端的邏輯專線(IEPL、MPLS 一類),頻寬獨享或準獨享,不經過公網出口的壅塞點。

• 延遲穩定、丟包低,晚高峰的表現與離峰接近。
• 成本高、總頻寬有限,所以通常只在重點地區部署,不可能覆蓋到每一個國家。
• 適合:即時性要求高的場景,例如會議、遊戲、遠端桌面、對穩定性敏感的業務。

專線不是「更快」,而是「更穩」。它的絕對延遲不一定比直連低,但在晚上八點和凌晨兩點測出來的數字應該差不多,這才是它值錢的地方。

延遲由哪幾塊組成

1. 物理傳播:光在光纖中的速度約為每毫秒 200 公里。上海到洛杉磯直線約 10500 公里,單程光程按 1.4 倍繞行係數算約 14700 公里,單程約 73 毫秒,往返約 146 毫秒。這是物理下限,任何優化都無法突破。
2. 路由繞行:實際路由不一定走最短路徑,繞行會額外增加幾十毫秒。
3. 排隊延遲:出口壅塞時,封包在佇列裡等待。這一項在晚高峰可以翻好幾倍,也是最不受控的一項。
4. 協定握手:見上一章,每多一層就多一個來回。

所以「這條線路延遲 40 毫秒」這種說法,只有在明確起點與終點時才有意義。同一個節點,從廣州測和從哈爾濱測,數字可以差出一倍。

丟包、抖動與晚高峰

「晚高峰變慢」是跨境存取裡最常見的抱怨,也是最容易被誤解的現象。它不是一個原因,而是一連串連鎖反應的結果。

丟包從哪裡來

• 誤碼:光纖的誤碼率極低,正常鏈路上因誤碼丟包可以忽略。無線段(4G、5G、Wi-Fi)是例外,訊號弱時誤碼率會明顯上升。
• 佇列溢出:路由器的緩衝區滿了,後來的封包被丟棄。這是跨境鏈路上最主要的丟包來源。
• 策略丟包:部分網路設備會對特定類型的流量做限速或丟棄。這也是 QUIC 系協定在個別網路裡表現不穩定的原因。

三種丟包的處理方式完全不同:誤碼只能靠換無線環境,佇列溢出可以靠換拓撲或離峰,策略丟包只能靠換協定或換連接埠。不區分來源就盲目調參數,基本上是白費力氣。

晚高峰是怎麼形成的

晚上七點到十一點,家用寬頻並發上升,國際出口的總流量接近或超過設計容量。出口設備開始排隊,然後是一連串連鎖:

1. 佇列變長,延遲上升。
2. 佇列滿,開始丟包。
3. TCP 把丟包當成壅塞訊號,壅塞視窗減半,吞吐驟降。
4. 使用者感覺慢,重新整理、重試,新連線湧入,壅塞進一步加劇。

這是一個正回饋,所以晚高峰的體驗下降往往不是線性的,而是過了某個點之後突然變差。很多人會覺得「八點之前還好好的,八點零五突然就不行了」,原因就在這裡。

為什麼百分之一的丟包能毀掉一半頻寬

TCP 的吞吐大致與「TCP 區段大小 ÷(來回時間 × 丟包率的平方根)」成正比。來回 150 毫秒、丟包率百分之一時,單條 TCP 連線的理論吞吐會掉到峰值的一小部分。這也是為什麼「測速網站顯示滿速,但開網頁很慢」會同時出現:測速用的是多執行緒並發,網頁用的是單條連線。

理解這一點之後,很多「玄學」就有了解釋:同一時間、同一條線路,下載器能跑滿而瀏覽器卡頓,不是瀏覽器的問題,是並發模型不同。

QUIC 系為什麼在高丟包下更好

QUIC 在使用者空間實作壅塞控制,常用的演算法基於頻寬與來回時間建模,不把每一次丟包都當成壅塞訊號。在隨機丟包為主的鏈路上,這能讓吞吐保持得更好。代價是它對「真壅塞」的反應也更遲鈍,在確實頻寬不足時會表現得不夠公平。

換句話說,QUIC 系不是「更快」,而是「對丟包更寬容」。鏈路本身不丟包時,它和 TCP 系沒有明顯差距;鏈路開始丟包時,差距才拉開。

緩衝區膨脹

家用路由器與部分電信商設備使用大緩衝區。緩衝區大在突發流量下是好事,但在持續滿載時會讓排隊延遲飆升到幾百毫秒。表現是:測速正常,但每一次點擊都要等一會兒;影片能播,但拖動進度列要轉圈。

判斷方法:同時觀察本地閘道與境外目標的來回時間。如果閘道本身就抖,問題在本地;如果閘道穩定而境外目標抖,問題在跨境段。這一步能把排查範圍砍掉一半。

抖動比延遲更影響體感

延遲高但穩定,使用者會適應;延遲不高但抖動大,影片會頻繁緩衝、語音會斷續、遊戲會瞬移。選線路時,抖動的權重應該高於平均延遲。很多用戶端只顯示一個「延遲」數字,那個數字通常是若干次探測的平均值,看不出抖動,需要自己連續測幾次看波動範圍。

按場景選型

前面幾章講的是原理,這一章給結論。前提是:以下建議都建立在「線路本身可用」的基礎上。如果線路在晚高峰已經嚴重壅塞,換協定只能緩解,不能治癒。

日常網頁與辦公

推薦 VLESS over TLS 或 Trojan。

理由:網頁載入會觸發大量短連線,握手來回次數被放大。這兩個協定走標準 TLS,配合連線重複使用,首屏體驗穩定;同時它們的流量外觀是普通 HTTPS,在各種網路環境下相容性最好。不建議在辦公場景用 QUIC 系:短連線場景下 QUIC 的握手優勢不明顯,而使用者空間通訊協定堆疊的 CPU 開銷在低配筆電上會被感受到。

4K 串流媒體

推薦 VLESS 或 Trojan,搭配中轉或專線。

理由:串流媒體是長連線、持續大流量,頻寬穩定性優先。TCP 系協定在頻寬充足時能跑滿;專線或優化中轉能避開晚高峰的出口壅塞。如果所在網路對 UDP 友善,Hysteria2 也是可選項,它在丟包鏈路上的位元率保持更好,不容易觸發播放器的降檔。站內觀影解鎖頁有按平台整理的線路建議,以及位元率與頻寬的關係的詳細說明。

連線遊戲

推薦 Trojan 或 VLESS,選近端節點,不要開多路複用。

理由:遊戲對延遲與抖動敏感,對頻寬不敏感。TCP 系協定的延遲曲線更平;多路複用會把多條連線塞進一條隧道,一旦隧道丟包,所有連線一起卡(隊頭阻塞),表現為「整局遊戲突然集體延遲」。

如果遊戲本身需要 UDP 轉發,確認用戶端與伺服器端都開啟了 UDP,否則會出現「能登入、進不去對局」的情況。延遲與丟包的更多實測思路見遊戲場景的延遲與丟包分析。

大檔案下載與更新

推薦 Hysteria2。

理由:下載是純吞吐場景,對延遲不敏感。在高丟包鏈路上,QUIC 系的吞吐優勢最明顯。代價是 CPU 佔用高,在低功耗裝置上可能反過來成為瓶頸——如果下載時發現速度上不去、CPU 卻跑滿,那就是裝置算力先到了上限。

行動裝置長時間待機

推薦 Trojan 或 VLESS。理由見電量那一章:QUIC 系的週期性保活會持續喚醒射頻。Android 端的背景保活與省電策略另有細節,可參考Android 端的實測對比。

弱網環境

推薦 Hysteria2 或 TUIC。

理由:弱網的典型特徵是丟包率高、抖動大。TCP 系協定在這種情況下會反覆收縮壅塞視窗,表現為「速度忽高忽低」;QUIC 系的壅塞控制對隨機丟包不敏感,速度更平穩。公共場所的 Wi-Fi、行動網路訊號只有一兩格、高鐵上,都屬於這一類。

需要同時使用 AI 工具時

AI 工具的介面呼叫是短請求,但單次回應可能很長(生成式回覆是串流回傳)。這類場景對首包延遲敏感、對頻寬要求中等,推薦 VLESS 或 Trojan 搭配中轉線路。更多細節見站內的AI 工具專題。

分層排錯與自我檢查

排錯的核心是分層:把「能不能連」和「快不快」分開,再把「快不快」拆成延遲、丟包、頻寬三塊。每層只改一個變數,才能知道是哪一步起了作用。

第一層:確認流量真的走了隧道

顯示「已連線」不等於流量真的走了線路。三種驗證方法:

1. 查出口 IP:連線前後各查一次,應該不同,且歸屬地應該是線路所在國家/地區。
2. 查 DNS:解析請求應該由隧道內的解析器處理,而不是本地電信商。如果 DNS 走了本地,會出現「能連上但部分網站打不開」。
3. 分應用驗證:如果開了分應用代理,確認目標應用在代理清單裡。

完整步驟見站內文章怎麼確認 VPN 真的生效了。命令列下可以這樣查:

# 1. 查目前出口 IP(範例位址,替換成任意回傳純文字 IP 的服務)
curl -s https://example.com/ip

# 2. 看目前使用的 DNS 伺服器
nslookup example.com
# 輸出裡 "Server:" 後面就是實際使用的解析器位址

# 3. 連續探測,看抖動而不只看平均值
ping -c 20 example.com

注意 ping 走的是 ICMP,部分線路對 ICMP 的優先權與 TCP 不同,ping 正常不代表 TCP 正常,反之亦然。要測 TCP 的來回,用 curl 看各階段耗時:

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

這幾個數字能直接告訴你時間花在哪一段:如果 time_namelookup 很大,是 DNS 問題;如果 time_connect 大,是 TCP 握手或鏈路問題;如果 time_appconnect 比 time_connect 大很多,是 TLS 握手慢,通常是線路來回太長或者憑證鏈太長。

第二層:連不上

按順序檢查,不要跳步:

• 訂閱是否過期:流量用盡或到期後,用戶端仍顯示「已連線」,但所有請求都會被拒絕。這是最常見也最容易被忽略的一條。
• 裝置時間:VMess 依賴時間戳記校驗,時間偏差過大會直接認證失敗。開啟自動同步。
• 協定與連接埠是否相符:伺服器設定改了而用戶端訂閱沒更新,是常見原因。重新拉一次訂閱。
• 本機防火牆:某些安全軟體會攔截非標準連接埠的對外連線,表現是所有線路都連不上。
• 憑證:Trojan 與 VLESS over TLS 依賴憑證。憑證過期時,用戶端會回報 TLS 握手失敗,而不是「連線逾時」。

第三層:連上但慢

1. 換線路:同一條線路在不同時段的表現差異很大。先換一條拓撲不同的線路對比。
2. 換協定:在同樣的線路上換協定。如果 TCP 系慢而 QUIC 系正常,說明鏈路上有丟包。
3. 看時段:記錄變慢的時間點。如果固定在晚間,是出口壅塞;如果全天如此,是線路本身的問題。
4. 看單一連線:用單執行緒下載測試。多執行緒快、單執行緒慢,說明存在丟包或緩衝區膨脹。
5. 看 MTU:QUIC 對 MTU 敏感。路徑 MTU 黑洞的表現是「握手成功、小請求正常、大請求卡死」。把 MTU 調低(例如 1280)再試。

第四層:只有部分應用有問題

• 分應用代理清單是否包含該應用。
• 應用是否使用了自己的 DNS 或加密 DNS,繞過了隧道內的解析。
• 應用是否強制走 IPv6,而隧道只代理了 IPv4。
• 應用是否使用了憑證綁定,對中間代理不相容。

這一層的排查成本最高,因為每個應用的網路行為都不一樣。有效的辦法是先用瀏覽器驗證隧道本身沒問題,再逐個應用排查。

參數速查與常見誤解

最後一章把用戶端裡那些開關逐個說清,再列幾條常見的誤解。這一章可以當工具頁用,遇到不確定的選項回來查。

用戶端裡的幾個開關

• TLS:開啟後流量外觀是 HTTPS。Trojan 與 VLESS 必須開;Shadowsocks 與 VMess 可以套 TLS,但會多一個來回。
• XTLS 與 Reality:VLESS 的兩種傳輸優化。前者減少加解密層的複製,後者讓伺服器在沒有自有憑證的情況下也能呈現真實的 TLS 特徵。兩者都需要伺服器配合,用戶端單方面開啟無效。
• 多路複用:把多條連線複用到一條隧道。降低握手次數,但在丟包鏈路上會引入隊頭阻塞。網頁瀏覽可開,遊戲與語音不建議。
• UDP 轉發:決定 UDP 流量是否走隧道。遊戲、語音、部分視訊通話依賴它。關閉後這些應用會直連或不可用。
• 壅塞控制:QUIC 系協定通常可選。基於頻寬建模的演算法在高丟包鏈路上吞吐更好,但在真壅塞時對其他流量不夠友善。
• 分應用代理:只讓指定應用走隧道。省電、減少干擾,但設定不當會出現「某個應用連不上」。
• 訂閱自動更新:定期拉取最新線路。建議開啟,但不要設得太頻繁,否則每次更新都會短暫中斷。

六條常見誤解

誤解一:協定越新越快。協定決定的是開銷與抗丟包能力,頻寬上限由線路與落地決定。在一條乾淨的低丟包鏈路上,六種協定的吞吐差距遠小於線路之間的差距。

誤解二:加密越強越慢。AEAD 類加密在現代處理器上開銷很小,真正的瓶頸是鏈路。把加密從 AES-256 換成 ChaCha20,在手機上可能有可量測的差異,在桌機上基本上感受不到。

誤解三:延遲低就一定快。延遲影響的是「開始」的速度,吞吐還取決於丟包與壅塞視窗。一條來回 40 毫秒但丟包百分之二的線路,下載速度可能不如一條來回 80 毫秒但幾乎不丟包的線路。

誤解四:UDP 一定被限速。取決於具體網路環境,不能一概而論。判斷方法很簡單:在同樣的線路上分別用 TCP 系與 QUIC 系協定做單執行緒下載,對比結果。

誤解五:多層代理更安全。疊加多層只會增加延遲與故障點,不會提升單層加密的強度。需要的是正確的協定設定,不是層數。

誤解六:連線數越多越快。瀏覽器的並發連線數是有限制的,超過之後新連線會排隊。多開用戶端、多開隧道只會互相搶頻寬。

把這份手冊用起來

如果你剛決定要試,先看套餐頁確認檔位:月訂閱 ¥9.9 含 60GB、¥18 含 250GB、¥28 含 500GB,流量按開通日每月重置,中途升級差價折算成剩餘天數;另有流量包 ¥158/300GB、¥358/1000GB、¥658/3000GB,用完為止,永久不過期。所有套餐都不限台數,支援支付寶、微信、USDT,註冊無需電子郵件地址,使用者名稱加密碼即可。首次付費後 7 天內可申請無理由退款。

如果你已經買好了,按使用教學走一遍匯入流程,再回來按場景挑協定。想先了解服務本身的定位與原則,看關於本站。