一、先對齊現象：進會慢、共享畫面與斷續常是三條不同的路

Zoom 桌面程式同時依賴多種連線：帳號登入與會議排程、會議室頁面與縮圖等控制面內容、下載與更新模組所依賴的CDN 邊緣，以及真正承載聲音與畫面的媒體路徑（多與 WebRTC、UDP、以及區域性媒體主機有關）。當你遇到Windows 會議卡頓時，請先分辨症狀落在哪一段：若卡在「加入會議」轉圈很久，瓶頸多半在 TLS 握手、DNS 或控制面網域仍被錯誤直連；若已進房但共享螢幕一按就失敗或黑畫面，常見是某一條媒體或信令路徑被規則拆到不同出口；若聲音「偶爾正常、多數時間爆音或掉線」，則要同時懷疑 WebRTC 候選路徑、UDP 可達性，以及Zoom CDN 分流是否讓下載與即時串流搶佔同一節點頻寬。

因此，請避免一開始就把所有問題都歸咎到「換一個節點」。較務實的做法是：先用連線日誌把「登入／加入會議」「會中操作（共享、白板）」「語音視訊媒體」三段分開觀察，確認各自命中的策略與 DNS 行為，再決定要不要把 CDN 類與媒體類拆到不同策略群組。若你尚未成功匯入訂閱或策略名稱不確定，建議先完成《Clash 訂閱連結怎麼用？機場設定檔案一鍵匯入完整教程》，避免在錯誤的群組名稱上反覆試錯。

二、兩類根因：全量代理誤傷 vs. CDN／媒體鏈路沒走對

全量代理誤傷指的是：不區分服務類型，把所有 TCP／UDP 一律導向同一個遠端節點，或讓本可直連的區域邊緣也繞一大圈。對 Zoom 而言，這會表現為整體延遲上升、DNS 查詢變慢、甚至讓本該就近建立的媒體連線被迫走不適合 UDP 的中繼。另一類是鏈路沒走對：登入與會議控制面走代理，但某條 CDN 下載或媒體子網域仍落在 DIRECT，被公司防火牆或地區策略攔截；或反過來，媒體走了一個對 UDP 不友善的出口，而信令仍在另一個出口，導致協商成功、媒體卻頻繁重連。

要區分兩者，核心證據仍是連線日誌：同一分鐘內，是否出現大量 Zoom 相關主機名稱命中不同策略群組；以及在你關閉「全量」或改為分流後，症狀是否呈現「整體一起好轉」（偏誤傷）或「只有某一類子網域改善」（偏拆錯路）。釐清後再寫 Zoom Clash 規則，才不會越改越亂。

三、Zoom 流量分層：控制面、CDN 與 WebRTC 媒體

實務上可把 Zoom 相關連線粗分成三層。第一層是帳號與會議控制：建立會議、加入連結、顯示與會者列表等，通常以 HTTPS 為主，延遲敏感較低但要求握手穩定。第二層是靜態與下載類 CDN：安裝程式更新、會中載入圖示或共用素材時，可能命中與主站不同的邊緣主機名稱。第三層是媒體與 WebRTC：語音、視訊與螢幕分享位元組，常涉及 UDP、TURN／中繼候選，以及區域性媒體伺服器前綴；這一層若與前兩層出口不一致，最容易出現「看得到介面、聲音卻爆」或「共享畫面一開就掉」的體感。

撰寫 Zoom CDN 分流時，請記得 CDN 與媒體的優化目標不同：前者偏吞吐與快取命中，後者偏抖動與封包遺失容忍。把兩者硬塞在同一個只看延遲數字的節點選擇裡，可能出現下載看起來正常、語音卻頻繁切換路由的現象。若你希望對照另一套「長連線＋CDN」的桌面協作場景，可參考《Figma 畫布一直轉圈？用 Clash 分流 CDN 與 WebSocket 穩住協作》，理解「介面與資料通道不宜被規則拆散」的共同原則，但請勿把 Figma 網域抄進 Zoom 規則。

四、Windows 重點：為什麼「只開系統代理」常常不夠

Zoom 桌面程式並不等同於 Edge 或 Chrome；即使你已在 Windows 設定中開啟系統 HTTP 代理，仍可能遇到部分連線以不同方式發起，或被公司端點安全軟體、防火牆政策影響。實務上，若症狀主要發生在Zoom Windows客戶端而不是瀏覽器版，我們通常會優先建議你驗證 TUN 模式是否能讓相關程序一致進核心，因為它能在網路層統一接管符合條件的流量。

啟用 TUN 會涉及路由與系統權限，請先閱讀《Clash TUN 模式開啟方法》再操作，並在開啟後回到連線清單確認 Zoom.exe 相關連線是否出現在核心中。若你同時使用 WSL2 或 Docker Desktop，也可對照《WSL2 共用本機 Clash 代理》理解「哪些流量預設不會自動跟著 Windows 代理走」，避免把問題誤判成單一視訊軟體故障。

五、建議排查順序（先證明流量進核心，再談節點）

下列順序刻意把「換節點」放在中後段：先確認 Zoom 相關連線有經過 Clash，且規則命中符合預期，再談線路品質與 UDP。

  1. 確認 Clash 正在執行，並依場景選擇系統代理或TUN；若問題主要出在桌面客戶端，優先驗證 TUN。
  2. 在「加入會議」「開啟視訊」「開始共享螢幕」三個動作下，各開啟一次連線日誌，檢查主機名稱後綴是否一致命中預期策略，而非被過寬的 DIRECT 或地區清單提前截走。
  3. 檢查 DNS 模式（是否 fake-ip）、以及 Zoom 相關後綴是否在 fake-ip-filter 或 nameserver-policy 中有合理設定，避免解析與連線策略互相打架。
  4. 若媒體仍異常，檢視是否有 UDP 相關連線被阻擋、或 WebRTC 候選是否反覆在「中繼」與「直連」之間切換。
  5. 在規則已正確命中的前提下，再為 CDN 與媒體分別挑選穩定、掉包低的節點；若上游網路限制 UDP，語音與共享仍可能異常，此時才需要回到網路供應商或會議政策層面處理。

若出現埠號占用、訂閱無法拉取等通用錯誤，請併讀《Clash 常見報錯解決方案》；本文聚焦 Zoom 場景下的Zoom CDN 分流與WebRTC對齊。

六、網域怎麼收集：以日誌為準，不要只抄過期清單

Zoom 會依區域、版本與會議類型調整邊緣與媒體主機命名；第三方整理的清單可作起點，但最可靠的方式仍是在你自己的環境收集主機名稱。Windows 上可搭配「工作管理員 → 效能 → 開啟資源監視器 → 網路」觀察連線時的遠端位址對應名稱，或在 Clash 用戶端的連線清單中依程序或關鍵字篩選 zoom。

將觀察到的名稱依後綴分組後，優先使用 DOMAIN-SUFFIX 對齊子網域樹，比過寬的 DOMAIN-KEYWORD 更不易誤傷其他服務。若你看到下載或更新檔來自第三方公有雲邊緣，請只加入「該次失敗時間點實際命中」的後綴，避免把整個超大後綴一刀切進代理，拖慢其他網站。

七、實務上常見的 Zoom 網域方向（以實測為準）

下列為多數環境下登入、加入會議與雲端功能會出現的典型後綴家族；實際是否全部需要、以及是否應走同一策略群組，請以你的連線日誌為準：

  • zoom.us：主站、部分網頁流程與短連結常見。
  • zoom.com：企業與部分國際化路徑中常見，請與 zoom.us 一併觀察是否被規則拆開。
  • zoomgov.com：政府版客戶端若啟用，控制面與媒體可能落在獨立後綴；一般環境可略過，但若日誌出現務必個別處理。
  • zoom.com.cn：中國區相關流程可能使用不同邊緣；若你不在該區卻被解析到此後綴，請優先檢查 DNS 汙染與分流衝突。
  • zoomus.cn：部分更新或相容路徑中仍可能出現在日誌裡，是否要走代理請依公司政策與實測結果決定。
  • cloud.zoom.us 等 *.zoom.us 子域：會議控制、API 與雲端功能相關主機名稱經常出現在此家族。
  • 媒體與 WebRTC：日誌中常出現帶區域或營運前綴的媒體主機名稱；請以實際出現的完整名稱歸納後綴，再寫規則。

重點在於：介面看得到、加入會議卻很慢時，優先懷疑控制面與 DNS；進房後共享或視訊一開就爆時，優先核對媒體與 WebRTC 相關主機名稱是否與登入流量同一出口，並檢查 UDP 是否被阻擋。

八、DNS 與 fake-ip：別讓解析鏈放大「進會慢」的感受

在 fake-ip 模式下，Clash 會先回傳虛擬位址再在連線階段決策出口。若 DNS 與規則配合不當，可能出現「解析看起來成功、實際 TLS 對錯出口」或反覆重試。Zoom 客戶端在加入會議時會持續嘗試多個子網域，任一條解析被汙染或指向不理想的路徑，轉圈時間就會被拉長。

實務上可以分兩步：第一，確認你的 DNS 上游對目標區域可信且可達；第二，對反覆出問題的後綴在用戶端支援的欄位中設定較穩定的解析策略（例如指定 DoH），並在調整後用連線日誌比對命中是否與預期一致。若改 DNS 後加入會議明顯變快，代表瓶頸有相當比例在解析鏈路，而非單純節點速度。

九、分流設計檢查清單（請以你的日誌為準）

下表整理撰寫 Zoom Clash 規則時的檢查角度；欄位中的後綴會隨營運調整，務必以實測主機名稱為準。

類型常見主機名稱方向設定提示
登入與會議控制zoom.us、cloud.zoom.us 等與排程／加入連結同一策略脈絡，避免 API 走代理、靜態資源直連。
CDN 與下載日誌中出現的 CDN 邊緣子域更新與大檔下載可與媒體拆群組，但別讓其中一條直連遭區域干擾。
媒體與 WebRTC日誌中的區域媒體前綴與 UDP、TURN 關聯高；需同步確認 TUN 與防火牆是否阻擋媒體埠位。
企業／政府版zoomgov.com 等與一般用戶端網域集合不同；規則請分開維護。

十、分流規則範例（請替換為你的策略群組名稱）

下列 YAML 片段示範「把 Zoom 相關後綴明確指向代理群組」的寫法；請將 PROXY 替換為實際策略群組名稱，並維持規則順序：更具體的 Zoom 條目應放在過寬的 MATCH 與地區直連清單之前。若你希望「CDN／控制面」與「媒體」分流到不同群組，可定義 PROXY_WEB 與 PROXY_MEDIA，再依日誌微調。

# Example only — replace PROXY_WEB / PROXY_MEDIA with your policy group names
rules:
  - DOMAIN-SUFFIX,zoom.us,PROXY_WEB
  - DOMAIN-SUFFIX,zoom.com,PROXY_WEB
  - DOMAIN-SUFFIX,zoomgov.com,PROXY_WEB
  - DOMAIN-SUFFIX,cloud.zoom.us,PROXY_WEB
  - DOMAIN-SUFFIX,zoom.com.cn,PROXY_WEB
  - DOMAIN-SUFFIX,zoomus.cn,PROXY_WEB

若日誌中出現其他媒體專用主機名稱，請以 DOMAIN-SUFFIX 逐條補上；不確定時寧可先記錄完整主機名稱，再查後綴歸屬，避免關鍵字規則過寬。

十一、WebRTC 與 UDP：規則正確之後仍要檢查「能不能通」

即使 Zoom 相關網域都已命中代理群組，若你的網路環境或節點型態對 UDP 不友善，語音與共享螢幕仍可能表現為高延遲或頻繁重連。此時請把觀察重點從「延遲數字」轉成「UDP 是否實際可到」與「WebRTC 候選是否穩定」。部分公司網路會阻擋非標準埠或非 HTTP 流量，這不是 Clash 規則能單獨解決的範疇。

協定層面也可參考《Shadowsocks vs Trojan vs Hysteria2》，理解不同傳輸方式對 UDP 與長連線的差異。請記得：節點再快，若規則讓某一條 Zoom 子網域直連失敗，使用者體感仍會是「進會議室轉很久」或「一共享就掉線」。

十二、圖形用戶端中如何少踩坑

在 Clash Verge Rev 等用戶端中，建議開啟即時連線清單，篩選 zoom 或上述後綴關鍵字，逐條確認策略。若某條顯示 DIRECT，請回到規則表檢查是否有廣告攔截、地理分流或「繞過區域網」類規則前置命中。

若桌面端基礎設定尚未完成，可先依《Clash Verge Rev 完整設定教學》跑通訂閱與模式，再回到本文補 Zoom 專用規則，可節省大量試錯時間。

十三、小結：把「卡頓與共享失敗」變成可驗證的規則問題

2026 年在 Windows 上使用 Zoom 遇到進會慢、共享螢幕異常或音視訊斷續時，可依序確認：客戶端流量是否進核心、DNS 與 fake-ip 是否一致、Zoom CDN 分流與WebRTC媒體是否各自命中合理出口，以及UDP 與節點型態是否支援你的會議型態。當連線日誌能清楚對應主機名稱與策略，你就不需盲目更換節點卻無法改善體驗。

當你希望把觀測、規則與核心更新集中在同一套成熟用戶端時，官方維護方案通常能降低手寫 YAML 的低階錯誤；相較其他同類工具，Clash 在規則透明度與日誌對照上往往更一致。→ 立即免費下載 Clash，開啟流暢上網新體驗