為什麼會議比看影片更怕丟包

同一條國際線路,晚上看 4K 影片可能毫無問題,第二天早上開會卻一直斷斷續續。原因不在頻寬大小,而在兩類流量對丟包的處理方式完全不同。

影片網站走的是 HTTP over TCP。播放器會預讀一段內容放進緩衝,鏈路上丟一個封包,TCP 負責重傳,只要緩衝還沒播完,使用者就察覺不到。緩衝的意義,就是把網路抖動吸收掉。

視訊會議走的是另一條路。Zoom、Teams、Google Meet 這類工具基於 WebRTC,音訊用 Opus 編碼,視訊用 VP8 / VP9 / H.264 / AV1,媒體資料封裝在 RTP 裡、用 SRTP 加密,跑在 UDP 之上。UDP 不保證送達,即時媒體流也不會停下來等重傳——等一個來回把封包補回來,那一小段聲音早就該播完了。會議軟體的做法是:丟掉的就丟掉,用前一段音訊做補償。所以鏈路上丟 1%,聽感上就是每隔一兩秒出現一次輕微斷續。

三個指標裡,對會議影響從大到小的順序是:丟包 > 抖動 > 延遲。丟包直接造成內容缺失;抖動讓接收端的緩衝來不及調整,表現為聲音忽快忽慢;延遲大了,對話就會開始互相搶話。

  • 1% 丟包率的量級參考:到這個水準,語音已經能聽出斷續,畫面開始出現馬賽克
  • 150ms ITU-T G.114 建議的單向延遲上限,超過之後對話容易互相搶話
  • 20ms Opus 常用的訊框長度,接收端的抖動緩衝就是在這個量級上做調整
  • 0 UDP 媒體流等待重傳的次數:丟了就跳過,由前一段音訊做補償

把「頻寬」和「品質」分開看:頻寬決定同時能跑多少路流量,丟包和抖動決定每一路流量本身的品質。會議卡頓絕大多數時候是後者的問題,把頻寬翻一倍,也不會讓斷續消失。

三類遠距辦公場景的網路要求對照

遠距辦公不是單一場景,而是一組場景。核心有三類:會議、檔案同步、遠端桌面;再往外還有線上文件與套件管理器拉取這兩類常被忽略的流量。它們對線路的要求各不相同,用同一套標準去套,總有一類用起來彆扭。先把工作日拆開來看,哪一類占比最高。

場景 典型工具與協定 最敏感指標 線路偏好 出問題時的表現
視訊會議 / 語音 Zoom、Teams、Google Meet;WebRTC / SRTP over UDP 丟包、抖動 IEPL 專線優先,其次中轉 聲音斷續、畫面馬賽克、輪流發言時搶話
檔案同步 / 程式碼倉庫 Git、雲端硬碟用戶端、物件儲存;TCP + TLS 頻寬、往返時延 中轉或直連 進度條走走停停,大檔案反覆重傳
遠端桌面 / SSH RDP、VNC、SSH;TCP 往返時延、丟包 IEPL 專線或中轉 滑鼠漂移、輸入延遲明顯、視窗一塊一塊刷新
線上文件 / 白板 WebSocket、HTTPS 往返時延 中轉或直連 游標不同步、儲存一直轉圈
套件管理 / 鏡像拉取 npm、pip、Docker Registry;TCP 頻寬 中轉或直連 拉取逾時、驗證失敗後重新下載

表裡能讀出一條規律:越依賴即時回饋的流量,越不能容忍丟包和抖動;越能等的流量,越只看頻寬和往返時延。選線路的第一步不是比價格,而是確認自己每天在跑哪幾類流量。

IEPL 專線、中轉、直連怎麼分工

線路類型決定的是「流量從哪個出口連向海外」。常見的三種路徑,成本和穩定性基本上是一一對應的:越穩的越貴,越便宜的越看時段。

直連:成本最低,晚高峰最先受影響

用戶端直接連上海外節點,流量從本地寬頻的國際出口出去,走的是公共網際網路的國際路由。它的優點是設定簡單、頻寬給得足;缺點是國際出口在晚高峰最容易壅塞,丟包和抖動都會跟著上來。直連適合檔案同步、套件管理、鏡像拉取這類可以重傳的流量,以及不趕時間的下載。

中轉:把國際段交給最佳化路由

用戶端先連到就近的中轉節點,再由中轉節點沿著最佳化過的路由連向海外。相當於把「最後一哩」和「國際段」分開處理,國際段的路徑比直連穩定,延遲波動也更小。中轉適合遠端桌面、線上文件、網頁協作,以及大部分日常的跨境存取。

IEPL 專線:為即時流量準備的路徑

IEPL 是端到端的乙太網路專線,國際段不經過公共網際網路的出口,丟包和抖動被壓到很低的程度,延遲也穩定。它適合視訊會議、語音通話、直播這類即時流量。代價是頻寬成本最高,通常按線路分配,不適合拿來跑大檔案——把專線頻寬都給雲端硬碟同步,會議就沒得用了。

線路類型 走什麼路徑 最適合 代價與注意事項
直連 本地出口 → 公共網際網路國際路由 → 海外節點 檔案同步、套件管理、非高峰時段下載 晚高峰丟包和抖動明顯,不建議用來開會
中轉 就近中轉節點 → 最佳化路由 → 海外節點 遠端桌面、線上文件、日常瀏覽 比直連穩定,但國際段仍會受壅塞影響
IEPL 專線 端到端專線,國際段不經過公共網際網路出口 視訊會議、語音通話、直播 頻寬成本高,按線路分配,別拿來跑大檔案

一句話結論:即時流量走專線,互動流量走中轉,吞吐流量走直連或中轉。三條路徑不是三選一,而是同一份訂閱裡依場景分工,同時存在、互不排擠。

分流規則:會議流量不該繞遠路

分流的目標不是「能不能連上」,而是讓每一類流量走它該走的那條線。同一份訂閱裡,會議走專線、遠端桌面走中轉、大檔案同步走直連,三條路徑各就各位,誰也不會把誰擠掉。

分流依據通常有三種:網域與 IP 段、行程名稱(桌面用戶端)、應用程式(行動端)。最省事的是依網域分組,因為會議軟體和協作工具的網域相對固定,維護成本最低。

# 分流策略示意:欄位名稱以所用用戶端的設定格式為準
groups:
  meeting:                        # 會議流量 → IEPL 專線
    - DOMAIN-SUFFIX,zoom.us
    - DOMAIN-SUFFIX,teams.microsoft.com
    - DOMAIN-SUFFIX,meet.google.com
  interactive:                    # 遠端桌面 / 線上文件 → 中轉
    - DOMAIN-SUFFIX,notion.so
    - IP-CIDR,198.51.100.0/24     # 文件範例網段,替換成自己的遠端桌面位址
  bulk:                           # 檔案同步 / 套件管理 → 直連
    - DOMAIN-SUFFIX,github.com
    - DOMAIN-SUFFIX,registry.npmjs.org
    - DOMAIN-SUFFIX,pypi.org

規則寫完要驗證兩件事:一是會議網域確實命中了會議組;二是台灣本地網域沒有被誤判進代理組——把本地流量也塞進國際線路,只會讓專線更壅塞。如果用戶端只提供「全域」和「規則」兩檔、沒有自訂策略組,那就退一步:把會議軟體單獨設成一檔,開會時切過去,開完再切回來。

分流規則依賴網域解析正確。如果用戶端把網域交給本地電信業者的 DNS 解析,解析請求會落在代理之外,也就是常說的 DNS 洩漏;回傳的 IP 也未必和線路入口相符,部分用戶端拿到 IP 之後依 IP 分流,規則就可能對不上。檢查方法放在下一節。

用戶端與 DNS:訂閱匯入後要驗證的幾項

訂閱連結的作用不只是省去手動填入節點。節點清單、線路變更、分流規則都隨訂閱更新,伺服器端調整線路時,用戶端下一次拉取訂閱就同步了,不用逐台裝置改設定。多數用戶端支援定時自動更新,建議開到每天一次。

協定層面,用戶端支援的常見類型包括 Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC。對遠距辦公來說,協定不是第一順位:同一台伺服器上換協定,不會讓丟包和抖動消失。Hysteria2 和 TUIC 基於 QUIC,在丟包環境下有自家的壅塞控制與重傳策略,網路條件差的時候體驗會好一些,但它們仍然跑在公共網際網路上,替代不了專線。真正決定會議品質的是線路類型和出口路徑。

各平台的用戶端差異,會直接影響分流能不能用:

  • Windows / macOS:支援 TUN 模式與行程分流,可以讓會議用戶端、瀏覽器、雲端硬碟各走各的策略組;
  • iOS / iPadOS:透過系統 VPN 描述檔運作,第一次啟用會跳出「允許加入設定」,必須點允許;系統同一時間只允許一個 VPN 設定生效;
  • Android:走 VpnService,支援依應用程式分流,系統的省電策略有可能把用戶端清掉,需要加入白名單;
  • 路由器 / 旁路由:會議室裡的硬體視訊終端、裝不了用戶端的裝置,靠旁路由涵蓋。

DNS 洩漏指的是流量走了代理,但網域解析請求仍然從本地網路發出。除了暴露解析紀錄,它還會讓分流規則拿到不相符的 IP。在用戶端裡開啟「使用代理 DNS」或指定 DoH / DoT 之後,用一次 DNS 洩漏檢測頁面確認:解析出口應該和代理出口落在同一個地區。

  • ✅ 匯入訂閱後,先確認節點清單能正常重新整理,再進會議
  • ✅ 開啟 DNS 洩漏檢測頁,確認解析請求的出口和代理出口是同一個地區
  • ✅ 在用戶端裡把會議軟體單獨歸到一個策略組,而不是跟著全域走
  • ✅ 會前用用戶端提供的線路延遲顯示,確認目前線路處於可用狀態
  • ❌ 不要在會議進行中切換節點、修改分流規則或更新訂閱
  • ❌ 不要用全域模式跑大檔案同步,專線頻寬會被同步工作佔用

會議卡頓時,按這個順序排查

會議已經卡了,再回頭大改設定只會更亂。依下面五個步驟走,每一步都能排除掉一類原因。

  1. 先分清是網路還是裝置。開啟工作管理員或活動監視器看 CPU 與記憶體佔用,同時暫停正在同步的雲端硬碟和下載工作,再重現一次。裝置端的卡頓和線路的斷續,表現不一樣。
  2. 確認目前走的是哪條線路。在用戶端裡看會議流量命中的策略組和節點類型,如果落在直連節點上,先換到專線再試一次。
  3. 比較同一場會議在兩種線路下的表現。斷續消失了,說明瓶頸在丟包;依舊卡,說明問題在裝置、對端或會議軟體本身。
  4. 檢查分流與 DNS。確認會議網域命中會議組,解析出口與代理出口一致。
  5. 最後再看 MTU。如果握手正常、小檔案能傳,但媒體流一直斷續,可能是 MTU 不相符導致大封包被丟棄;把用戶端的 MTU 從預設值調小一級(例如 1400)再測。

排查順序的核心邏輯:先排除裝置和本地頻寬,再確認線路類型,最後才動設定檔。順序反了,會在一個本來沒問題的用戶端上反覆折騰。

關於會議卡頓與線路選擇的常見問題

為什麼看影片很流暢,一開會就卡?

兩類流量對丟包的處理方式不同。影片走 TCP,有緩衝與重傳作為後盾;會議走 UDP 媒體流,不重傳,丟包直接變成聲音缺失。所以同一條線路,看影片沒問題,不代表開會沒問題。

專線一定比中轉快嗎?

「快」要分開說。專線的優勢是丟包和抖動低、延遲穩定,峰值頻寬不一定比中轉高。跑大檔案,中轉甚至直連可能更快;開會和通話,專線更穩。

一份訂閱能同時涵蓋這三類場景嗎?

可以,前提是用戶端支援分流和策略組。VPNEM 的訂閱不限台數同時在線,筆電、平板、會議室終端可以共用一份訂閱,各自依場景走各自的線路。

會議前需要做哪些準備?

提前開啟用戶端,確認訂閱已更新、會議軟體命中會議組、DNS 解析出口正常;會議期間不要切換節點、改規則或更新訂閱。

結論:一套可落實的線路組合

把上面的結論收攏成一句話:即時流量走專線,互動流量走中轉,吞吐流量走直連或中轉,再用分流規則把三者固定下來。會議卡不卡,取決於丟包和抖動;檔案傳得快不快,取決於頻寬和往返時延。兩個問題用兩條路徑解決,不要指望一條線路同時滿足。

用量上可以這樣估:以會議和文件協作為主、用量不大的,月訂閱 ¥9.9 / 60GB 這一檔就夠用;全天在線、頻繁同步的,看 ¥18 / 250GB;多台裝置加上大量檔案往返,再考慮 ¥28 / 500GB。用量不穩定、不想按週期重置的,流量包 ¥158 / 300GB 起,用完為止、永久不過期,適合當補充。

以 VPNEM 為例,線路方面提供 110+ 國家、210+ 線路,訂閱不限台數同時在線,註冊無需電子郵件地址,退款期限為 60 天;付款支援支付寶、微信、USDT。先用一份訂閱把分流和線路實際跑一遍,再依實際用量調整檔位,比一開始就買大套餐來得穩妥。