線路與協議技術參考

一次跨境連線裡發生了什麼

把一次存取拆開來看,資料從裝置到目標服務要經過五個環節:裝置上的客戶端 → 本地網路(路由器、光纖數據機、無線接取)→ 電信業者出口 → 跨境鏈路 → 落地節點 → 目標服務。前兩個環節由你控制,第三個環節由電信業者決定,第四、第五個環節才是加速服務真正能最佳化的部分。

理解這句話很重要:跨境加速服務不能改變你家寬頻的品質,也不能改變目標服務本身的回應速度。它能做的是把「電信業者出口 → 落地節點」這一段換成一條更可控的路徑。所以當你覺得慢的時候,先分清問題出在哪一段,比反覆換節點管用得多。

協議與線路是兩個獨立維度

很多討論把兩者混在一起講,結果越看越糊塗。它們是兩件不同的事:

• 協議決定資料怎麼封裝、怎麼加密、怎麼握手。它是軟體層的約定,同一個協議可以跑在很多條不同的線路上。
• 線路決定封包實際走哪一條實體路徑、經過哪些機房、在哪一跳出境。它是網路層的事實,同一條線路上可以跑任何協議。

打個比方:協議像寄快遞時選的信封和封口方式,線路像快遞實際走的運輸路線。信封再講究,路線堵住了一樣慢;路線再順,信封不合規也可能被退回。兩者要分別評估,組合起來才有意義。

在本服務的客戶端裡,這個區分是直接可見的:地區側欄的每一行都帶一個線路類型徽章(專線 / 中轉 / 直連),而協議是在當前線路卡下方單獨選擇的。這樣你可以固定線路、只換協議,或者固定協議、只換線路,把變數一個一個排除掉。完整的線路清單在線路頁。

延遲由四部分構成

使用者感受到的「快慢」,在技術上主要體現為延遲。延遲不是一個單一數字,它至少由四部分疊加:

1. 物理傳播延遲。光在光纖中的傳播速度約為每秒 20 萬公里,這是硬上限。以中國東部到日本東京為例,直線距離約 2000 公里,單程理論下限約 10 毫秒,往返約 20 毫秒。也就是說,亞洲區域內 20~40 毫秒的往返延遲已經接近物理極限,繼續往下壓的空間很小。
2. 路由繞行。封包不一定走直線。公共網際網路上的路由由各電信業者之間的互連關係決定,繞經第三地是常態。一段直線距離 2000 公里的路徑,實際可能走出 5000 公里。
3. 排隊延遲。路由器與交換器的出口頻寬有限,流量大時封包要排隊。排隊延遲在鏈路利用率超過七成之後會快速上升,這是晚高峰變慢的主要原因。
4. 協議握手開銷。建立連線本身需要往返。TCP 三次握手加 TLS 握手,通常要額外付出一個到兩個往返時間。這部分與線路品質無關,但可以透過選擇協議和重複使用連線來壓縮。

前兩項由線路決定,第三項由線路品質與時段共同決定,第四項由協議決定。這就是為什麼「選協議」和「選線路」要分開做——它們最佳化的是不同的那一段。

抖動與丟包比平均延遲更影響體感

平均延遲只是三個指標裡的其中一個。另外兩個同樣重要:

• 抖動:延遲的波動幅度。平均 60 毫秒、波動正負 5 毫秒的線路,體感比平均 50 毫秒、波動正負 40 毫秒的線路好得多。視訊會議和即時語音對抖動最敏感。
• 丟包:封包沒能到達對端。TCP 系協議遇到丟包會重傳並降低傳送速率,一次百分之一的丟包在長肥管道(高延遲、高頻寬的鏈路)上可能讓吞吐量掉一半以上。

所以評估一條線路,不能只看延遲數字,還要看它在晚高峰時段的抖動與丟包是否穩定。線路頁標註了每條線路的類型,類型本身就暗示了它的穩定性特徵——這一點在下面的線路拓撲一節展開。

六種主流協議的設計取捨

協議沒有絕對的好壞,只有設計目標的差異。下面六種是當前客戶端裡最常見的選擇。它們之間有一條比任何其他差異都重要的分界線:前四種基於 TCP,後兩種基於 QUIC(也就是跑在 UDP 上)。這條分界線決定了它們在弱網環境下的行為方式完全不同。

• Shadowsocks TCP / AEAD

  輕量加密代理,資源佔用最低,舊裝置友善。

• VMess TCP / 多傳輸層

  功能完整,支援複雜分流,握手開銷偏大。

• Trojan TLS / 443

  把代理流量做成標準 HTTPS,特徵隱蔽。

• VLESS TLS / 精簡

  去掉內建加密層,握手更輕,吞吐量靠前。

• Hysteria2 QUIC / UDP

  為高丟包鏈路調校,頻寬保持能力最強。

• TUIC QUIC / UDP

  0-RTT 恢復,行動裝置切換網路後回得快。

Shadowsocks:夠用就好的輕量方案

Shadowsocks 的設計目標是「夠用就好」:一個輕量的加密代理,把本地流量加密後轉送到遠端節點。它沒有複雜的握手協議,使用 AEAD 系列加密演算法,每個連線的標頭開銷很小。

優點很明確:實作簡單、CPU 與記憶體佔用低、在舊裝置與路由器上跑得動、客戶端生態極其成熟。它的缺點也來自同一處——功能克制。沒有原生的多工,每條連線獨立建立;偽裝能力依賴外掛或傳輸層配合,裸用時的流量特徵相對固定。

適合誰:路由器、舊手機、舊電腦,以及只做網頁瀏覽和輕量辦公的情境。如果裝置效能有限,Shadowsocks 往往是最不容易出問題的選擇。

VMess:功能完整但更重

VMess 是 V2Ray 專案自研的協議,設計上比 Shadowsocks 完整得多:支援多種傳輸層(TCP、WebSocket、gRPC、HTTP/2),支援完整的路由分流規則,可以按網域、IP、連接埠決定走哪條線路。

它使用帶時間戳記的驗證握手,這是最需要留意的一點:客戶端與伺服器的時鐘必須基本一致,偏差過大時會直接驗證失敗。很多「昨天還好好的、今天連不上」的案例,根源就是裝置時間不對。

握手開銷比 Shadowsocks 大一些,建立連線需要的往返次數更多。在需要複雜分流規則的情境下,這個代價是值得的;如果只是簡單代理,它就偏重了。適合誰:需要按網域分流、需要多條出站規則、願意花時間設定的使用者。

Trojan:把代理做成標準 HTTPS

Trojan 的思路完全不同:它不發明新的加密方式,而是把代理流量偽裝成標準的 HTTPS 流量,直接使用 TLS。從外部看,它就是一次普通的 TLS 連線——因為它在協議層面確實就是。

這個設計的收益是特徵隱蔽:流量形態與存取一個真實網站幾乎沒有區別。代價是部署上的耦合——它必須佔用 443 連接埠並設定有效憑證,一旦有別的服務搶了 443,就會衝突。

效能上,Trojan 的開銷主要來自 TLS 本身。現代客戶端的 TLS 1.3 握手已經相當快,實際體驗與 VLESS 接近。適合誰:希望代理流量與一般 HTTPS 難以區分的情境,以及已經具備憑證條件的部署環境。

VLESS:精簡版的高吞吐路線

VLESS 可以理解為 VMess 的精簡版:去掉了內建加密層,把加密完全交給傳輸層(通常是 TLS)。少一層加密,就少一次資料處理,CPU 開銷和握手體積都更小。

配合 XTLS 系列流控時,VLESS 可以在轉送時減少一次「解密再加密」的過程,吞吐表現是六種裡比較靠前的。代價是它必須搭配 TLS 使用——裸 VLESS 沒有加密,不適合單獨使用。它的設定形態與 VMess 接近,熟悉 V2Ray 系客戶端的使用者上手沒有障礙。

適合誰:現代客戶端、追求吞吐量、已經具備 TLS 條件的情境。日常瀏覽與 AI 工具的長連線,VLESS 是很穩的預設選擇。

Hysteria2:為高丟包鏈路而生

Hysteria2 基於 QUIC,跑在 UDP 上。它最值得說的不是加密,而是壅塞控制:它使用為高丟包鏈路調校的壅塞控制演算法(BBR 系),在跨境這種長距離、有丟包的鏈路上,吞吐保持能力明顯好於傳統 TCP 系協議。

原因在於 TCP 把丟包一律解釋為「網路壅塞」,於是降速重傳;而跨境鏈路上的丟包很多時候與壅塞無關,降速就是白白損失頻寬。QUIC 系的協議可以在使用者空間實現更聰明的判斷,把「真壅塞」和「隨機丟包」區分開。

代價有兩個:一是走 UDP,部分網路環境對 UDP 有額外限制或限速,實際表現會打折;二是加密與壅塞控制都在使用者空間做,CPU 佔用與電量消耗比 TCP 系協議高一點。適合誰:跨境長距離、晚高峰丟包明顯、需要穩定頻寬的情境,例如 4K 串流和大檔案下載。

TUIC:把連線建立壓到 0-RTT

TUIC 同樣基於 QUIC,但設計取向更偏「快」:它把連線建立壓縮到 0-RTT,也就是在工作階段恢復時可以不帶完整握手就送出資料。

這個特性對行動裝置特別有價值。手機在 Wi-Fi 與行動網路之間切換時,連線會中斷重建;TUIC 重建連線的速度更快,體感上就是「切個網路,影片沒斷」。它的生態規模比前幾種小一些,部分客戶端支援有限,選它之前先確認你常用的客戶端是否支援。

適合誰:手機、平板等會頻繁切換網路的裝置,以及需要快速恢復連線的情境。

六種協議橫向對照

連線建立速度與資源佔用

「連上要等一兩秒」和「連上之後速度慢」是兩個不同的問題,前者屬於握手開銷,後者屬於線路品質。這一節講前者,以及它在行動裝置上的另一面:電量。

首次連線要付出幾個往返

建立一條到落地節點的連線,不是發一個封包就能開始傳資料的。以 TCP 系協議為例:

1. TCP 三次握手,消耗 1 個往返時間。
2. TLS 握手(TLS 1.3),再消耗 1 個往返時間。
3. 協議自身的驗證,通常可以搭在 TLS 握手裡一併完成。

所以在一個往返 60 毫秒的線路上,首次連線的「見面成本」大約是 120 毫秒。這個數字在開啟一個網頁時感受不到,但如果客戶端為每一個請求都新建連線,累積起來就很明顯了。

工作階段恢復把成本壓到一個往返以內

TLS 1.3 支援工作階段恢復:客戶端與伺服器在首次連線後交換一張「票」,後續連線可以憑票直接進入加密傳輸,握手壓縮到 0 個往返。QUIC 系協議(Hysteria2、TUIC)原生支援這一點,TUIC 更是把 0-RTT 當作核心賣點。

實際影響是:同一個客戶端在幾分鐘內重複存取同一節點,第二次之後幾乎沒有握手開銷。這也是為什麼「連上之後用起來很順,但每次重連都要等一兩秒」的情況,通常不是線路本身的問題,而是握手路徑上的某個環節變慢了——例如客戶端在做延遲測試、或者線路清單在同步。

多工:一條連線跑完所有請求

多工指的是在一條已建立的連線裡同時跑多個請求。好處是只需要一次握手,後續請求直接重複使用;壞處是這條連線一旦出問題,所有請求一起受影響。

Shadowsocks 沒有原生多工,VMess 與 VLESS 支援,QUIC 系協議在傳輸層天然支援。對日常使用來說,多工主要改善的是「開啟一個有很多小請求的網頁」這類情境——首屏需要載入幾十個資源的頁面,重複使用連線的體驗明顯更連貫。

行動裝置電量:三個真實的消耗來源

手機上的電量消耗主要來自三處,與協議選擇的關聯度依次遞減:

1. 心跳與保持連線。為了保持連線可用,客戶端會定期發送小封包。頻率越高越耗電。合理的區間是幾十秒一次,過於頻繁(例如每秒一次)會明顯影響待機時長。
2. UDP 與無線模組喚醒。QUIC 系協議走 UDP,部分行動系統對 UDP 的電源管理更積極,可能更頻繁地喚醒無線模組。這是 Hysteria2 與 TUIC 在行動裝置上比 TCP 系協議略耗電的主要原因。
3. 加解密與壅塞控制的運算。這兩項都在使用者空間完成,CPU 佔用高一點,電量就多一點。現代行動晶片處理這些負載很輕鬆,所以這一項的實際影響最小。

實務建議:如果裝置只是待機、偶爾收發訊息,選 TCP 系協議;如果需要長時間看影片或下載,QUIC 系協議的頻寬優勢通常超過它的電量代價。

資源佔用對照

表裡的往返次數是協議原理層面的相對描述,不是實測結果。真實體驗還取決於客戶端的實作品質、線路的往返時間,以及裝置本身的效能。換協議之前,先確認你的客戶端確實支援它——支援不完整時,「換了更差的協議」比「沒換」更糟。

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

線路拓撲講的是封包從客戶端到落地節點之間經過哪些節點、走什麼樣的鏈路。它決定了這條線路在晚高峰時段的穩定性,而這往往是「白天好用、晚上難用」問題的真正答案。

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

直連是最簡單的拓撲:客戶端直接連到境外落地節點,中間經過的各跳全部由公共網際網路的路由決定。

優點是路徑短、成本低、部署靈活。缺點也很直接:跨境段完全暴露在公共網際網路的壅塞與路由波動裡。同一條直連線路,凌晨可能跑得很好,晚上八點之後可能掉到難以使用。它的表現取決於電信業者之間的互連品質,以及那個時段有多少人同時在用這條路徑。選擇直連線路時,把它當作「夠用就好」的選項,而不是追求穩定的選項。

中轉:用一段可控鏈路換穩定

中轉的思路是在客戶端與落地節點之間加一個入口節點。客戶端先連到離自己較近的入口,再由入口節點沿一條經過最佳化的路徑把流量送到落地節點。

這樣做的好處是:客戶端到入口這一段通常在同一區域或同一電信業者網路內,路徑短、品質好;入口到落地這一段由服務方自己規劃,可以避開公共網際網路上壅塞嚴重的互連點。使用者感受到的延遲 = 客戶端到入口 + 入口到落地,兩段都比原來那條不可控的直連路徑更可預測。

代價是多了一跳,理論上多出一點延遲。但在晚高峰時段,這個「多出來的一跳」往往反而讓總延遲更低,因為它繞開了壅塞點。中轉線路的另一個好處是入口可以就近選:同一條中轉線路,不同地區的使用者可以選擇不同的入口,而不需要服務方為每個地區都部署一套落地。

需要注意的一點是:中轉節點的品質決定了整條線路的上限。入口本身如果過載,後面的路徑再最佳化也沒用。這也是評估服務方時值得關注的地方——線路清單裡標註為中轉的條目,數量不在多,而在入口是否分散。

專線:把跨境段固定下來

專線(IEPL,國際乙太網路專線)是三種拓撲裡最「重」的一種:跨境段不走公共網際網路,而是走服務方向電信業者租用的專用鏈路。這條鏈路有約定的頻寬與品質指標,不與其他人的流量搶佔同一個出口。

它帶來的直接結果是穩定性:延遲波動小、晚高峰幾乎不受影響、丟包率長期維持在很低的水平。對於需要長時間保持連線的應用(視訊會議、遠端桌面、AI 工具的長工作階段、大檔案傳輸),專線的價值主要體現在「不會突然掉下去」,而不是「峰值有多快」。

代價是成本與覆蓋。專線的單位頻寬成本遠高於公共網際網路,所以通常只在需求量最大的地區與城市部署;數量上不會像直連那樣鋪得很廣。在本服務的線路清單裡,標註為 IEPL 專線的條目集中在日本、新加坡、美國、香港、義大利等常用落地區域,這也符合專線的部署邏輯——優先放在使用者最常去的地方。

三種拓撲怎麼選

選擇順序上,一個實用的做法是:預設用中轉,遇到對穩定性要求高的任務時切專線,直連留給對延遲不敏感的輕量情境。本服務的客戶端支援在地區側欄裡直接切換線路類型,不需要重新匯入訂閱。想先看完整的線路清單,可以打開線路頁按地區瀏覽。

丟包與晚高峰壅塞的成因

晚高峰變慢是跨境存取最常見的抱怨,也是最容易被誤解的現象。它通常不是「服務方限速」,而是幾個可解釋的機制疊加在一起。理解這些機制,能幫你判斷該換線路、換協議,還是乾脆換個時段。

出口頻寬是共享的

電信業者之間的互連頻寬是有限的,而且是所有使用者共享的。晚上八點到十一點是家用寬頻使用的高峰,同一時間大量使用者在看影片、下載、玩遊戲,跨境方向的流量同步上升。當某條互連鏈路的利用率超過七成,排隊延遲就開始明顯上升;超過九成,丟包開始出現。

這解釋了一個常見現象:同一條線路,白天延遲穩定、晚上成倍上漲。線路本身沒有變化,變化的是它和別人共享的那段管道有多擁擠。

丟包為什麼會讓速度掉得比想像中多

TCP 的設計裡,丟包被當作壅塞訊號:一旦偵測到丟包,傳送方會把傳送視窗砍半,然後慢慢爬回來。這個機制在區域網路裡很有效,但在跨境這種高延遲鏈路上會放大問題。

原因在於「長肥管道」效應:往返延遲高、頻寬大的鏈路上,傳送方需要維持大量在途資料才能跑滿頻寬。一次丟包讓視窗砍半,而爬回來需要的时间與往返延遲成正比——往返 200 毫秒的線路上,視窗恢復可能要好幾秒。在這幾秒裡,吞吐量只有峰值的一半甚至更低。

所以百分之一的丟包,在高延遲鏈路上可能帶來三成以上的吞吐損失。這也是 QUIC 系協議(Hysteria2、TUIC)在跨境情境裡表現更好的根本原因:它們能在使用者空間實現更精細的壅塞判斷,把隨機丟包與真壅塞區分開,不至於一丟包就大幅降速。

無線接取段也會造成丟包

不是所有丟包都發生在跨境段。無線接取是最容易被忽略的一環:

• Wi-Fi 訊號弱。隔一堵承重牆、距離路由器較遠時,無線重傳會明顯增加。表現是延遲忽高忽低,而不是穩定地慢。
• 2.4GHz 頻段擁擠。同頻段裝置多時,頻道競爭會帶來隨機丟包。換成 5GHz 頻段通常立竿見影。
• 行動網路切換。手機在基地台之間移動時會有短暫的連線中斷,QUIC 系協議恢復得更快。
• 路由器效能不足。老舊路由器在跑加密流量時 CPU 滿載,自己就成了瓶頸,表現為「連上後整體變慢」。

排查方法很簡單:用同一台裝置、同一條線路,分別接網路線和 Wi-Fi 測試。如果網路線下明顯更好,問題就出在無線接取段,換線路解決不了。

一條可執行的排查順序

1. 確認範圍。是所有網站都慢,還是只有某一個?只有某一個的話,問題多半在目標服務或它的連線路徑,不在你的線路。
2. 換線路類型。從中轉切到 IEPL 專線。如果明顯改善,說明原來的線路在晚高峰被壅塞影響。
3. 換協議。從 TCP 系切到 QUIC 系(Hysteria2 / TUIC)。如果改善明顯,說明瓶頸在丟包導致的降速,而不在鏈路本身。
4. 換接取方式。Wi-Fi 換網路線,或換到 5GHz 頻段。這一步排除本地無線段的干擾。
5. 換時段。如果以上都無效,可能確實是該時段整體壅塞。換到人少的時段測試,能確認這個判斷。

這五步的順序是有講究的:從「影響面最大、操作最省事」的一步開始,逐步縮小範圍。多數情況下,前三步之內就能定位問題。如果排查過程中需要重新匯入訂閱,流程見教學頁。

依使用情境選協議與線路

前面幾節把機制講清楚了,這一節把它們收成可以直接用的對照。選型的核心原則是:先看情境對「延遲 / 頻寬 / 穩定性」三者中哪一個最敏感,再決定協議與線路的組合。

網頁瀏覽與文書作業

這類情境的特點是請求多、單個請求小、對首位元組時間敏感。協議上推薦 VLESS 或 Trojan,它們基於 TCP、握手開銷可控,配合工作階段恢復後重複存取幾乎無感。線路用中轉即可,除非你所在地區的中轉入口在晚高峰也吃緊。

如果要開啟的是協作文件、線上試算表這類持續保持連線的應用,建議切到 IEPL 專線。這類應用的體驗瓶頸不在峰值速度,而在「編輯時會不會卡一下」,專線的低抖動正好對症。

AI 工具與開發情境

AI 對話工具和程式碼補全工具的共同點是:一個工作階段可能持續幾分鐘到幾十分鐘,中間有大量小請求往返,而且一旦連線中斷,整個工作階段的上下文可能要重來。對這類情境,穩定性優先於峰值速度。

推薦組合是 VLESS + IEPL 專線。VLESS 在長連線上的資源佔用低,專線保證工作階段不被打斷。如果所在網路對 UDP 友善,也可以試 Hysteria2,它在長距離鏈路上的吞吐保持更好。命令列工具與開發環境的代理設定,在程式設計師情境的那篇文章裡有更細的說明。

4K 串流

串流對頻寬的要求是持續性的:4K 播放通常需要穩定維持在 25 Mbps 以上,而且要求這個頻寬在整段播放期間保持,不能忽高忽低。協議上首推 Hysteria2,它的壅塞控制在長距離鏈路上更能守住頻寬;線路用 IEPL 專線或優質中轉。

另一個容易被忽略的點是落地區域的選擇。串流平台的區域庫與你的出口 IP 歸屬地綁定,選錯地區會出現「能連上但內容不對」的情況。選地區時優先看平台本身在哪個區域有內容,再看該區域有沒有專線節點。地區與線路的對應關係可以在線路頁逐條核對。

行動裝置與經常切換網路

手機和平板會在 Wi-Fi 與行動網路之間來回切,也會在基地台之間移動。這類情境對「連線恢復速度」的要求高於一切。協議上 TUIC 是首選,它的 0-RTT 恢復能讓切換後的重連幾乎無感;如果客戶端不支援 TUIC,退而選 VLESS。

線路方面,中轉就夠了——行動網路本身的品質波動已經很大,專線的穩定性優勢在行動情境裡體現得不那麼明顯。電量敏感的使用者可以優先 TCP 系協議,待機時的心跳開銷更低。

路由器與多裝置共享

在路由器上跑代理時,CPU 與記憶體是硬限制,協議越輕越好。Shadowsocks 是這類情境最穩妥的選擇:實作簡單、資源佔用低、客戶端支援廣泛。如果路由器效能較好,也可以考慮 VLESS。

本服務的方案不限裝置數量,所以路由器、手機、電腦可以同時在線,不需要為每台裝置單獨買一份。流量是共享的,依開通日每月重置——如果你把路由器上的所有裝置都接進來,流量消耗會比單機使用快得多,這一點要有預期。

情境對照速查

客戶端裡的線路與協議設定

本服務的客戶端把上面這些選擇做成了幾個開關,不需要手寫設定。這一節說明每個開關對應的是哪一層,以及什麼時候該動它。

地區側欄與線路類型徽章

客戶端左側是地區清單,每一行顯示地區與城市,並帶一個線路類型徽章:

• IEPL 專線 跨境段走專用鏈路,穩定性最好,適合長連線與串流。
• 中轉 經就近入口轉送,日常使用的預設選項。
• 直連 直接連到落地節點,路徑最短,品質隨公網波動。

同一個地區可能同時提供多種線路類型,這時依上一節的情境對照選。切換線路不需要重新匯入訂閱,客戶端會直接重建連線。

當前線路卡與自動選線

主區上方的當前線路卡顯示三件事:落地城市、線路類型、當前使用的協議。卡片右側的「自動選線」開關打開後,客戶端會在你選定的地區範圍內自動挑一條當前狀態較好的線路。

自動選線的適用情境是「不想每次手動挑」;不適用的是「需要固定出口 IP」——例如某些服務會記住你的登入地區,頻繁變動可能觸發額外的驗證。需要固定時,關掉自動選線,手動指定一條線路。

協議切換

當前線路卡下方是協議 chips 列,列出該線路支援的協議。點一下即可切換。切換協議會重建連線,已建立的工作階段會短暫中斷,所以正在開會或下載時不要隨手切。

如果某個協議在你的網路環境下連不上,通常有兩個原因:一是該協議依賴的傳輸層被本地網路阻擋(例如 UDP 受限時 QUIC 系協議會失敗),二是客戶端版本過舊不支援。第二種情況升級客戶端即可;客戶端在面板的下載頁取得,登入後就能下載。

裝置清單與訂閱同步

視窗下方的裝置清單列出當前使用同一訂閱的裝置,每行帶平台圖示與同步狀態。本服務不限裝置數量,所以清單的長度沒有上限,它只是讓你知道有哪些裝置在用。

訂閱同步是自動的:線路有調整時,客戶端會在下一次同步時拿到新清單,不需要手動更新。底部的等寬字型一行顯示訂閱狀態與流量重置規則——流量依開通日每月重置,不是依日曆月。這一點在方案頁也有說明。

手動設定時要注意什麼

如果你用的是第三方客戶端,需要手動匯入訂閱連結。訂閱連結在面板裡取得,登入後可見,不要把它貼到公開場合——它等同於你的帳號憑證。範例格式如下(僅為格式示範,不是可用位址):

https://example.com/sub?token=YOUR_TOKEN&flag=clash

匯入時的幾個常見問題:

1. 匯入後沒有節點。多半是訂閱連結複製不完整,末尾被截斷。重新完整複製一次。
2. 節點有但連不上。檢查客戶端的協議支援情況。匯入的設定裡包含 Hysteria2 或 TUIC 節點,而客戶端版本不支援時,這些節點會顯示但無法連線。
3. 能連上但速度很慢。先確認走的是哪條線路,再依上一節的排查順序處理。
4. 更新訂閱後節點變少。確認訂閱連結沒有過期,以及是不是把不同方案的訂閱混在了一起。

術語表與延伸閱讀

最後把本頁用到的術語集中解釋一遍,方便回頭查閱。

常用術語

往返時間(RTT)

資料從客戶端送到對端再返回所需的時間,單位毫秒。它是延遲最主要的組成部分。

抖動

往返時間的波動幅度。抖動大的線路體感比平均延遲略高但穩定的線路更差。

丟包

送出的封包沒有到達對端。TCP 系協議遇到丟包會降速重傳,QUIC 系協議能在使用者空間做更精細的判斷。

長肥管道

往返延遲高、頻寬大的鏈路。這類鏈路上 TCP 的視窗恢復慢,丟包帶來的吞吐損失被放大。

多工

在一條已建立的連線裡同時跑多個請求,省去重複握手。缺點是單條連線出問題時影響面更大。

0-RTT

工作階段恢復時不帶完整握手就直接送資料,把連線建立的開銷壓到最低。TUIC 以此為核心特性。

壅塞控制

傳送方根據網路回饋調整傳送速率的演算法。不同演算法對丟包的解釋不同,直接決定高丟包鏈路上的實際吞吐。

IEPL 專線

國際乙太網路專線。跨境段走專用鏈路,不與公共網際網路流量搶佔出口,穩定性與抖動表現最好。

中轉

客戶端先連到就近入口節點,再由入口沿最佳化路徑送到落地節點。用一段可控鏈路換穩定。

直連

客戶端直接連到落地節點,全程走公共網際網路路由。路徑最短,品質隨公網波動。

落地節點

流量最終出口所在的伺服器位置,決定了目標服務看到的 IP 歸屬地。

流量重置日

本服務的流量依開通日每月重置,不是依日曆月。開通日是 8 號,下一個週期的起點就是下個月 8 號。

延伸閱讀

本頁是系統查閱手冊,如果你想按別的角度繼續深入,站內還有這些內容:

• 教學頁——從註冊到匯入客戶端的完整主線流程,第一次使用建議從這裡開始。
• 線路頁——完整的地區與線路清單,依區域分組,標註線路類型與串流支援情況。
• 方案頁——三種月訂閱方案與流量包的完整說明,以及所有方案共同包含的內容。
• 線路怎麼選——依地區、線路類型、用途三步挑節點的入門文章。
• 新手入門十問——多裝置、流量計算、限速、訂閱連結等最常被問到的問題。
• 買 VPN 怎麼避開陷阱——下單前該確認哪些事,以及退款承諾、付款管道這些細節裡的判斷依據。
• ChatGPT 加速——AI 工具的存取與穩定性專題,含長連線的設定建議。

關於本頁的說明

本頁講的是協議與線路的通用原理。文中提到的往返次數、握手開銷等描述屬於協議原理層面的相對比較,不是對特定網路環境的實測結論——真實體驗取決於你的寬頻品質、所在地區、目標服務的位置,以及使用時段。

涉及本服務的具體數字只有這些:110+ 國家 / 150+ 線路、不限裝置數量、月訂閱 ¥9.9 起、流量包永久不過期、7 天無理由退款、支援支付寶 / 微信 / USDT、無需電子郵件地址即可註冊。其餘任何數字都不代表本服務的承諾。