远程办公时，Zoom 视频会议卡顿、Slack 消息延迟和 Google Meet 音视频不同步，不一定是节点速度不够，也可能是 Clash 把办公工具、国内业务和视频流量全部交给了同一个策略组。常见表现是：浏览器打开网页很快，但会议连接反复重连；Slack 文字消息几秒后才送达；Meet 能进入房间，却在开启摄像头后持续降低画质。更合理的做法是按应用实际访问的域名进行精确分流，让 Zoom、Slack、Meet 的必要请求使用稳定节点，同时保留国内网站、企业内网和本地服务的直连路径。本文以 Clash Verge Rev、Clash Verge、Mihomo 等支持 YAML 规则的客户端为例，说明如何规划策略组、编写规则、验证命中结果，并处理 DNS、系统代理与 TUN 模式之间的关系。

开始前需要明确一个边界：Clash 只能改善请求到代理出口之间的路径，不能修复公司 Wi-Fi 本身的丢包、节点过载、麦克风权限或会议服务端故障。如果会议室网络上行带宽不足，即使规则命中代理，视频仍可能卡顿。因此建议先用浏览器或系统工具确认基础网络，再在 Clash 的连接面板里观察实际域名和策略。不要只根据「全局代理已开启」来判断配置正确，真正有价值的信息是请求是否出现、命中了哪个策略组，以及切换节点后延迟和丢包是否发生变化。

远程办公分流要解决什么问题

远程办公的流量通常不是单一类型。视频会议需要持续的上行、下行和低抖动，文字协作工具更依赖鉴权、消息推送和 WebSocket 长连接，国内办公系统则常常要求固定的直连路径。若用一条规则把所有海外流量送入代理，虽然配置简单，却容易带来三个副作用：第一，国内网站访问绕远，企业 OA 或内网域名可能无法打开；第二，会议流量与大文件下载共用节点，晚高峰时更容易排队；第三，某些服务的登录、验证码和 API 请求可能来自不同域名，规则覆盖不完整时会出现「能登录但不能发消息」的半通状态。

Clash 的规则匹配通常遵循从上到下的顺序。靠前的规则优先级更高，后面的 GEOIP、MATCH 或兜底规则只在前面没有命中时生效。因此，远程办公配置的核心不是堆积大量域名，而是先定义几个清晰的策略组，再把最确定的域名规则放在自定义规则区域的前面。建议至少准备以下三组：

  • OFFICE-PROXY：用于 Zoom、Slack、Google Meet 等需要稳定跨境连接的办公工具，优先选择延迟较低、丢包较少的节点。
  • DIRECT：用于国内网站、公司内网、局域网设备和不需要代理的服务，减少绕路与带宽消耗。
  • 手动备用组：当某个服务的默认节点出现拥塞时，可快速切换到同地区或邻近地区的备用节点，不必重新编辑规则。

不要简单地把 Zoom、Slack 和 Meet 绑定到同一个「海外」大组后就结束。不同服务的最佳出口可能不同：Zoom 对 UDP 音视频和实时抖动比较敏感，Slack 的消息、文件和通话可能使用不同的主机，Google Meet 还会依赖 Google 账号登录与静态资源域名。更稳妥的方式是先统一指向 OFFICE-PROXY，确认稳定后，再根据连接日志拆分为 VIDEO-PROXY、COLLAB-PROXY 等更细的策略组。

排障原则：先让所有办公工具命中同一个稳定策略组，再逐个细分。一次修改十几条规则并同时更换节点，会让你无法判断问题究竟来自规则、DNS 还是线路质量。

Zoom、Slack 与 Meet 的域名规划

域名规则应服务于实际请求，而不是盲目收集网上的域名清单。软件版本、地区、登录方式和 CDN 调度都会影响最终访问主机，所以表格中的条目适合作为起点，最终仍要以 Clash 连接日志中出现的真实域名为准。对于带有大量第三方资源的服务，优先使用官方主域名或明确的后缀规则，避免把整个 CDN 或所有 Google 服务无差别送入代理。

工具 可优先观察的域名 配置重点
Zoom zoom.us、zoom.com 关注登录、会议信令、音视频连接是否命中同一稳定出口
Slack slack.com、工作区实际使用的相关主机 检查消息推送、文件加载与 WebSocket 是否反复断开
Google Meet meet.google.com、googleapis.com、账号鉴权相关主机 不要只代理 Meet 页面，还要核对登录与会议建立阶段的请求

在规则语法上，可以使用 DOMAIN-SUFFIX 覆盖主域名及其子域。例如把 DOMAIN-SUFFIX,zoom.us,OFFICE-PROXY 放在自定义规则中，通常比只写一个固定的 DOMAIN 更不容易漏掉子域。Slack 和 Google Meet 也可以采用相同思路，但要注意策略组名称必须与你配置文件中的实际名称完全一致。部分订阅会把策略组命名为「节点选择」「Proxy」或「自动选择」，不能直接照搬示例中的英文名称。

# Example rules
- DOMAIN-SUFFIX,zoom.us,OFFICE-PROXY
- DOMAIN-SUFFIX,zoom.com,OFFICE-PROXY
- DOMAIN-SUFFIX,slack.com,OFFICE-PROXY
- DOMAIN,meet.google.com,OFFICE-PROXY
- DOMAIN-SUFFIX,googleapis.com,OFFICE-PROXY
- DOMAIN-SUFFIX,googleusercontent.com,OFFICE-PROXY
- DOMAIN-SUFFIX,corp.example.com,DIRECT
- GEOIP,CN,DIRECT
- MATCH,DIRECT

上面的 Google 规则不应无条件复制到所有环境。googleapis.com 可能承载很多与远程办公无关的服务，过宽的代理范围会增加流量和排障复杂度。如果你只需要 Meet，可以先添加 meet.google.com，然后在会议登录、加入房间和开启摄像头的过程中查看连接日志；只有当日志明确显示某些鉴权或 API 主机需要代理时，再增加对应条目。对于公司自有域名、VPN 网关、内部 Git、文件服务器和打印设备，应明确写入直连规则，并放在更宽泛的规则之前。

在 Clash 中完成配置与验证

第一步：确认配置文件和本地端口

打开 Clash Verge Rev 或其他 Mihomo 客户端，先确认当前启用的配置文件确实包含代理组、规则和 DNS 设置。订阅更新后，手写内容可能被覆盖，因此更推荐使用客户端的配置覆写、Merge 或本地补丁功能，把远程办公规则单独保存。找到混合端口，例如 7890，并确认系统代理开关状态。对于只使用桌面客户端的用户，先从 Rule 模式开始，不要一上来就启用 TUN，以便把每一次请求和规则命中关系看清楚。

第二步：添加办公域名规则

将 Zoom、Slack 和 Meet 的规则放到自定义规则的靠前位置。保存后重新载入配置，检查策略组名称是否存在。若客户端提示规则格式错误，优先检查逗号、缩进、策略组拼写和 YAML 层级；规则内容本身正确，并不代表放置位置正确。某些客户端的覆写入口要求使用特定字段，例如 prepend-rules 或图形化的规则编辑器，不能把整段配置随意粘贴到普通文本框中。

第三步：按真实工作流测试

不要只打开网站首页就宣布配置成功。Zoom 应按「登录账号—加入测试会议—打开摄像头—打开麦克风—持续通话五分钟」的顺序测试；Slack 应发送文字、接收消息、打开一个工作区文件，并观察桌面通知是否及时；Meet 则要完成登录、加入会议、切换摄像头和共享屏幕。每完成一个动作，就在 Clash 的连接页面搜索对应域名，确认策略不是 DIRECT 或意外命中了一个高延迟组。

视频会议的连接状态还要结合系统统计判断。若连接面板显示命中 OFFICE-PROXY，但会议仍出现马赛克，可能是节点出口拥塞、UDP 不可用或本地 Wi-Fi 上行不足。若消息发送正常、文件加载失败，说明 Slack 的不同资源可能命中了不同规则；若 Meet 页面能打开但无法加入会议，则应重点查看鉴权、WebSocket 和会议服务相关主机，而不是继续更换浏览器。

第四步：记录节点与规则结果

建议为每个办公工具记录一次测试结果，包括节点地区、连接延迟、会议持续时间、是否出现重连、屏幕共享是否稳定，以及 Clash 日志中的主要域名。这样在下次订阅更新或节点调整后，可以直接复测，而不是凭印象判断「今天网络变差了」。如果公司有固定办公时段，还可以分别在上午、下午和晚高峰测试，因为相同节点的平均延迟并不能代表全天的抖动情况。

DNS、系统代理与 TUN 模式如何取舍

分流规则匹配的是域名，但域名解析发生在请求建立之前，所以 DNS 配置会直接影响判断结果。启用 fake-ip 或 redir-host 时，应确保 DNS 请求没有被系统、浏览器 DoH 或其他 VPN 服务偷偷接管。常见问题是：Clash 连接面板里看不到 Meet 或 Slack 的域名，只出现陌生 IP；这可能意味着应用使用了自己的加密 DNS，或者流量绕过了 Clash。此时不要先增加更多规则，应先确认 DNS 路径和应用代理设置。

系统代理模式适合大多数浏览器、办公客户端和遵循 HTTP 代理环境的程序，优点是改动小、容易关闭，也不容易影响企业 VPN 的路由。它无法保证所有程序都遵守代理，尤其是部分原生音视频模块、后台服务和命令行工具。若 Slack 桌面版能用但某个集成终端无法访问，不要直接认为规则失效，可以检查该程序是否读取系统代理，或在终端中显式设置 HTTPS_PROXY。

TUN 模式通过虚拟网卡接管更底层的流量，适合应用完全不支持 HTTP 代理，或你需要让多个后台进程统一经过 Clash 的场景。但 TUN 更容易和公司 VPN、虚拟机网卡、Docker 网络以及安全软件冲突。启用后若出现内网地址打不开、公司 VPN 失效、系统 DNS 反复变化，应先关闭 TUN，恢复 Rule 加系统代理进行对照。只有确认应用确实绕过用户态代理，并且你清楚 TUN 的路由、DNS 和绕过列表设置时，才值得长期启用。

企业网络提示：公司 VPN、零信任客户端和 Clash 不宜同时争抢默认路由。优先询问 IT 部门哪些域名必须走企业通道，再把这些域名或网段加入绕过列表，避免为了修复 Meet 而影响内部系统。

卡顿、延迟与无法登录的排查顺序

遇到问题时，建议按照「规则命中—节点质量—DNS—应用行为—本地网络」的顺序排查。第一步看 Clash 连接日志：如果完全没有相关请求，说明应用没有经过 Clash，应该检查系统代理、TUN、应用自身代理设置或防火墙；如果请求出现但显示 DIRECT，说明规则顺序或域名覆盖不足；如果命中代理却频繁重连，再测试备用节点和不同地区出口。

第二步区分延迟与抖动。网页测速显示的平均延迟较低，并不代表视频会议稳定。Zoom 和 Meet 更怕短时间内连续丢包，Slack 则更容易表现为消息推送断开。可以在相同网络下分别测试两个策略组，不要同时切换 DNS、节点和 TUN。若更换节点后会议立刻恢复，问题倾向于出口质量；若所有节点都一样，继续查本地 Wi-Fi、路由器负载或公司网络策略。

第三步检查规则是否过宽或过窄。过宽会让国内办公系统、云盘和大文件下载占用海外节点；过窄则会出现登录成功、消息失败或会议页面打开但无法建立媒体连接。对于新增域名，先临时放入 OFFICE-PROXY 验证，再决定是否长期保留。规则稳定后，定期清理不再出现的条目，避免配置文件越来越难维护。

还要留意账号与权限问题。Zoom 的摄像头权限、Slack 的工作区策略、Meet 的浏览器权限和企业 SSO 都可能造成类似网络故障的表象。若连接日志显示请求快速返回 401、403 或权限提示，而不是超时、重置或 TLS 失败，就不应继续修改 Clash 规则。网络配置负责建立连接，不能替代组织管理员授权。

与只提供单一全局开关的代理工具相比，远程办公更需要可观察的规则命中、可切换的策略组和明确的直连例外；一些轻量工具虽然上手快，却常把国内业务、视频会议和后台同步混在一起，出了问题很难定位。Clash 的优势在于能用 DOMAIN、策略组、连接日志和可选 TUN 把链路拆开：你可以让 Zoom、Slack、Meet 走稳定节点，让企业内网保持直连，并根据实际日志逐步收紧规则。如果你希望把这套分流方案应用到自己的办公设备上，可先选择合适客户端，再按本文步骤完成配置。

前往下载 →