Clash远程办公怎么配？Zoom、Slack与Meet分流优化指南

先确定远程办公的分流目标

远程办公场景中的流量并不是“全部代理”或“全部直连”这么简单。视频会议需要稳定的长连接、较低的抖动和可靠的 UDP 支持；Slack 等团队沟通工具通常同时使用网页、桌面客户端、WebSocket 与文件上传；Google Meet 则涉及多个 Google 域名、媒体服务器和浏览器权限。把所有流量交给同一个节点，可能让会议变得不稳定，也可能让国内服务访问变慢。

比较稳妥的思路是使用 mode: rule，先为 Zoom、Slack、Google Meet 建立独立规则，再将这些规则指向远程办公策略组。国内常用的企业邮箱、网盘、代码仓库镜像或内部系统，则根据实际网络位置选择 DIRECT。这样既能让国际办公服务通过合适节点访问，也不会让所有国内流量绕行。

为 Zoom、Slack 与 Meet 设计规则

规则匹配通常按照 rules 从上到下执行，第一条命中的规则会决定流量去向。因此，办公服务规则应放在通用的广告拦截、地区规则或最终兜底规则之前。若先命中一个宽泛的 GEOIP,CN,DIRECT，部分使用境外域名但解析结果变化较大的服务可能提前被送往直连。

Zoom：不要只添加一个主域名

Zoom 的登录页面、会议控制、聊天、更新和媒体连接不一定全部使用同一个域名。可以先加入常见的基础域名，再通过 FlClash 的连接记录观察实际请求。如果企业使用自定义区域或特定数据中心，最终应以运行日志和服务方文档为准，而不是无限增加猜测域名。

rules:
  - DOMAIN-SUFFIX,zoom.us,Remote-Work
  - DOMAIN-SUFFIX,zoom.com,Remote-Work

Zoom 会议中的音视频可能使用 UDP。仅依赖浏览器的 HTTP 代理设置时，页面能够打开并不代表媒体链路一定使用同一条路径。若客户端支持 TUN，可以在确认系统权限、虚拟网卡和 DNS 接管均正常后再启用；如果会议经常出现“能看到画面但没有声音”，应同时检查节点是否允许 UDP、网络是否限制 UDP，以及客户端是否被防火墙拦截。

Slack：同时覆盖工作区与附件访问

Slack 工作区常见域名包括 slack.com 和用户所属的工作区域名。图片、文件、缩略图和部分实时连接可能来自独立的内容分发域名。建议先按主域名配置，再打开连接日志访问一次工作区、发送一条消息、下载一个附件，确认是否有请求被错误地分配到直连。

rules:
  - DOMAIN-SUFFIX,slack.com,Remote-Work
  - DOMAIN-SUFFIX,slack-edge.com,Remote-Work

如果只给 Slack 网页配置代理，而桌面客户端仍然无法收发消息，可能是桌面应用没有读取系统代理，也可能是它使用了不同的网络组件。此时可以在日志中搜索工作区域名、WebSocket 请求和附件域名。不要为了修复一个文件下载问题，直接把所有 HTTPS 流量切换到代理。

Google Meet：信令与媒体流要分别验证

Google Meet 通常依赖 meet.google.com，但登录、日历邀请、身份验证和媒体服务还可能访问其他 Google 域名。基础配置可以先覆盖 Meet 主域名和常见的 Google 服务域名，再根据连接记录补充。规则过宽会让搜索、地图或其他并不需要代理的 Google 服务一起绕行，因此不建议未经测试就使用整个 Google 域名集合。

rules:
  - DOMAIN-SUFFIX,meet.google.com,Remote-Work
  - DOMAIN-SUFFIX,accounts.google.com,Remote-Work
  - DOMAIN-SUFFIX,googleusercontent.com,Remote-Work

Google Meet 的视频质量更容易受到抖动、丢包和上行带宽影响。节点测速显示的延迟只是控制连接的参考值，不能代表会议媒体流的实际表现。应在真实会议中观察画质是否频繁降级、语音是否断续、共享屏幕是否延迟，并优先选择具备稳定 UDP 或良好 TCP 回退能力的节点。

国内服务与办公内网使用直连

如果公司门户、OA、企业邮箱或文件系统位于国内网络，通常应优先直连。企业内网域名、私有 IP 和局域网地址也不应交给公共代理节点。常见的内网规则可以放在国际办公规则之后、通用地区规则之前，并根据公司域名替换示例中的占位内容。

rules:
  - DOMAIN-SUFFIX,corp.example.cn,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

no-resolve 可以避免在匹配 IP-CIDR 规则时额外触发 DNS 解析，但它不等于允许所有私有地址安全访问。企业网络若使用更具体的网段，应向管理员确认范围；不要为了“修复内网访问”而随意关闭 DNS 防护或扩大 allow-lan。

动手配置远程办公策略组

下面是一套适合桌面端 FlClash 或其他 mihomo 客户端的基础结构。示例中的节点名称只是占位符，不能直接当作真实节点使用。若订阅已经提供了“节点选择”或“自动选择”策略组，可以直接引用现有组，避免重复维护节点列表。

proxy-groups:
  - name: Remote-Work
    type: url-test
    proxies:
      - Office-SG
      - Office-JP
      - Office-US
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: Office-Manual
    type: select
    proxies:
      - Remote-Work
      - Office-SG
      - Office-JP
      - DIRECT

rules:
  - DOMAIN-SUFFIX,zoom.us,Remote-Work
  - DOMAIN-SUFFIX,zoom.com,Remote-Work
  - DOMAIN-SUFFIX,slack.com,Remote-Work
  - DOMAIN-SUFFIX,slack-edge.com,Remote-Work
  - DOMAIN-SUFFIX,meet.google.com,Remote-Work
  - DOMAIN-SUFFIX,accounts.google.com,Remote-Work
  - DOMAIN-SUFFIX,corp.example.cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Office-Manual

1. 在客户端中导入或备份当前配置，确认订阅更新后不会覆盖本地覆写内容。
2. 打开配置编辑、覆写或 Mixin 功能，把远程办公策略组和规则放入对应位置。
3. 将示例节点替换为订阅中真实存在的节点，或改成订阅已经提供的策略组名称。
4. 检查 YAML 缩进。字段层级使用空格，不要混用 Tab；策略组名称在规则中必须逐字一致。
5. 保存后重新载入配置，确认核心日志没有出现解析错误、未知代理组或未知节点提示。
6. 开启系统代理，依次访问 Zoom、Slack 和 Meet，再从连接记录确认请求命中了 Remote-Work。
7. 访问一个国内办公系统和局域网地址，确认它们命中 DIRECT，而不是被远程节点接管。

url-test 会按照设定的测试地址和间隔选择延迟较低的节点，但它测试的是指定 URL 的连接结果，不是 Zoom、Slack 或 Meet 的完整体验。对于重要会议，可以把策略组临时改成 select，提前在真实网络环境中手动比较两个或三个节点，再固定到表现稳定的节点。

节点筛选与会议稳定性验证

远程办公节点不应只按测速延迟排序。视频会议更关心持续稳定性、上行质量、丢包和 UDP 表现；Slack 文件协作则更容易暴露下载速度、连接重置和长时间保持连接的问题。建议在工作时间之外进行至少一次完整测试，再把结果用于正式会议。

如果会议页面可以打开，但加入会议失败，先检查浏览器权限、系统防火墙和节点 UDP 能力；如果只有共享屏幕失败，则要区分浏览器权限问题与网络问题。如果 Slack 消息延迟而文件下载正常，重点查看 WebSocket 连接是否被规则、代理链或网络中间设备重置。若所有应用同时变慢，则应先测试节点本身，而不是继续增加域名规则。

DNS 也会影响分流结果。使用 fake-ip、redir-host 或系统 DNS 时，域名解析路径可能不同。开启 TUN 后，如果出现国内网站被误判为代理、公司内网域名无法解析，先检查 dns.nameserver-policy、局域网 DNS 和绕过设置。不要在没有备份的情况下同时修改 DNS、TUN 和规则，否则很难确定故障来源。

最终可以保留两套策略：会议前使用手动选择的稳定节点，日常办公使用 url-test 自动选择。会议结束后再切回自动策略，避免节点在通话过程中因测速结果变化而切换。规则配置完成后，定期查看连接日志，删除已经失效或从未命中的域名规则，保持配置简洁。