情境資訊 · Clash 技術部落格

Zoom、Teams、Slack 用 Clash 怎麼分流？遠端辦公會議與登入疑難排解

Zoom、Teams 和 Slack 能登入，不代表會議媒體、檔案與訊息長連線都正常。按實際失敗動作檢查接管和出口，公司內部系統繼續使用組織要求的 VPN，並用實際會議與檔案傳輸重新測試。

閱讀正文回到部落格
  • Zoom
  • Teams
  • Slack
  • 遠端辦公
本文目錄
文章作者
Clash 官方
發布日期
更新時間
預計閱讀
約 8 分鐘

辦公應用程式最麻煩的故障，往往是能登入和傳送訊息，卻在開會、分享螢幕或開啟附件時失敗。這時需要驗證的是具體任務，而不是再次開啟首頁。分別測試會議媒體、訊息連線和檔案存取，同時保留公司要求的內部網路存取方式，才不會修好會議卻影響辦公系統。

能登入卻無法開會或下載附件，分別檢查哪類請求？

記錄 Zoom、Teams 和 Slack 失敗的是登入、附件還是音視訊，再查看下表的對應服務。UDP 常用於會議媒體，WebSocket 用於即時訊息連線；只測試網頁，不能代替會議和訊息連線的檢查。

官方網路要求裡最值得注意的差別

應用關鍵流量2026 年仍應參考的官方資訊
Zoom登入與網頁走 TCP 443，會議媒體優先 UDP會議常用 UDP 3478-3479、8801-8810；IP 段會更新
TeamsMicrosoft 365 登入、聊天、檔案與媒體分開媒體推薦直連 UDP 3478-3481，端點清單按月更新
Slack訊息依賴 TCP 443 上的持久 WebSocketSSL 檢查必須支援 WebSocket，或排除官方列出的 wss 網域

網域規則適合處理登入和普通 HTTPS，請求媒體時還要考慮 UDP、企業防火牆和應用處理程式。不要把官方維護的 IP 清單永久抄進個人 YAML；Zoom 和 Microsoft 都會更新範圍，企業環境應由管理員訂閱官方清單。

把辦公網頁與即時會議分成兩個策略群組

聊天、檔案和登入需要出口穩定，會議則更在意 UDP、上行和抖動。可以用 Work-Web 管理普通請求，用 Meeting 選擇已經驗證過 UDP 的節點；如果公司網路允許 Zoom 或 Teams 媒體直連，Meeting 組也應保留 DIRECT。

規則只示範穩定網域，媒體 IP 以官方清單為準
proxy-groups:
  - name: Work-Web
    type: select
    proxies: [REPLACE_WITH_WORK_NODE, DIRECT]
  - name: Meeting
    type: select
    proxies: [DIRECT, REPLACE_WITH_UDP_NODE]

rules:
  - DOMAIN-SUFFIX,zoom.us,Meeting
  - DOMAIN-SUFFIX,zoom.com,Meeting
  - DOMAIN-SUFFIX,teams.microsoft.com,Work-Web
  - DOMAIN-SUFFIX,teams.cloud.microsoft,Work-Web
  - DOMAIN-SUFFIX,slack.com,Work-Web
  - DOMAIN-SUFFIX,slack-edge.com,Work-Web
  - MATCH,DIRECT

兩個 REPLACE_WITH 名稱都要換成目前設定中已有的節點名稱。如果原設定已規定其他流量的預設處理方式，用原來的 MATCH 規則替換範例最後一條 MATCH,DIRECT。先手動固定策略，避免會議中途自動切換出口。

Zoom 能登入卻卡在 Connecting，去看媒體 UDP

瀏覽器能開啟 zoom.us，只證明 HTTPS 登入入口可達。進入會議後一直 Connecting、能看到畫面卻聽不到聲音，或共享幾分鐘後掉線，都應在 Clash 連線頁和防火牆日誌裡查看 UDP。Zoom 官方目前列出的會議媒體連接埠包括 UDP 3478-3479 與 8801-8810。

個人網路可以用同一節點先做 Zoom 的音頻與共享測試；企業網路不要自行複製整段 IP 白名單，應交給管理員根據 Zoom 官方頁面維護。節點沒有 UDP 支援時，切換網頁代理不會修復會議媒體。

Teams 檔案能開啟但會議卡頓，檢查媒體 UDP

Teams 登入會經過 Microsoft 身分服務，聊天與檔案還可能進入 SharePoint 或 OneDrive，實時媒體則使用另一組端點。Microsoft 2026 年網路指南繼續建議媒體繞過代理、保持盡可能短的路徑，並放行 UDP 3478-3481。

如果公司強制代理或 SSL 檢查，應以組織策略為準。個人 Clash 規則不應覆蓋公司 VPN 傳送的私有網段和內部 DNS；網頁與聊天已正常時，不要為了會議延遲把全部 Microsoft 365 流量換到另一地區。

Slack 灰條反覆顯示重連，直接跑官方 WebSocket 測試

Slack 專項檢查

  1. 開啟 my.slack.com/help/test

    從目前工作區執行連線測試，查看 Primary 與 Backup WebSocket。

  2. 檢查 SSL 解密

    如果企業代理進行 SSL 解密卻不支援 WebSocket，應由管理員將 wss-primary.slack.com、wss-backup.slack.com 和 wss-mobile.slack.com 排除在解密之外。

  3. 收集 Net Logs

    桌面端 Help → Troubleshooting → Restart and Collect Net Logs，可記錄真正斷開的連線。

  4. 區分 Huddle

    文字穩定但 Huddle 失敗時，在 Audio & video 設定執行音影片測試，不重置工作區。

公司 VPN 已經接管內部網路時，不再疊第二個 TUN

如果電腦還要連線公司 VPN，優先保住公司傳送的私有網段和內部 DNS。Clash 只處理確實需要的外部網頁，比兩張虛擬網路介面卡互相爭搶預設路由更穩。

瀏覽器已登入，桌面用戶端仍回到登入頁

讓登入驗證、登入後回到應用程式的請求和應用程式內請求都使用同一 Work-Web 出口。檢查系統時間，以及預設瀏覽器能否完成這次跳轉；不要在登入中途切換節點。

公司網頁正常，Clash TUN 一開就失效

退回 Clash 系統代理；私有網段和內部 DNS 繼續交給公司 VPN。

文字訊息正常，附件打不開

查 SharePoint、Slack 檔案網域或 CDN 的實際請求，不改會議 UDP。

移動熱點會議正常，公司 Wi-Fi 失敗

把結果交給網路管理員，重點查 UDP 與 SSL/WebSocket 檢查。

會議中途自動換節點後斷開

Meeting 組改為固定選擇，重新入會建立新會話。

分流完成後的實際驗證

  • Zoom 能完成登入，並連續測試音頻、影片和螢幕共享
  • Teams 能傳送訊息、開啟檔案，並進入一次測試會議
  • Slack 官方測試中的 Primary 與 Backup WebSocket 通過，檔案和 Huddle 分別可用
  • 公司內部網路頁面與內部 DNS 仍由公司 VPN 處理，退出 Clash 後不會留下系統代理

參考資料