为什么远程办公需要单独做 Zoom 与 Slack 分流？

远程办公时，最让人困扰的通常不是「完全没有网络」，而是会议偶尔卡顿、语音延迟忽高忽低、Slack 消息过几分钟才送达。浏览器打开普通网页很顺利，并不能说明 Zoom、Slack、Google 文档或企业登录服务都拥有同样的连通性。它们使用的域名、连接类型和长连接保持方式不同，如果所有流量都交给一个过于宽泛的规则，国内网站可能被迫绕行，海外办公服务又可能误走直连，最终形成「网页能开、会议不稳、消息延迟」的半通状态。

本文面向使用 Clash Verge、Clash Verge Rev、Mihomo Party、Clash for Android 等客户端的远程办公用户，重点讨论一套可迁移的配置思路：国内站点继续直连，Zoom 与 Slack 使用独立策略组，DNS 解析与代理出口保持一致，并通过连接日志确认实际命中的规则。文中的示例不会绑定某一家节点服务商，也不建议把所有海外流量简单设置为全局代理；真正稳定的关键，是缩小需要代理的范围、固定实时业务的出口、为办公软件保留足够的故障排查空间。

Zoom 和 Slack 也并非只有一个固定域名。Zoom 客户端可能访问会议、登录、更新、遥测和内容分发相关地址，Slack 则可能同时使用工作区域名、API、文件预览、头像和实时消息通道。不同版本的客户端、企业网络策略和所在地区都会改变连接目标，因此下文给出的域名只是起点。最终仍应以 Clash 的连接列表、请求主机名和规则命中结果为准，逐步补充而不是盲目复制一张永远不变的清单。

先拆流量：Zoom、Slack 与国内网站分别怎么走

远程办公配置的第一步不是马上填写规则，而是先把业务拆成几类。Zoom 音视频对延迟、抖动和丢包更敏感，会议建立后还需要持续维持连接；Slack 文本消息单次数据量很小，但依赖实时连接和通知服务，规则错误时常见表现是消息延迟、频道内容刷新失败或文件预览打不开；国内网站与公司内网通常更适合直连，绕行代理不仅增加延迟，还可能触发验证码、登录异常或访问来源变化。

常见的规则写法可以从域名后缀开始，例如将 zoom.us、zoom.com 相关请求交给 Zoom 策略组，将 slack.com 以及你所在企业的 Slack 工作区域名交给 Slack 策略组。部分资源可能来自独立 CDN 或第三方服务，不能因为页面地址显示为 Slack 就假设所有请求都属于同一个后缀。首次使用时打开连接日志，先启动 Slack、刷新频道、发送一条测试消息，再查看实际请求的主机名；Zoom 则应分别测试登录、加入会议和会议内语音。

规则顺序同样重要。更具体的办公域名必须放在宽泛的兜底规则之前，否则可能先被「国内直连」「常见域名直连」或某个过宽的 GEOIP 规则截走。对于公司自有域名，建议优先使用明确的 DOMAIN-SUFFIX 或 DOMAIN 规则；对于本地开发服务、打印机、路由器和私有网段，则保留 DIRECT，避免 TUN 或全局代理把办公设备之间的访问带到远端节点。

动手配置：四步完成远程办公分流

下面以支持 Mihomo 内核的客户端为例。不同客户端的按钮名称可能是「配置」「Profiles」「覆写」「规则」或「设置」，但配置逻辑基本一致。开始前请备份当前配置文件，并准备好一条可正常使用的订阅；不要在文章、截图或工单中公开完整订阅链接，因为其中通常包含可以直接识别账户的访问令牌。

1. 确认客户端和内核：打开 Clash Verge Rev、Mihomo Party 或其他客户端的设置页，确认当前使用的是 Mihomo 或兼容 Clash Meta 语法的内核。若仍使用较旧的 Clash Premium 配置，先确认它是否支持你的规则集、DNS 写法和策略组类型，不要直接把新语法整段粘贴进去。
2. 导入并启用配置：在配置页添加订阅链接，等待 YAML 下载和解析完成，然后明确点击「设为活动配置」或类似按钮。只下载订阅但没有切换到活动配置，是许多用户以为规则无效的原因。启用后先打开规则模式，不要一开始就切换全局模式。
3. 建立办公策略组：在配置或覆写中准备 ZOOM 与 SLACK 两个策略组。Zoom 建议使用手动选择或固定节点，Slack 可使用手动选择或低频健康检查的 url-test 组；会议进行期间不要让策略组频繁自动切换节点。
4. 添加具体规则：把已确认的 Zoom、Slack 域名分别指向对应策略组，将公司内网域名、本地网段和国内常用服务指向直连，最后保留原配置的兜底规则。保存后重新加载配置，并在连接列表里观察新请求是否命中预期策略。
5. 逐项验证业务：先登录 Slack 并发送测试消息，再打开文件预览和频道搜索；随后启动 Zoom，测试登录、加入会议、摄像头、麦克风和屏幕共享。每完成一项就记录连接日志，不要同时修改 DNS、TUN、规则和节点，否则出现问题时无法判断是哪一层造成的。

如果客户端支持覆写，推荐把自定义内容单独保存，而不是直接改动远程订阅原文。这样订阅更新后，节点列表和远端规则可以继续刷新，本地的办公策略组也不会被覆盖。覆写的优先级应当清晰：先定义策略组，再插入规则，最后检查原配置是否已经存在同名组。若出现重复名称，可能导致客户端加载失败，或者你修改的组并不是当前规则真正引用的组。

规则示例与策略组设计

以下片段只展示思路，实际规则名称、节点名称和完整配置结构应以你的客户端版本为准。使用前请检查 YAML 缩进，尤其是 rules、proxy-groups 与列表项之间的空格关系。

proxy-groups:
  - name: ZOOM
    type: select
    proxies:
      - "办公稳定"
      - DIRECT

  - name: SLACK
    type: select
    proxies:
      - "办公稳定"
      - "自动选择"

rules:
  - DOMAIN-SUFFIX,zoom.us,ZOOM
  - DOMAIN-SUFFIX,zoom.com,ZOOM
  - DOMAIN-SUFFIX,slack.com,SLACK
  - DOMAIN-SUFFIX,slack-edge.com,SLACK
  - DOMAIN-SUFFIX,slack-msgs.com,SLACK
  - DOMAIN-SUFFIX,公司内网域名,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

示例中的 slack-edge.com 和 slack-msgs.com 不能被视为所有环境都必需的固定答案。若连接日志没有出现这些域名，不必为了「规则看起来完整」而强行加入；如果你的工作区使用独立域名或文件服务，也应根据实际日志添加更具体的规则。规则测试时可以临时把未知请求交给一个单独的「办公观察」策略组，确认业务正常后再合并到正式策略组。

DNS、系统代理与 TUN：稳定性问题通常出在哪里

DNS 配置会直接影响分流结果。若域名解析在本地完成，而连接随后通过代理出口访问，可能出现解析结果与出口地区不匹配；若所有 DNS 请求都被粗暴送到远端，又可能让国内网站打开变慢。较稳妥的做法是使用客户端支持的分流 DNS：国内域名使用可信的本地或国内解析路径，代理域名使用远端 DNS 或 DoH，并确保 DNS 查询不会在系统代理与 Clash 内核之间来回绕路。

使用 fake-ip 时，要特别留意企业内网、局域网设备和需要真实 IP 的服务。可以将公司内网后缀、路由器地址、打印机网段和本机回环地址加入 fake-ip-filter 或直连例外。若 Slack 的通知看似正常，但点击文件预览后一直转圈，先查看连接列表中的实际域名和 DNS 命中情况；不要因为「消息能收到」就认为所有 Slack 资源都已经正确分流。

系统代理适合浏览器、办公套件和遵循系统设置的桌面程序。它配置简单，出问题时也容易关闭，是第一次搭建远程办公规则时的推荐起点。但部分 Zoom 辅助进程、命令行工具、后台更新服务或企业安全软件可能不会读取系统代理。此时再考虑 TUN，让 Mihomo 在网络层接管更多 TCP/UDP 流量，同时检查虚拟网卡权限、自动路由、DNS 劫持和网络适配器优先级。

TUN 并不是「开启后一定更快」。它解决的是应用不遵循系统代理的问题，却也会扩大配置影响范围。开启后如果国内网站变慢、公司 VPN 无法连接、局域网设备消失，先关闭 TUN 回到系统代理模式，确认基础规则没有问题，再逐项开启 auto-route、auto-detect-interface 等选项。Windows 用户还要注意 VPN、WSL、虚拟机网卡与 TUN 的路由冲突；Android 用户则需确认系统 VPN 权限、私人 DNS 和其他 VPN 应用没有同时接管流量。

会议卡顿与 Slack 延迟的排障顺序

当 Zoom 会议卡顿时，先区分是连接建立失败还是会议中途质量下降。前者通常与登录域名、规则命中、DNS 或节点不可用有关；后者更常见于节点拥塞、出口抖动、UDP 质量差、自动切换或本地 Wi-Fi 不稳定。打开 Clash 连接日志，观察会议开始后是否持续出现新的代理连接、反复关闭和重建，若每隔几十秒就更换目标或节点，应先固定策略组，而不是继续添加域名。

如果 Zoom 能登录但无法加入会议，可以把登录、会议建立和会议内媒体流分开测试。登录成功只说明认证链路可用，不能证明音视频服务器、区域调度地址和 UDP 都正常。必要时在客户端设置中临时测试 TCP 传输，若 TCP 稳定而 UDP 明显丢包，问题更可能在节点或网络路径，而不是规则文本。会议结束后再恢复适合你网络的传输方式，避免在正式会议中反复切换。

Slack 消息延迟则要检查客户端是否保持实时连接。先确认工作区网页能否刷新，再查看连接日志中是否有持续连接的目标主机；如果每次切换频道都重新连接，可能是网络重置、代理节点不稳定或 WebSocket 被中间设备关闭。若文字消息正常、文件和图片异常，应继续观察 CDN、对象存储或预览服务的域名，把确实属于工作区资源的目标加入 Slack 策略组，但不要把所有陌生 CDN 后缀一律代理。

最后建议为远程办公保留一份「能用的基线配置」。当你准备升级客户端、替换内核或新增规则时，先复制配置文件，再一次只改一个变量，并记录修改日期、节点、测试结果和异常现象。这样即使新规则导致 Zoom 或 Slack 出现问题，也能迅速回滚，而不是在会议开始前临时删除整份配置。对于团队环境，还可以把办公规则、国内直连规则和个人节点选择分开维护，减少订阅刷新对日常工作的影响。

相比一些只提供全局开关、规则编辑入口隐蔽，或文档停留在旧版 Clash for Windows 的同类工具，远程办公场景更需要清晰的策略组、可查看的连接日志、可回滚的配置方式以及对 Mihomo 规则的持续兼容。Clash 官网 的优势正在于把 Zoom、Slack、系统代理、TUN 和 DNS 这些容易混淆的环节拆开说明，方便你按实际连接逐项验证，而不是靠反复切换全局模式碰运气。若你希望按照本文思路搭建一套更容易检查和维护的 Clash 工作环境，不妨前往下载，再从规则模式和固定办公节点开始配置。