远程办公分流的基本思路

Zoom、Slack 和 Google Meet 的连接目标不止一个域名：登录、消息、网页界面、文件与会议媒体可能分别连接不同服务。规则模式下，Clash 根据连接信息匹配 rules，再把流量交给规则指定的策略组；如果某条连接没有命中办公规则，就会继续向下匹配。因此，配置目标不是把所有相关流量一律代理，而是让需要代理的服务使用稳定出口，同时让国内网站和不需要代理的应用保持直连。

先确认实际运行的内核。下文使用的规则格式以 mihomo 为参考；传统 Clash 内核以及不同版本客户端对规则类型、TUN 和覆写的支持可能不同。Clash Verge、Clash Verge Rev 等客户端的界面名称也会变化。修改前在客户端的内核信息或启动日志中记录内核名称与版本，并确认编辑的是当前生效配置，而非订阅原文或临时生成文件。

另外，域名规则和 DNS 解析彼此相关，但不是一回事。若应用通过系统 DNS、浏览器安全 DNS 或其他解析路径取得 IP，内核看到的连接信息可能不完整。排查时应同时查看连接记录、规则命中结果与 DNS 配置，而不是只凭“网页能打开”推断所有会议流量都经过了代理。

服务域名与策略组规划

为办公应用单独准备一个明确的策略组，例如配置中已经存在的 Work 或 办公代理。规则目标必须与 proxy-groups 中的名称完全一致，包括大小写和空格；如果配置里没有这个组名，内核可能报规则目标无效，或者加载结果与预期不同。组内可手动选择稳定节点，也可使用已有的自动选择组。会议期间优先考虑持续稳定和丢包表现，不要仅按一次延迟测试结果决定。

服务可先验证的域名线索配置时的边界
Zoomzoom.us、zoom.com登录、网页和会议媒体可能使用不同连接；只加域名规则不能保证所有媒体流量都已覆盖。
Slackslack.com、slack-edge.com工作区、消息、文件和通话可能经过不同主机；不要把未确认的通用 CDN 域名整体交给代理。
Google Meetmeet.google.com会议页面域名不代表 Google 全部服务。避免为了 Meet 把所有 Google 域名都送往代理。

这些域名只是建立测试规则的起点，不是服务商完整、永久不变的地址清单。服务可能调整域名、使用 CDN 或通过共享基础设施传输媒体。出现漏分流时，先在 Clash 的连接记录中找到对应应用和目标域名，再决定是否补充具体规则；不应从网上复制宽泛域名列表后不加验证地套用。

国内网站的直连策略也应放在适当位置。若现有配置已通过规则集处理国内域名和 IP，尽量沿用已有逻辑，不要重复创建一组互相冲突的规则。规则按顺序匹配，前面命中的规则会先决定去向；办公规则、国内直连规则和兜底规则之间的先后关系，需要结合现有配置结构安排。

动手配置：添加规则并逐项验证

下面用 Work 作为策略组名称示例。应用前先确认你的配置中确实存在该组；如果名称不同，请替换为真实名称。规则应合并到现有 rules 列表，并放在可能提前匹配这些域名的宽泛规则之前、兜底规则之前。不要重复建立第二个顶层 rules:，也不要删除原有订阅规则。

rules:
  - DOMAIN-SUFFIX,zoom.us,Work
  - DOMAIN-SUFFIX,zoom.com,Work
  - DOMAIN-SUFFIX,slack.com,Work
  - DOMAIN-SUFFIX,slack-edge.com,Work
  - DOMAIN,meet.google.com,Work
  # 保留现有的国内直连规则与其他规则
  - MATCH,PROXY

这只是规则片段，不是完整配置。PROXY 也必须是现有策略组的实际名称；如果原配置的兜底策略不同，应保留原值。DOMAIN 只匹配指定域名，DOMAIN-SUFFIX 匹配域名本身及其子域名。示例没有把 google.com 整体交给代理，以免顺带改变 Gmail、搜索和其他 Google 服务的访问路径。

  1. 备份当前配置。使用客户端提供的覆写、合并或配置编辑功能；如果订阅更新会覆盖手动修改，不要只改订阅下载后的临时文件。保留原始文件，以便规则报错时恢复。
  2. 确认策略组与规则位置。检查 proxy-groups 中是否存在 Work，并确认办公域名规则排在宽泛匹配规则和 MATCH 之前。策略组本身可先手动选一个已验证可用的节点。
  3. 验证配置并重新加载。查看客户端的配置检查结果和内核日志。若提示 YAML 解析错误，优先检查缩进、逗号、重复键以及是否把片段放进了错误层级；规则缩进通常应与现有列表保持一致。
  4. 测试单项服务。打开 Slack 工作区、加入 Zoom 测试会议，再单独加入 Google Meet。每次只测试一种服务，并在连接记录中检查目标域名、命中规则、策略组和最终节点。
  5. 检查直连网站与会议表现。打开常用国内网站，确认仍命中预期的直连规则；会议中观察音频、画面、共享屏幕和重连情况。记录测试时间、网络类型和节点，以便对比修改前后的结果。

若浏览器中的服务页面命中了 Work，但通话仍断续，不能据此认定分流完全正确。部分会议媒体会使用 UDP，某些系统代理模式不一定能接管这类连接；在支持且确有需要时，可测试 TUN 模式，并核对系统权限、路由和内核日志。会议服务常使用多个端口和动态地址，不建议未经抓取连接记录就添加覆盖范围很大的端口规则。

会议卡顿与协作异常的排查顺序

先分辨问题发生在哪一层：是客户端无法登录、消息或文件加载失败，还是已经进入会议但声音和画面不稳定。前两类问题更适合从域名规则、DNS、认证状态和节点可达性查起；会议媒体问题还要检查 UDP 接管、链路丢包、出口拥塞以及组织网络限制。多个故障同时出现时，不要一次修改节点、DNS、规则与 TUN，否则很难判断变化来自哪一项。

现象先检查什么可做的验证
页面能打开，会议加入失败会议相关连接是否命中办公策略；是否有额外 VPN 或企业网络限制在连接记录中查看加入会议时新增的域名和失败状态，再逐项测试。
消息正常，语音或画面断续UDP 流量是否被当前接管方式处理；节点是否持续丢包或拥塞在相同网络和会议条件下对比已验证的节点；如需测试 TUN，一次只改变这一项。
Slack 页面或文件偶发加载失败具体失败请求的目标域名、命中策略与 DNS 结果刷新连接记录，确认是否有相关域名落入兜底规则；只补充实际观察到的目标。
国内网站也变慢是否把共享域名范围设得过宽；国内直连规则是否被办公规则提前匹配检查具体连接命中的第一条规则，调整顺序或缩小匹配范围后复测。

自动选择组的探测结果不等于会议质量保证。节点探测通常只反映对指定测试地址的一次连接情况，不能替代真实会议中的持续丢包、抖动和吞吐表现。要比较出口，固定网络、会议应用和测试时段，每轮只换一个节点；确认稳定后再决定是否设为办公策略组的默认选择。

最后，把可复现的信息记录下来：客户端与内核版本、规则模式或 TUN 状态、网络类型、策略组和节点、故障时间、连接记录中的目标域名与错误信息。分享日志或截图前，遮盖订阅令牌、账户标识、会议链接和其他凭据。这样既便于定位真正漏掉的连接，也能避免为了修复一个域名而把整个办公流量或国内网站不必要地送入代理。