前言：让会议流量走对线路
远程办公时，Zoom、Google Meet 和 Slack 往往需要同时在线。会议画面偶尔卡顿、语音延迟，或者 Slack 长时间显示“正在连接”，不一定是客户端本身出了问题：代理节点的拥塞、规则顺序不合理、UDP 流量没有被正确接管，都可能影响实际体验。反过来，如果为了修复会议问题直接开启全局代理，国内网站、网银或本地办公系统也可能被不必要地转发，造成访问变慢或登录异常。
Clash 的优势在于可以根据域名和策略组分别处理流量。本文以 Mihomo 内核常见的配置语法为例，说明如何为 Zoom、Google Meet 和 Slack 规划分流规则、选择会议线路，并通过客户端的连接记录验证结果。不同客户端的菜单名称可能略有差异；如果订阅配置会自动更新，建议使用客户端支持的覆写或合并功能，而不是直接修改后又被订阅覆盖。
配置目标
让会议和协作应用按需进入稳定策略组，国内流量继续直连；遇到音视频问题时，能够区分域名规则、节点质量与 UDP 接管问题，避免盲目切换全局模式。
1先规划策略组与节点
会议线路不应只看客户端显示的单次延迟。延迟测试通常只反映到测速地址的往返时间，不等同于 Zoom 或 Meet 的实际媒体质量。视频会议更在意持续带宽、丢包、抖动和线路稳定性；一个延迟略高但不频繁波动的节点，实际体验可能优于测速数字漂亮却容易拥塞的节点。
建议至少准备两个用途清晰的策略组：一个用于会议和海外协作服务，一个保留常规代理用途。会议组优先选择稳定、支持 UDP 转发的节点；如果团队或服务要求固定出口地区，可手动选择符合要求的节点，避免自动策略频繁更换出口。若没有必须代理的要求，也可以先测试直连，再决定是否将会议流量交给代理。
下面是简化示例。请将 节点 A、节点 B 替换成订阅中真实存在的节点名称；如果现有配置已经有相同名称的策略组，不要重复创建。
先测实际会议线路
在会议前用同一台设备、同一网络进行短时测试，分别记录直连和候选节点下的语音连续性、画面清晰度与丢包提示。不要在重要会议中途频繁更换节点；切换出口可能导致现有会议连接重新建立。
2为 Zoom、Google Meet 与 Slack 设置分流
规则应放在较宽泛的规则集和最终兜底规则之前，否则前面的 GEOIP、规则集或 MATCH 可能先匹配，后续添加的应用规则便不会生效。将下面的示例放入配置的 rules 中，并按自己的连接策略把 Work-Meeting 改为 DIRECT 或其他已存在的策略组名称。规则组名称必须与配置中的策略组完全一致。
如果你决定让 Zoom 或 Meet 直连，可将对应规则的策略目标改为 DIRECT，而不是另建一套重复的域名规则。反之，如果公司网络、所在地区或服务环境要求使用代理，则将它们指向会议策略组。规则的适用效果取决于实际访问的域名、订阅规则和客户端接管方式，因此上面的列表是起点，不是对所有部署环境都完整的域名清单。
控制匹配范围与规则顺序
不要为了“保险”简单加入 DOMAIN-SUFFIX,google.com：这会把大量并非会议所需的 Google 服务一并交给同一策略，可能影响其他应用。也不建议使用过宽的 DOMAIN-KEYWORD,zoom，因为关键词匹配可能命中不相关域名。遇到规则没有覆盖的连接时，先在客户端的连接或日志页面查看目标域名和当前命中的规则，再按实际记录补充精确规则。
Zoom 与 Google Meet 的音视频媒体流可能使用动态地址和 UDP，单靠域名规则不能保证每一种媒体连接都按预期工作。启用系统代理的客户端通常主要处理遵循系统代理设置的连接；若应用的媒体流绕过系统代理，可以在确认需求后测试 TUN 模式，并检查所用节点和内核是否支持 UDP。不要把网上流传的固定 IP 列表当作永久规则：服务地址可能变化，过时的 IP-CIDR 规则会让流量走错路径。
注意规则覆盖
请确认应用规则位于宽泛规则和 MATCH 之前。修改配置前保留原文件或建立备份；若客户端提示配置校验失败，先恢复备份，再检查缩进、逗号、策略组名称和节点名称。
3验证连接并排查会议问题
保存配置并重新加载后，先确认 Clash 当前处于规则模式，而不是全局模式或直连模式。随后分别打开 Zoom、Google Meet 和 Slack，检查客户端的连接记录：目标域名是否出现、连接命中了哪条规则、最终使用了哪个策略组。不同客户端的日志页面名称不完全相同，但通常可以在“连接”“日志”或“网络”相关页面查看。若流量没有出现在记录中，优先检查系统代理是否启用，或评估是否需要 TUN 接管。
| 现象 | 优先检查 | 处理建议 |
|---|---|---|
| 会议能加入，但声音断续或画面冻结 | 节点拥塞、线路丢包、UDP 转发 | 先对比直连与其他稳定节点；确认客户端接管方式和节点支持 UDP。 |
| 浏览器中的 Meet 正常，桌面应用异常 | 应用是否遵循系统代理、进程流量是否被接管 | 查看连接记录；必要时测试 TUN，并在测试后确认国内应用仍按预期直连。 |
| Slack 一直显示连接中或文件加载失败 | 是否命中协作策略、WebSocket 连接是否稳定 | 检查 Slack 相关域名的命中结果，尝试固定到稳定节点并保持出口不变。 |
| 国内网站也变慢或无法访问 | 是否误开全局模式、规则顺序是否被覆盖 | 切回规则模式，检查国内规则和兜底规则，并确认会议规则没有扩大到整个域名族。 |
会议期间如何切换策略
开始会议前先选定一个候选节点，并等待连接记录稳定下来。若确实需要切换，可在策略组中改选节点，然后观察会议是否自动恢复；部分会议连接不会无缝迁移，可能需要退出后重新加入。尽量避免使用会在会议期间自动轮换出口的负载均衡策略，因为出口频繁变化会增加连接重建的概率。会议结束后，再比较日志、丢包提示和实际听感，决定是否保留该节点。
如果问题只发生在某一家公司网络，先确认其防火墙、VPN、终端安全软件或网络策略是否限制代理和 UDP；不要未经许可绕过单位的安全规定。多人协作时，也可以记录使用的策略名称、节点地区、测试时间和故障表现，方便管理员区分本地网络问题与代理线路问题。
推荐排查顺序
先确认规则模式与规则命中，再检查当前策略和节点质量，最后排查 UDP、TUN 与本地网络限制。每次只改一个设置并复测，才能知道真正起作用的是哪一步。
完成配置后，不需要把所有办公流量都强制导向同一条线路。保留精确的应用规则、让国内服务按原有规则直连，并在会议前确认策略组和节点状态，通常比临时开启全局代理更容易维护。需要安装或更换客户端时，可以前往下载。