场景资讯 · Clash 技术博客

Zoom、Teams、Slack 用 Clash 怎么分流？远程办公会议与登录排障

能登录不代表会议媒体、文件和消息长连接都走对了。下面分别处理 Zoom、Teams 和 Slack 的网络路径，并把公司 VPN 保留给内部系统。

阅读正文返回博客
  • Zoom
  • Teams
  • Slack
  • 远程办公
本文目录
文章作者
Clashare
发布日期
更新时间
预计阅读
约 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 后不会留下系统代理

参考资料