前言：先明确办公流量的分流目标
远程办公时，网络问题往往不是“能不能打开网页”这么简单：Zoom 或 Google Meet 可能出现语音断续、画面冻结，Slack 则可能长时间显示正在连接，文件和图片也迟迟无法加载。把 Clash 切换到全局模式有时能临时解决访问问题，但所有国内网站和应用也会一起绕行代理，带来额外延迟、登录验证或内部系统访问异常。
更稳妥的做法是使用 Rule（规则）模式，把会议和协作软件的流量明确交给合适的策略组，同时保留国内网站直连。需要注意，Zoom、Slack 和 Google Meet 的域名、连接方式及实际访问路径可能随客户端版本、地区、组织网络和服务端调整而变化。本文提供的是可检查、可逐步验证的配置思路，不是保证覆盖所有流量的固定域名清单。
配置目标
为视频会议准备稳定且延迟较低的连接，为 Slack 等协作工具选择可靠的代理或直连路径，并让国内网站继续使用 DIRECT。出现异常时，可以按应用和规则逐项定位，而不是长期依赖全局代理。
1先准备策略组与规则顺序
规则只负责决定流量交给谁处理，真正的连接路径由策略组决定。因此，在添加域名规则之前，先确认配置中存在可用的代理策略组，并确认它包含当前在线的节点。常见订阅会提供名为“节点选择”“手动选择”或“自动选择”的组；如果规则引用了不存在的组名，Clash 可能无法正常加载配置。
会议与协作分开选择
建议将实时会议与消息协作分成两个策略组，避免会议期间更换节点时影响 Slack 的长连接。下面的名称仅为示例，必须与自己配置中的实际策略组名称一致。若订阅已有对应组，可以直接复用，不必重复创建。
- Work-Meeting：用于 Zoom 和 Google Meet。优先考虑延迟稳定、丢包较少、带宽足够的节点；测试通过后，会议期间尽量固定选择，不要频繁切换。
- Work-Collab：用于 Slack 及其消息、文件相关连接。重点看长时间连接是否稳定、文件上传下载是否连续，而不只是测速页面上的瞬时速度。
- DIRECT：国内网站、公司内网和明确要求本地出口的服务继续直连。如果公司使用专用域名或 VPN，应遵循组织的网络与安全要求。
选择节点的实用方法
先在客户端的延迟测试中排除不可用节点，再分别进行一次短时会议和文件传输测试。低延迟不一定代表低抖动或高带宽；如果自动测速组切换过于频繁，可改用手动策略组，并在会议前选定经过验证的节点。
把应用规则放在兜底规则之前
Clash 按规则从上到下匹配，通常先匹配到的规则就会决定流量去向。因此，具体的办公域名规则应放在较宽泛的规则和最终兜底规则之前。例如，如果配置里存在把大部分国外流量交给其他策略组的规则，应将办公规则置于它之前；末尾的 MATCH 或类似兜底规则应保留在最后。修改前最好备份配置，避免缩进或策略组名称错误造成配置加载失败。
2配置 Zoom、Slack 与 Google Meet 分流
以下示例使用常见域名后缀和关键字规则，便于先建立基本分流。请将 Work-Meeting 与 Work-Collab 替换为你自己的策略组名称，并把办公规则放在相关兜底规则之前。订阅配置的格式和覆写能力因客户端与内核而异：有的客户端支持在配置覆写或 Merge 中添加规则，有的需要编辑配置副本；不要直接覆盖订阅后无法恢复的原始文件。
这是起点而非完整的服务端清单。Google Meet 可能还会访问 Google 的身份验证、静态资源或媒体相关域名；Slack 也可能按功能调用其他资源域名。不要为了“一次性覆盖”而把整个 google.com 或所有 Google 域名强制放入会议策略组，否则 Gmail、云端硬盘和其他 Google 服务也可能被一起改变路径。优先通过客户端的连接记录或连接详情确认实际访问的域名，再添加确有需要的规则。
留意 Zoom 的 UDP 与媒体流量
Zoom 会议不仅有网页和登录请求，也会建立音视频媒体连接。系统代理模式主要接管遵循系统代理设置的流量，部分应用的 UDP、点对点媒体或其他非代理连接可能不会按域名规则转发。若 Zoom 已经可以登录但会议音视频仍卡顿，可检查客户端连接记录是否出现直连流量，并确认当前内核和客户端是否支持所需的透明接管方式。
不要随意加入过期 IP 规则
会议服务的 IP 地址可能变化，并可能由云服务商动态分配。未经验证地复制固定 IP-CIDR 清单，可能造成误分流或规则失效。优先使用可观察、可维护的域名规则；确需按 IP 分流时，应以服务商或组织网络管理员提供的最新信息为准。
3在客户端应用配置并逐项验证
Clash Verge、Clash Verge Rev 和其他 Mihomo 客户端的菜单名称可能不同，但基本流程相似：先导入并启用订阅，确认核心运行正常，再选择规则模式、启用配置覆写，最后检查规则与连接记录。不要同时在多个配置文件中维护相同规则，否则后续更新时容易出现重复项或规则顺序难以判断。
- 备份当前配置：保存一份原始订阅或记录当前配置，确保出现问题时可以恢复。
- 确认策略组：在客户端的代理或策略组页面，确认会议组、协作组及其可选节点均可使用。策略组不存在时，先调整名称或创建组，再添加规则。
- 添加办公规则：将示例规则放入客户端支持的覆写、Merge 或配置编辑入口。检查 YAML 缩进、逗号和策略组名称，随后保存并重新加载配置。
- 启用规则模式：将运行模式设为 Rule。全局模式适合短时排查，不适合作为保留国内直连的常态配置。
- 检查连接记录：分别启动 Zoom、Slack 和 Google Meet，在连接详情中查看域名命中了哪条规则、使用哪个策略组，以及连接是 TCP 还是 UDP。
- 验证国内直连：访问常用国内网站和公司内部服务，确认它们没有被办公规则误匹配，并按照组织要求保留必要的内网直连或专用 VPN 路径。
根据现象定位问题
- 会议能连接但声音断续：先检查丢包、节点负载和上行带宽，再确认媒体流量是否绕过了系统代理。可以对比一次稳定节点与本地直连的表现；不要只凭延迟数字判断结果。
- Google Meet 页面打开但无法加入会议：查看连接记录中是否有相关域名走了错误策略。若确有资源域名未命中，可先添加精确域名规则并重新测试，避免直接扩大到所有 Google 流量。
- Slack 一直显示正在连接：确认 Slack 域名命中了预期策略组，测试该组节点的长连接稳定性，并检查系统时间、DNS 解析及公司防火墙策略。企业网络限制应联系管理员处理。
- 国内网站也变慢：检查规则顺序和末尾兜底规则，确认办公规则没有写成过宽的域名关键字。逐条禁用新加规则进行对比，有助于迅速找到误匹配项。
- 修改后配置无法加载：恢复备份，再逐段加入规则。特别检查缩进、列表符号以及策略组名称是否与配置中的名称完全一致；客户端日志通常会指出解析错误位置。
排查时建议一次只改一类设置，并记录修改前后的表现。例如先验证节点，再验证域名规则，最后才调整 DNS 或 TUN。这样可以区分是节点质量、规则匹配、DNS 解析还是系统接管方式导致的问题。会议过程中尽量不要同时切换节点、重载配置和变更系统网络模式，以免把短暂断线误判为规则配置失败。
会议前的快速检查
提前几分钟打开 Clash，确认 Rule 模式、节点可用、会议组选择正确，并进行一次音视频测试。对于公司设备或受管理网络，优先遵循 IT 部门提供的代理、DNS、VPN 和数据保护要求，不要为了绕过策略而擅自扩大接管范围。
4建立稳定、可维护的办公配置
远程办公的 Clash 配置不应追求规则数量越多越好，而应做到路径明确、容易检查、出错后能恢复。Zoom 和 Google Meet 适合归入专门的会议策略组，重点观察媒体连接的稳定性；Slack 则可使用独立协作组，避免会议切换节点时影响消息长连接。国内网站继续由原有直连规则处理，避免使用全局模式长期接管所有流量。
在实际使用中，建议定期检查订阅更新后策略组是否改名、客户端是否仍加载覆写配置，以及新添加的域名规则是否仍然命中。若组织调整了会议平台、安全网关或内部网络要求，应以管理员提供的信息为准。只有通过连接记录和真实会议测试验证过的规则，才适合保留在日常配置中。
如果你还没有适合自己设备的 Clash 客户端，可以先查看下载页面，选择与操作系统和设备架构相匹配的版本。