远程办公时，Zoom 画面卡顿、Slack 消息迟迟不刷新，或 Google Meet 能进会议却频繁掉线，未必都是节点速度不够。桌面客户端、浏览器和会议媒体流可能使用不同的网络路径：一部分请求走系统代理，另一部分通过 UDP 直连；而 Clash 的规则又可能让国内办公站点绕远。本文面向已经会导入配置的用户，说明如何为 Zoom、Slack 和 Google Meet规划分流：先确认流量与故障类型，再建立独立策略组、添加克制的域名规则，最后通过连接记录检查实际命中结果。
不同客户端版本、服务地区和企业网络策略会影响应用所访问的域名，服务商也可能调整基础设施。因此，下文的域名示例适合作为排查起点，不应理解为永远完整的官方清单。若设备由公司管理，先确认允许使用代理及自定义规则；不要尝试绕过组织的访问控制或设备安全策略。
先区分网页请求与会议媒体流
Zoom、Slack 和 Google Meet 并不是只访问一个网站。登录、聊天、文件、日程和会议控制通常会产生 HTTPS 请求；音视频则需要持续、低延迟的媒体连接。只看到登录页加载成功，并不代表会议媒体也已经通过代理。反过来，会议画面卡顿也不一定说明域名规则漏了：Wi-Fi 丢包、上行带宽不足、节点拥塞、公司 VPN 冲突，都可能造成类似现象。
常见症状可以帮助缩小范围：
- 登录或聊天加载失败：先在 Clash 连接记录中搜索应用相关域名，检查 DNS、规则命中和策略组状态。Slack 网页能打开但工作区内容转圈时，也要留意文件或消息连接是否访问了不同主机。
- 能进入会议，但声音断续或画面冻结：观察会议期间连接是否持续出现、最终策略是什么，并记录客户端提示的网络质量。媒体可能使用 UDP；仅配置 HTTP 代理并不能保证所有实时媒体流都自动转发。
- 开会正常，国内办公系统变慢：检查企业门户、内部工单、代码平台及 SSO 域名是否被过宽的代理规则捕获。把所有 Google 或所有外网一概代理，常会把本应直连的业务也带进代理。
排查时一次只改一个因素：先保持当前节点不变，确认域名命中；再切换策略组节点比较；最后才测试系统代理或 TUN。若同时换节点、改 DNS、开 TUN 并重启应用，即使问题消失，也很难知道真正起作用的是哪一项。
为会议与协作流量建立可控的策略组
不建议把会议软件规则直接写成某个固定节点。节点可能维护或拥塞，固定出口会让故障排查和临时切换都不方便。更稳妥的做法是在现有配置中复用一个代理策略组，或建立一个含自动选择与手动选择的组，再让 Zoom、Slack、Meet 的规则指向它。以下名称只是示例，实际规则中的策略组名称必须与配置中的名称完全一致。
proxy-groups:
- name: Meeting
type: select
proxies:
- Auto
- Node-A
- Node-B
- DIRECT
若你的配置已经有 PROXY、手动选择或地区策略组，不必为每个应用重复创建一整套节点列表。会议策略组可以引用已有组，也可以先用 select 手动比较；待确认多地网络表现后，再考虑 url-test。自动测速反映的是探测网址的响应，不等于 Zoom 或 Meet 的实时音视频质量，不能只凭测速延迟就认定某个节点适合会议。
策略分层还应照顾办公网络：企业内网域名、内部 DNS 名称和公司指定的 SSO 登录入口，通常应按单位网络要求处理，不能为了让会议软件“全走代理”就一并转发。若工作环境必须连接公司 VPN，应先确认 VPN 与 Clash 的路由优先级和 DNS 配置；两者同时接管默认路由时，可能出现会议控制连接正常、媒体流却断开的情况。
动手配置：添加规则并逐项验证命中
先备份当前配置，或确认你能通过客户端的配置管理恢复原文件。若使用订阅配置，直接编辑下载来的 YAML 可能在更新订阅后被覆盖；优先使用客户端支持的覆写、扩展规则或自定义规则入口。不同 Clash 客户端的菜单名称不完全一样，原则是把自定义规则放在通用规则集之前，并在规则模式下测试。
- 找到规则入口：在 Clash Verge Rev、Clash Verge 或其他 Mihomo 客户端中打开当前配置，确认可以编辑覆写规则。先记录原有规则顺序与策略组名称，避免误删订阅提供的规则。
- 添加窄范围域名：可以从这些示例开始，再结合连接记录增删。域名后缀应按实际客户端访问情况验证，不要把未确认的整类域名全部纳入。
rules:
- DOMAIN-SUFFIX,zoom.us,Meeting
- DOMAIN-SUFFIX,zoom.com,Meeting
- DOMAIN-SUFFIX,slack.com,Meeting
- DOMAIN-SUFFIX,slack-edge.com,Meeting
- DOMAIN,meet.google.com,Meeting
- MATCH,DIRECT示例最后的 MATCH,DIRECT 仅用于展示规则结构，不应拿来替换你原配置的兜底规则。保留现有配置的国内直连、广告过滤、规则集和最终匹配逻辑。实际环境可能还会出现其他主机名；应在应用运行时从连接面板观察，并逐条确认后再补充。尤其谨慎处理 googleapis.com 等共享范围较大的后缀：其他 Google 服务也可能使用它，整段代理会改变与会议无关的访问路径。
- 检查规则顺序：会议域名规则应放在可能提前匹配它们的宽泛规则之前。例如，若前面的规则集已将某个请求归入直连组，后面的精确规则就没有机会生效。保存后重新加载配置，并确认客户端没有 YAML 语法错误。
- 发起可复现的测试：先启动 Zoom、Slack 或 Meet，再进入连接面板搜索
zoom、slack、meet等关键词。记录主机名、规则类型、命中规则和最终策略组。逐个打开聊天、上传小文件和加入测试会议，避免仅靠首页加载判断全部功能。 - 做对照测试：在会议策略组中切换一个节点，保持其他条件不变，再比较入会耗时、声音连续性和丢包提示。若记录显示请求命中了目标规则但仍经常卡顿，进一步检查节点负载、网络上行、Wi-Fi 信号以及 UDP 路径，而不是不断扩大域名范围。
规则生效后仍卡顿：检查 UDP、DNS 与办公直连
如果规则面板显示 Zoom 或 Meet 域名已命中代理策略，但会议仍然断续，下一步要确认媒体流是否也进入预期路径。实时音视频常需要 UDP，而不同代理节点、传输协议、客户端内核和系统网络环境对 UDP 的支持并不相同。规则命中只说明相应连接选择了一个策略，并不证明节点能够稳定承载实时媒体。若连接记录中出现大量直连 UDP，先核对客户端的代理模式、节点能力和所在网络是否限制 UDP；不要简单地把所有 UDP 一概封锁，否则可能让应用回退到更慢的连接方式，甚至无法通话。
DNS 也会影响规则判断。启用增强模式或使用订阅规则集时，Mihomo 可能通过域名嗅探、映射或规则集处理连接；如果应用使用缓存 IP、系统 DNS 与 Clash DNS 不一致，连接记录里的域名可能不完整。此时可在不改变其他设置的前提下重新启动应用、检查 DNS 模式和日志，再观察是否能识别实际主机。不要仅为了“看见域名”就随意更换所有 DNS，企业内网和公司 VPN 可能依赖专用解析。
当国内办公网站受影响时，先在连接列表找到慢的站点，确认它命中了哪条规则。对稳定的企业域名，可按组织网络要求使用直连或指定的公司出口；不确定域名归属时，先询问 IT 管理员。过宽的 DOMAIN-SUFFIX 会同时覆盖同一主域下的多个服务，维护成本往往高于几条清晰的精确规则。保留少量、可解释的覆盖项，也能在订阅更新后更快判断是哪条规则改变了行为。
另一个常被忽略的因素是系统代理与 TUN 的差异。浏览器可能遵循系统代理，而桌面会议客户端或其他子进程可能使用自己的网络栈；TUN 能覆盖更多应用流量，却会增加与公司 VPN、虚拟网卡和安全软件发生路由冲突的可能。建议先用规则模式建立基线，只有确认某个应用绕过系统代理、且该设备允许使用 TUN 时再测试。每次切换后都检查连接面板和公司内网访问，发现路由冲突就恢复到已知可用的设置。
不少会议软件内置自动选路，但它们通常不会让你清楚控制哪些协作域名走代理、哪些企业站点保持直连；相反，把全部流量交给一个全局隧道，又可能增加国内办公服务的延迟。用 Clash 的策略组、窄范围域名规则和连接记录逐项验证，可以在会议稳定性与本地办公访问之间取得更可控的平衡。如果你希望按自己的设备和网络环境整理客户端，再前往下载页查看适用版本。