情境資訊 · Clash 技術部落格

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

能登入不代表會議媒體、檔案和訊息長連線都走對了。下面分別處理 Zoom、Teams 和 Slack 的網路路徑，並把公司 VPN 保留給內部系統。

閱讀正文回到部落格
  • Zoom
  • Teams
  • Slack
  • 遠端辦公
本文目錄
發布日期
更新時間
預計閱讀
約 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,DIRECT 換回原來的 MATCH 規則。先手動固定策略，不要讓會議進行到一半時自動換出口。

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

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

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

Teams 檔案正常、會議卡頓，說明不是同一條路徑

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

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

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

Slack 最有辨識度的問題不是網頁打不開，而是訊息區頂部反覆出現重連提示。先用官方連線測試確認 WebSocket，再決定是否需要讓管理員調整 SSL 檢查。

Slack 專項檢查

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

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

  2. 檢查 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 後不會留下系統代理

參考資料