會議卡頓的根源:封包遺失與抖動,不是頻寬
視訊會議是即時雙向串流。編碼器大約每 20 毫秒產生一個影格,接收端用數十到數百毫秒的抖動緩衝把影格排齊後再播放。中途掉一個封包,重傳已經來不及,播放端只能用上一個影格頂替,畫面就是一塊馬賽克或一瞬間的定格;連續封包遺失時,聲音會先中斷。整個過程對延遲波動極度敏感,對峰值頻寬則幾乎沒有要求。
頻寬反而是最容易滿足的一項。1080p 群組會議大約需要 2.5~4 Mbps 上行,1080p 螢幕分享大約需要 1.5~2.5 Mbps。多數辦公寬頻的上行都在這個區間之上,所以「頻寬夠、會議還是卡」的情況,問題基本上都落在另外三個指標上。
| 指標 | 對會議的影響 | 常見可感知範圍 | 怎麼測 |
|---|---|---|---|
| 封包遺失率 | 畫面馬賽克、聲音先中斷 | 持續高於 1% 開始可感知,高於 3% 就很明顯 | 連續 ping,或用戶端內建的封包遺失統計 |
| RTT 來回延遲 | 搶話、互動遲鈍 | 單程超過 150 ms 即可感知 | ping 會議服務網域,觀察平均值 |
| 抖動 | 抖動緩衝被拉長,對方聲音慢半拍 | 波動超過 30 ms | 連續 ping,觀察 RTT 的高低起伏 |
| 上行頻寬 | 解析度被自動調降、分享畫面模糊 | 上行被佔滿時出現 | 會議軟體內建的統計面板 |
表中的數值是常見經驗範圍,用來判斷方向,不是廠商承諾值;實際表現還取決於編碼器與會議軟體的降級策略。
會議軟體大多同時支援 UDP 和 TCP。走 UDP 時延遲低,封包遺失會直接反映在畫面上;走 TCP 時封包遺失會觸發重傳,整體延遲因此被拉長。如果用戶端只代理 TCP,會議流量可能繞過線路走本地網路 —— 這一點要在用戶端設定裡確認,而不是看連線狀態用猜的。
三種線路類型在晚間尖峰的真實差別
線路類型描述的是封包從你的電腦到目標伺服器走哪條實體路徑,和用什麼協定封裝是兩件事。協定(Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC)決定握手方式、抗封包遺失能力和 UDP 支援;路徑決定這條路在晚上八點到十一點之間有多壅塞。兩者要分開看,才不會把「協定新」誤當成「線路穩」。
直連:路徑最短,但和所有人共用出口
用戶端直接連線到境外伺服器,流量經過公共國際出口。路徑最短,延遲通常最低;但公共出口是共享資源,晚間尖峰的封包遺失率與抖動會同時上升。適合對頻寬要求高、對延遲不敏感的用途,例如夜間同步大檔案、拉取映像檔。
中轉:中國大陸入口穩定,瓶頸在出境段
先連到中國大陸的中轉入口,再由中轉伺服器出境。多了一跳,但中國大陸這一段走的是可控鏈路,入口品質穩定;瓶頸轉移到出境段,晚間尖峰穩不穩,取決於中轉商的出口資源。多數辦公情境可以把它當成預設線路。
IEPL 專線:不經公共出口的點對點鏈路
國際乙太網路專線是點對點鏈路,不擠公共出口,頻寬與封包遺失在晚間尖峰基本不變。成本高,所以一般只涵蓋核心地區。視訊會議、遠端桌面這類對封包遺失與抖動敏感的用途,優先放在這類線路上。
| 線路類型 | 路徑特徵 | 晚間尖峰的封包遺失與抖動 | 適合的辦公用途 |
|---|---|---|---|
| 直連 | 最短路徑,經公共國際出口 | 波動大,隨出口壅塞上升 | 大檔案同步、夜間備份 |
| 中轉 | 中國大陸入口 + 出境段兩跳 | 入口穩定,出境段看資源 | 日常協作、程式碼倉庫、雲端硬碟 |
| IEPL 專線 | 點對點專線,不經公共出口 | 相對穩定 | 視訊會議、遠端桌面、網路電話 |
協定層面:基於 QUIC 的 Hysteria2 和 TUIC 在封包遺失環境下更從容,不會阻塞隊頭,還能做前向糾錯;代價是 UDP 在某些網路裡會被限速甚至阻擋,遇到這種情況換回 Trojan 或 VLESS + TLS 更穩。但協定選得再好,也救不回一條已經壅塞的實體路徑 —— 先看線路,再調協定。
依辦公情境選線路
同一個訂閱裡通常有多條線路,選哪條取決於你的主要用途。以下是四類常見辦公情境的取捨順序,判斷標準並不一樣。
視訊會議:Zoom / Teams / Meet
優先順序是封包遺失、抖動,最後才是頻寬。選 IEPL 專線,並確認用戶端已開啟 UDP 轉發。不要選帶自動負載平衡、會中途換節點的線路:切換意味著連線重建,會議會直接中斷好幾秒。
遠端桌面 / SSH / 資料庫
這類互動對 RTT 最敏感,對頻寬要求很低,5 Mbps 以內通常就夠。選實體距離近、RTT 穩定的專線入口,別為了「頻寬大」去選繞遠路的節點,繞路帶來的延遲比頻寬收益更明顯。
檔案同步 / 程式碼倉庫 / 雲端硬碟
這類流量走 TCP,封包遺失會由重傳補回來,體驗主要受頻寬影響。可以放心用中轉或直連,把專線留給會議和遠端桌面,線路資源按用途分開,比所有人擠一條線更划算。
網路電話 / 線上客服
頻寬需求比視訊會議更低,但抖動同樣致命,判斷標準和會議一致:先看晚間尖峰的延遲波動,再看頻寬。
分流規則與用戶端設定
分流的意義是把有限的專線頻寬留給會議,而不是讓所有流量擠在同一條路上。基本思路分三段:中國大陸的網域與 IP 直連,會議與協作網域走線路,其餘流量走預設出口。
# 分流規則範例(依網域與地區比對,由上往下生效)
DOMAIN-SUFFIX,zoom.us,PROXY
DOMAIN-SUFFIX,teams.microsoft.com,PROXY
DOMAIN-SUFFIX,slack.com,PROXY
DOMAIN-SUFFIX,meet.google.com,PROXY
DOMAIN-SUFFIX,github.com,PROXY
GEOIP,CN,DIRECT
MATCH,PROXY規則由上往下比對,命中第一條就生效,所以具體網域要寫在 GEOIP 之前。會議軟體除了主網域,還會連上一批 CDN 與信令網域,只寫一條 zoom.us,畫面可能出得來、螢幕分享卻仍然走直連。遇到這種情況,直接把會議軟體的處理程序整體指定走專線更省事,桌面用戶端一般支援按處理程序分流。
訂閱連結與匯入
各平台的用戶端都是把訂閱連結貼進去,更新後節點清單會自動重新整理,不需要手動逐條新增。訂閱連結等同於帳號憑證,不要貼到公開場合。同時連線的裝置數量不限,但同一條線路的頻寬是所有裝置共享的,多台裝置同時開會時,記得把非會議的下載任務移到別的線路。
各平台用戶端的差異
- Windows:TUN 模式可以接管全部流量,包括不讀系統代理的會議用戶端;首次啟動需要安裝虛擬網卡驅動程式。
- macOS:透過系統網路延伸功能建立連線,第一次連線需要在系統設定裡允許,部分權限要手動確認。
- iOS:走 Network Extension,系統會彈出視窗要求允許 VPN 設定;背景執行受系統限制,長時間會議建議接上電源並關閉低耗電模式。
- Android:需要授予 VPN 權限,並把用戶端加入電池最佳化白名單,否則螢幕熄滅後可能被系統回收,會議中途斷線。
- Linux:命令列用戶端搭配系統代理或 TUN 使用,不同桌面環境的分流生效方式不一樣,上線前實測一次。
切換策略與上線前檢查清單
再穩的線路也有維護窗口。比較省心的做法是準備主備兩條:主力放 IEPL 專線,備用放一條中轉;重要會議開始前十分鐘切到主線路,並跑一遍下面的流程。具體的線路分布可以在線路列表裡對照,出口是否真的換了,用出口 IP 查詢確認。
- 打開用戶端,確認目前線路是專線,而不是上次切換後殘留的備用節點。
- 用出口 IP 查詢確認流量確實走了線路,顯示的城市應該和節點所在地一致。
- 在會議用戶端裡發起一次迴路測試,看它統計面板裡的封包遺失與延遲。
- 確認 UDP 轉發處於開啟狀態,並確認會議軟體沒有被分流規則漏掉。
- 會議期間不切換節點、不更新訂閱 —— 兩者都會重建連線。
- ✅ 會議前十分鐘完成切換與檢查,而不是進了會議再調整。
- ✅ 行動裝置用戶端已加入省電白名單,螢幕熄滅也不斷線。
- ✅ 會議網域走專線,UDP 轉發已開啟。
- ✅ 備用線路可用,並且知道怎麼一鍵切回。
- ❌ 把「節點數量多」當成唯一的挑選標準:節點多不等於路徑好。
- ❌ 會議進行中更新訂閱或切換節點。
- ❌ 只看測速軟體的下行峰值:那是一次性的數字,和會議時的封包遺失、抖動不是一回事。
測速軟體測的是頻寬峰值,會議要的是持續穩定的低封包遺失。一條下行能跑很高、晚間尖峰封包遺失 5% 的線路,視訊會議照樣糊。判斷線路好壞,要看連續十分鐘的延遲波動,而不是一張測速截圖。連線正常但會議仍然卡時,可以先按疑難排解的步驟逐項排除。
結論:視訊會議卡不卡,關鍵在封包遺失與抖動,不在頻寬。選線順序是 IEPL 專線優先、中轉次之、直連備援;依情境分流,把專線留給會議和遠端桌面;協定層面,封包遺失環境優先考慮 Hysteria2 / TUIC,被限速時退回 Trojan 或 VLESS + TLS。上線前跑一遍檢查清單,比在會議中臨時補救划算。