協定與線路選型參考

六種協定的設計取捨

代理協定要解決的問題可以拆成三件:把流量封裝進一條能夠通行的連線、在兩端之間完成加密與完整性校驗、讓鏈路上的中間裝置無法從位元組層面判斷內容。六種主流協定在這三件事上的取捨各不相同,取捨的結果直接體現在握手往返次數、CPU 佔用、抗丟包能力和行動裝置耗電上。本章依設計取向逐個說明,不做排名,因為脫離鏈路談優劣沒有意義。

Shadowsocks:最薄的一層封裝

Shadowsocks 的設計目標很克制:用一條加密的 TCP 或 UDP 連線把流量送到出口,不額外疊加偽裝層。加密使用 AEAD 套件,常見的是 AES-128-GCM、AES-256-GCM 與 ChaCha20-Poly1305,這類模式把加密與完整性校驗合併成一步,省掉了先加密再單獨計算校驗的往返。因為沒有內建 TLS,它的握手成本在六種協定裡屬於最低的一檔,對延遲敏感的情境能直接受益。代價是流量特徵完全取決於外層怎麼包裝:裸跑時它就是一段高熵位元組的 TCP 流,鏈路上任何做深度封包檢測的裝置都可能對它產生興趣。實際部署裡通常會把 Shadowsocks 放進 TLS 通道,或者與其它傳輸層組合使用。

VMess:帶身分與時間校驗的封裝

VMess 在協定標頭攜帶使用者識別碼與時間戳,伺服器端用這兩項做身分校驗。這也帶來一個容易踩的坑:用戶端與節點的時間必須大致同步,偏差過大時握手會被直接拒絕,表現是設定逐項核對都對、就是連不上。VMess 的標頭經歷過多個版本,AEAD 版本把標頭也納入完整性保護,避免標頭欄位被中途竄改。它的開銷略高於 Shadowsocks,換來的是更明確的多使用者模型與更細的標頭欄位,適合在一個節點上區分多個訂閱者。

Trojan:把流量放進標準 TLS

Trojan 的思路是把代理流量放進一條標準 TLS 連線:先完成一次看起來完全正常的 TLS 握手,伺服器端在握手完成後才校驗密碼。對鏈路上的中間裝置來說,它看到的是一次普通的 HTTPS 工作階段,目標網域、憑證鏈、握手順序都與常規存取一致。密碼不符時,伺服器端可以把這條連線轉發給一個真實的 Web 服務,讓探測方拿到一份正常的網頁回應。相容性好是它的優勢,代價是多了一層 TLS,握手多一個往返,CPU 也要多做一次對稱加解密。

VLESS:去掉重複的一層

VLESS 的取向是只做該做的事:協定本身不加密,把加密完全交給外層 TLS,從而避免在 TLS 裡再套一層加密的重複開銷。搭配 XTLS 系列的流量控制,內層與外層的加密可以不再重複執行,CPU 佔用明顯下降。VLESS 是無狀態的,伺服器端不需要為每個使用者維護工作階段表,節點橫向擴充更容易。它適合已經有穩定 TLS 通道、又希望把吞吐量與 CPU 效率拉滿的情境;反過來說,如果外層 TLS 設定不當,VLESS 本身沒有額外的備援加密。

Hysteria2:在 QUIC 上交換壅塞控制

Hysteria2 跑在 QUIC 之上,也就是走 UDP。它最實際的差異在壅塞控制:可以選用 BBR 一類的演算法,在丟包率較高的鏈路上仍然維持較高吞吐量,而不是像傳統 TCP 壅塞控制那樣一遇丟包就大幅縮小視窗。代價同樣明確:UDP 流量在部分網路裡會被限速或降級處理;QUIC 在使用者空間實作,每個封包都要經過一次使用者空間拷貝與計時器處理,CPU 佔用高於核心 TCP;行動裝置長時間使用,耗電也會更高。

TUIC:QUIC 上的多工與 0-RTT

TUIC 同樣基於 QUIC,重點放在多工與快速恢復:一條 QUIC 連線上可以並行承載多條邏輯流,已經建立過工作階段的用戶端再次連線時可以走 0-RTT,省掉一個往返。它的取捨與 Hysteria2 接近,即 UDP 鏈路是否可用直接決定體驗上限。在 UDP 通暢的網路裡,TUIC 的首包時間表現很亮眼;在 UDP 被限速的網路裡,它反而不如一條穩定的 TCP 線路。

結論很樸素:鏈路品質好、追求低開銷,Shadowsocks 與 VLESS 更合適;需要相容性與偽裝,Trojan 更穩;鏈路丟包嚴重,Hysteria2 與 TUIC 的壅塞控制能救回吞吐量;行動裝置長時間掛機,核心空間的 TCP 系協定在耗電上更友善。VPNLW 的 230+ 線路依地區標註了可用協定,匯入訂閱後用戶端會依線路下發對應的協定組合,不需要手工拼裝設定。

從點擊到首包:握手都發生了什麼

使用者感受到的快慢由兩個不同的量決定:首包時間,也就是點開一個連結到收到第一個位元組的間隔;以及持續吞吐量,也就是開始傳輸之後的速度。首包時間由往返次數決定,吞吐量由頻寬與壅塞控制決定。兩者經常被混為一談,排錯時也就容易走錯方向——明明只是握手慢,卻一直在換大頻寬線路。

一次請求經過了幾次往返

把一次網頁請求拆開,大致經過下面幾步。第一步是名稱解析,如果本機快取裡沒有記錄,需要一次或多次往返去問 DNS;在代理模式下,解析可能交給遠端完成,本機到節點這一段就多了一次協商。第二步是到節點的傳輸握手,TCP 需要一個往返。第三步是 TLS 握手,TLS 1.3 在完整握手時是一個往返,工作階段恢復時可以做到 0-RTT。第四步是代理協定本身的協商:VLESS 與 Trojan 基本沒有額外往返,VMess 需要校驗識別碼與時間,QUIC 系協定是一個往返或 0-RTT。第五步是節點到目標網站,這一段取決於落地機房到目標的物理距離與路由品質。第六步才是資料回傳。

把這幾段加起來就能解釋一個常見現象:第一次打開某個網站明顯慢,第二次就快了。原因不是線路變好了,而是連線池與 TLS 工作階段票據被重用,後面幾次省掉了握手。

0-RTT 省下的是什麼,代價在哪裡

TLS 1.3 的工作階段恢復允許用戶端在第一個飛行封包裡就帶上應用資料,這就是 0-RTT。QUIC 沿用了這套機制。省下的是一個完整往返,在跨洋鏈路上相當於把首包時間砍掉一截。代價是重放風險:鏈路上的攻擊者可以截獲並重放這段 0-RTT 資料,所以協定規範建議只對冪等請求使用。用戶端是否真的啟用 0-RTT,取決於實作與本機快取狀態,不能把它當成必然發生的事。在排查「為什麼有時快有時慢」時,這一條值得記住。

連線重用與隊頭阻塞

多工把多條請求塞進一條連線,省掉重複握手。在 TCP 上,一條連線內的資料嚴格有序,前面一個封包丟了,後面所有流都要等它重傳,這就是隊頭阻塞。QUIC 在傳輸層就把流拆開,一條流丟包不影響其它流,代價是每條流都要單獨維護狀態,記憶體與排程開銷更高。選擇是否開啟多工要看情境:請求密集、連線數受限時,重用的收益明顯;單筆大流量傳輸時,不開多工反而更穩,因為不必和別的流搶同一個視窗。

怎麼自己量首包時間

瀏覽器開發人員工具的網路面板可以直接看到每個請求的排隊、DNS、連線、TLS 與首位元組各階段耗時。命令列可以用 curl 的分階段計時:

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

把這條指令在連線建立前後各跑一次,差值就是握手成本。範例網域只用於示範寫法,不要把真實的訂閱位址貼進任何線上工具或公開截圖。

理解這張表之後,很多「線路慢」的判斷會變得精確:如果只有第一次慢,問題在握手與解析;如果每次打開都慢,問題在往返次數;如果首包快但傳輸慢,問題在頻寬與壅塞控制。三種情況的處理方式完全不同。

CPU、記憶體與行動裝置耗電

協定選型在桌面端主要影響速度,在行動裝置上還會影響續航。耗電不是一個抽象指標,它由 CPU 喚醒次數、射頻模組工作時間、記憶體配置與回收頻率共同決定。同一份訂閱,在筆電上差別看不出來,在手機上可能是一小時與三小時的差別。

加密套件的硬體加速

AES-GCM 在支援 AES-NI 的 x86 處理器與帶 ARMv8 加密擴充的晶片上都是硬體指令,單位位元組成本極低。ChaCha20-Poly1305 是純軟體實作更快的方案,在沒有硬體加速的老裝置上反而佔優。多數用戶端會依 CPU 能力自動選擇,少數需要手動指定。把一台老 Android 裝置的加密套件從 AES 改成 ChaCha20,有時能明顯降低發熱與掉電速度,這是一個成本很低但常被忽略的調整。

使用者空間與核心空間的差別

TCP 由作業系統核心處理,封包從網路卡到應用只經過必要的拷貝。QUIC 在使用者空間實作,每個封包都要經過一次系統呼叫、一次使用者空間拷貝、一次計時器檢查。桌面處理器上這點開銷可以忽略,行動處理器上它會直接轉化成耗電與發熱。這也是為什麼 Hysteria2 與 TUIC 在手機上長時間使用時,續航表現通常不如 TCP 系協定。不是說 QUIC 系協定不好,而是它的優勢在丟包鏈路上,代價在耗電上,需要依情境權衡。

心跳與保活

NAT 裝置會回收閒置對應,用戶端因此需要週期性發送心跳來維持通道。心跳間隔越短,斷線機率越低,但射頻模組被喚醒的次數也越多。行動裝置的合理做法是把心跳間隔調長,搭配系統層級的網路保活;桌面端則可以保持較短間隔,換取更快的恢復速度。如果發現「鎖屏一會兒回來就要重連」,先看心跳間隔,而不是急著換節點。

背景保活與省電策略

iOS 對背景網路權限限制嚴格,應用程式進入背景一段時間後會被暫停,代理也隨之斷開。Android 的省電策略會限制背景應用程式的網路存取,常見表現是鎖屏幾分鐘後訊息收不到。解決辦法是把用戶端加入系統的省電白名單,並允許其在背景執行。這一步不是選項,而是行動裝置長期使用的前提。具體操作步驟在 Android 相關的教學文章裡有逐屏說明。

分應用程式代理是最直接的省電最佳化

只讓需要的應用程式走代理,能同時減少三件事:總流量、加解密次數、射頻模組的工作時間。系統更新、應用程式商店下載、區域網路備份這類流量完全沒必要經過境外節點。多數用戶端支援按應用程式勾選,設定一次即可長期生效。對於流量額度有限的方案,這一項還能順帶省下可觀的流量。

把這幾項調好之後,行動裝置的體驗改善往往比換一條線路更明顯。線路決定上限,設定決定實際消耗。

直連、中轉與專線

一條線路可以拆成三段:使用者到入口的接入段、入口到落地的跨境段、落地到目標的落地段。三段裡只有跨境段是服務商能主動最佳化的部分,線路類型的差別也主要落在這一段。理解這一點,就能理解為什麼同一個城市的兩條線路延遲差不多,晚高峰表現卻完全不同。

直連:路徑最短,品質最不可控

直連指節點機房直接位於境外,使用者流量經國際出口直達機房。優點是路徑短、沒有額外跳數,鏈路品質好的時候延遲最低。缺點同樣明顯:跨境段與所有使用同一出口的使用者共用,晚高峰的壅塞無法迴避。直連線路適合當作備用,或者在對延遲極敏感、且能接受波動的情境裡使用。把直連當成唯一選擇,等於把體驗押在別人家的出口頻寬上。

中轉:把不可控的一段換成可控的一段

中轉在離使用者更近的位置設入口,例如香港或日本,使用者先連到入口,再由入口沿最佳化過的路徑轉發到落地。中轉的價值不在於縮短物理距離,而在於把與所有人一起擠國際出口的情形,換成走一條經過排程的骨幹路徑。入口節點還能做統一排程:某條落地線路壅塞時,把流量切到另一條。代價是多了一跳,基礎延遲會比直連略高,但抖動通常更小,晚高峰的落差也更平緩。

專線:用成本換確定性

IEPL 一類的專線由電信業者提供,頻寬與路徑有明確的服務等級約定,不與公網流量搶同一佇列。它的表現是延遲穩定、丟包低、晚高峰不明顯。成本是三者裡最高的,所以通常只在部分線路上提供。判斷一條線路是不是專線,可以看命名標註,也可以用路由追蹤觀察跨境段的跳數與經過的網路。跳數少、路徑穩定、跨境段集中在少數幾個網路裡,通常是經過最佳化的路徑。

延遲與抖動是兩個不同的指標

平均延遲低不代表體驗好。視訊會議怕的是抖動,也就是延遲的波動;大檔案傳輸怕的是丟包,因為丟包會觸發壅塞控制縮小視窗。專線在這兩個指標上的優勢,比它在平均延遲上的優勢更明顯。很多使用者回饋「換了專線之後數值沒降多少,但會議不卡了」,說的就是抖動。

選擇建議很直接:日常瀏覽與影片用中轉即可;會議、即時協作、對斷流零容忍的情境用專線;直連留給備用與輕量情境。VPNLW 的線路清單依地區標註了線路類型,可以在節點頁依地區篩選後逐條對照。

延遲、丟包與晚高峰

這一章解釋三件出現頻率最高的事:為什麼延遲會變高、為什麼會丟包、為什麼晚上特別慢。理解成因之後,大部分「是不是線路壞了」的疑問可以自己判斷,不必每次都提交工單。

延遲由四部分組成

第一是傳播延遲,訊號在介質中傳播的時間,由物理距離決定,無法最佳化。第二是傳輸延遲,把資料推上鏈路的時間,由頻寬與封包大小決定。第三是排隊延遲,資料在路由器佇列裡等待的時間,壅塞時會急遽上升。第四是處理延遲,裝置轉發、加解密、通訊協定堆疊處理的時間。四者裡只有排隊延遲與處理延遲有最佳化空間。物理距離決定的下限無法突破,這也是為什麼繞路有時反而更快:繞開壅塞節點的路徑,總時間可能短於直線路徑。

丟包從哪裡來

丟包的常見來源有四類。一是佇列溢出,鏈路上某一跳的緩衝被佔滿,後來的封包直接被丟棄。二是無線干擾,Wi-Fi 與行動網路在高干擾環境下會出現隨機丟包。三是裝置限速與策略,部分網路會對特定類型的流量做限速,超出部分被丟棄。四是 MTU 不符,封包在轉發時被分片,分片遺失會導致整個封包重傳。四類來源的處理方式不同:佇列溢出要換線路,無線干擾要換接入方式,限速要換連接埠或協定,MTU 問題要調整用戶端的 MTU 設定。

壅塞控制決定了丟包的代價

傳統 TCP 壅塞控制把丟包當成壅塞訊號,一旦偵測到丟包就大幅縮小壅塞視窗,吞吐量隨之塌陷。BBR 換了一個思路:持續估計鏈路的頻寬與最小往返時間,依估計值發送,丟包不再必然導致降速。這就是 Hysteria2 在丟包鏈路上表現更好的根本原因。不是它更快,而是它對丟包的反應不同。理解了這一點,就不會再糾結「為什麼同一個節點,換協定之後速度差這麼多」。

晚高峰為什麼慢

國際出口的頻寬是共用資源。晚間是使用高峰,出口鏈路被佔滿,佇列變長,排隊延遲上升,佇列溢出後開始丟包。表現是延遲從平時的水準抬升、丟包率上升、吞吐量下降,而且同一時段內波動很大。專線與最佳化中轉的價值在這個時段最明顯:它們不與該出口的公網流量搶同一佇列。如果只在晚上慢、白天正常,基本可以判定是共用出口的壅塞,而不是區域網路或用戶端的問題。

自測的侷限

ping 用的是 ICMP,和 TCP 走的不一定是同一條佇列,ping 值低不代表代理快。測速工具測的是瞬時吞吐量,連續取樣才能看出穩定性。合理的觀察方法是同一時段多次取樣,看抖動與丟包率,而不是盯住單次峰值。測速節點本身的頻寬也可能是瓶頸,選一個離落地位置更近的測速目標,結果才有參考價值。

把這五種情況記住,大多數問題在提交工單之前就能定位到具體一層。

依情境選協定

選型有一個固定的決策順序:先看線路,再看協定,最後調用戶端參數。線路決定物理上限,協定決定在同一條線路上的效率,用戶端參數決定細節體驗。順序反了,就會陷入反覆換協定卻不見改善的循環——因為瓶頸根本不在協定上。

決策順序

第一步問情境是否對抖動敏感:會議、即時協作、遊戲屬於這一類,優先專線。第二步看鏈路的丟包情況:如果長期存在隨機丟包,QUIC 系協定的壅塞控制能救回吞吐量。第三步看裝置類型與耗電限制:手機長時間掛機優先 TCP 系。第四步看是否需要 UDP 轉發:部分應用程式依賴 UDP,需要用戶端與線路同時支援。

4K 串流

4K 串流對持續頻寬的要求明顯高於 1080p,位元率通常在兩位數 Mbps,而且要求穩定——緩衝區一旦被抽乾就會轉圈。選型的重點是持續吞吐量與線路穩定性,而不是峰值。TCP 系協定搭配中轉或專線線路,通常比在 UDP 上追求峰值更穩。如果所在網路對 UDP 限速,QUIC 系協定反而會拖後腿。區域片庫與出口地區的關係,在串流媒體專題文章裡有更具體的對照。

視訊會議

會議對延遲與抖動敏感,對頻寬要求不高。首選專線或最佳化中轉,協定用 TCP 系即可。會議期間不要切換節點,切換會造成幾秒的中斷,而在會議裡幾秒足以打斷一段發言。如果會議軟體本身走 UDP,需要確認用戶端沒有把 UDP 流量丟棄,否則會出現能聽到聲音、看不到共享畫面的情況。

大檔案與備份

高頻寬、高延遲的鏈路上,壅塞控制的影響被放大。BBR 一類的演算法能把管道填滿,Hysteria2 在這類情境裡優勢明顯。需要注意的是流量消耗:一次完整備份可能用掉大半個月的方案額度,流量包更適合這種突發用量,用完為止、永久不過期,不必為了一個月的峰值去升級月訂閱。

行動裝置長時間掛機

耗電優先。選 TCP 系協定,心跳間隔調長,開啟分應用程式代理。不要在手機上長時間跑 QUIC 系協定做大流量下載,發熱與耗電都會明顯上升。如果只是收訊息、看網頁,這類輕量使用對協定幾乎無感,選最省電的組合即可。

AI 工具與長連線

AI 工具的回應是串流式的,一次對話可能維持幾十秒的長連線。這類情境對頻寬要求不高,對穩定性要求高——連線中斷會讓整段回答作廢。選穩定線路加 TCP 系協定,比追求低延遲更實際。如果經常遇到回答中途停止,先排查線路抖動,而不是換協定。相關的排查思路在幫助中心有更細的條目。

即時對戰遊戲

物理距離是硬限制,協定能做的最佳化有限。需要 UDP 轉發,並且線路的抖動要小。跨洲對戰的延遲下限由光速決定,任何協定都無法突破。把預期放對位置,比反覆換節點更有用。

方案與情境的搭配也值得說一句:月訂閱 ¥9.9 含 60GB,適合輕量瀏覽與訊息類使用;¥18 含 250GB,涵蓋日常串流與辦公;¥28 含 500GB,適合重度觀看與多裝置同時使用。流量依開通日每月重置,中途升級差價折算成剩餘天數。突發的大用量用流量包更划算,¥158 對應 300GB、¥358 對應 1000GB、¥658 對應 3000GB,用完為止、永久不過期。

平台支援與訂閱匯入

協定與線路選定之後,最後一哩在用戶端。同一份訂閱在不同平台上的表現可能不一樣,差別主要來自核心對協定的支援範圍、背景保活策略,以及代理的接管方式。理解這三處差異,能省掉大量「同一個節點在電腦上好好的、在手機上不行」的困惑。

五個平台的差異

Windows 有系統代理與 TUN 兩種模式,系統代理只對遵守系統設定的應用程式生效,TUN 則能接管不遵守系統代理的程式。macOS 的權限模型更嚴格,首次啟用 TUN 需要授權並安裝網路擴充功能。iOS 的背景限制最嚴,需要依指引加入設定,分應用程式代理的能力有限。Android 支援分應用程式代理,但省電策略需要手動放行。Linux 既有命令列用戶端也有圖形用戶端,適合把代理做在路由層,讓整個區域網路共用一條出口。

訂閱匯入的四個步驟

第一步,登入使用者面板,進入訂閱頁。第二步,複製訂閱連結。第三步,在用戶端選擇從剪貼簿匯入,或直接貼上連結。第四步,首次匯入後手動更新一次,確認節點清單已重新整理。四步都完成後,選一條線路連線,再用任一個查詢出口位址的頁面確認出口地區與所選線路一致。

https://example.com/sub?token=YOUR_TOKEN

上面是格式示意,真實連結在登入後的面板裡取得。訂閱連結等同於憑證,拿到它的人可以使用你的流量額度,不要貼到公開論壇或截圖裡。如果懷疑連結外洩,在面板裡重置訂閱即可讓舊連結失效。

更新訂閱的時機

節點調整、協定變更、方案續訂之後,都需要在用戶端手動更新一次訂閱。部分用戶端支援定時自動更新,間隔建議設在數小時級別,過於頻繁的拉取沒有意義,也會讓節點清單在切換時短暫不可用。

不限裝置數與頻寬分攤

VPNLW 的訂閱不限裝置數,同一帳號可以在 Windows、macOS、iOS、Android、Linux 上同時使用。需要注意的是,一條線路的頻寬是共用的,同一時間多台裝置跑大流量,單台裝置的可用頻寬會下降。家庭情境下把下載任務安排在非高峰時段,體驗會更好。這也是為什麼「裝置數不限」與「頻寬無限」是兩件事,前者是授權,後者是物理資源。

用戶端的取得入口在使用者面板內,登入後依平台下載即可。訂閱與用戶端都放在面板裡,不在行銷頁提供靜態安裝檔,這樣版本與帳號狀態能保持一致。

分層排錯與驗證

排錯最忌一上來就換節點。連線是分層建立的,任何一層出問題表現都像連不上,逐層排除比反覆試錯快得多。本章給出一套可以照著做的流程,以及每一步的驗證指令。

六層模型

第一層是接入層:裝置是否連網、Wi-Fi 是否正常、是否被強制入口頁攔截。第二層是名稱解析:網域能否解析到正確位址,是否被本機 DNS 劫持。第三層是傳輸握手:能否與節點建立 TCP 或 UDP 連線。第四層是協定協商:身分校驗是否通過,時間是否同步。第五層是分流規則:這條流量是否被規則放行。第六層是應用層:目標服務本身是否可用。

每一層怎麼驗證

接入層用 ping 閘道確認本機鏈路。名稱解析用 nslookup 指定一個公用解析器對照。傳輸握手用 curl 的詳細輸出看連線是否建立、TLS 是否完成。協定協商看用戶端日誌裡的握手結果,失敗通常會有明確的錯誤碼。分流規則用全域模式對照。應用層換一個目標網站對照,排除目標服務本身故障。

ping -c 4 192.168.1.1
nslookup example.com 1.1.1.1
curl -v --max-time 10 https://example.com/
traceroute example.com

這四條指令涵蓋了前三層。範例位址是通用寫法,把閘道換成自己網路的實際位址即可。

分流規則造成的假故障

規則模式下,部分網域走直連、部分走代理。如果某個應用程式打不開而其它應用程式正常,先切到全域模式對照:全域正常說明是規則問題,全域同樣異常說明是線路或協定問題。這個對照能把排查範圍一次縮小一半,是最省時間的一步。規則問題通常來自自訂規則寫錯、網域後綴比對過寬,或者規則集沒有更新。

時間同步為什麼重要

VMess 一類的協定會用時間戳做校驗,系統時間偏差過大時握手會被拒絕。表現是設定沒錯、節點在線、就是連不上。檢查一下裝置的自動時間同步是否開啟,長時間休眠的筆電與老裝置最容易出現這個問題。

什麼時候需要提交工單

逐層驗證之後仍然無法定位,再提交工單。工單裡寫清:平台與用戶端、使用的線路、出現問題的時段、已經做過的驗證步驟與結果。資訊完整的工單處理速度明顯更快,因為不需要來回確認基礎資訊。如果問題只在特定時段出現,標註具體時間點,便於對照線路側的紀錄。

術語與參數速查

這一章把前面用到的術語集中列出,並附上服務本身的參數,方便查閱。術語依筆畫與字母混排,不做嚴格分類。

術語表

方案與流量包

服務參數

覆蓋:120+ 國家 / 230+ 線路。裝置:不限台數。支援平台:Windows / macOS / iOS / Android / Linux。付款方式:支付寶 / 微信 / USDT。退款:7 天無條件退款。註冊:無需電子郵件地址,使用者名稱加密碼即可註冊。加密採用軍工級加密。

繼續閱讀

想依步驟完成第一次設定,看快速上手教學;想比較方案與流量包,看方案與價格;想依地區挑線路,看全球線路清單;常見問題集中在幫助中心。三篇延伸文章可以接著讀:新手名詞速查、區域片庫與 4K 頻寬實測對比、Android 背景保活與分應用程式代理。