远程办公时，Zoom、Slack、Google Meet 的问题往往不是简单的“能不能打开”，而是会议进行十几分钟后突然卡顿、语音延迟升高、摄像头画面降质，或者 Slack 消息要等待很久才同步。更麻烦的是，如果直接开启全局代理，国内企业 OA、内网 Git、钉钉、企业微信以及本地办公系统也可能被送到不合适的节点，造成访问变慢或登录异常。
更稳妥的做法，是用 Clash 的规则分流为远程办公流量单独安排出口：Zoom、Slack、Google Meet 等必要域名走稳定的代理策略组，国内网站和公司内网保持 DIRECT，其它不确定的流量则根据连接日志逐步调整。本文以 Clash Verge Rev 或其它支持 Mihomo 内核的客户端为例，介绍远程办公场景下的节点选择、应用分流、规则顺序、DNS 检查，以及会议前后的验证方法。配置时请同时遵守所在地区法律法规、公司网络安全制度和视频会议平台的使用条款。
远程办公最容易被忽略的网络需求
视频会议和协作软件对网络的要求，与普通网页浏览并不完全相同。打开网页时，偶尔等待几秒可能不影响工作；但 Zoom 或 Google Meet 使用的是持续的音视频连接，短时间丢包、抖动或上行带宽下降，都会被放大为卡顿、回声和画面模糊。Slack 虽然主要是消息和文件协作，但它也包含实时通知、文件上传、图片预览、语音或视频功能，同样需要稳定的长连接。
因此，远程办公配置不应只看测速软件里的峰值下载速度，而应关注以下几项指标：
- 延迟和抖动：延迟决定声音和操作反馈是否及时，抖动则决定连接是否忽快忽慢。会议中平均延迟不高，但抖动频繁，也会出现明显的断续感。
- 上行稳定性：开启摄像头、共享屏幕和上传文件时，上行带宽比单纯下载网页更重要。家庭宽带被多人同时上传或备份时，会议质量很容易下降。
- 长连接保持能力：Slack 通知和会议信令经常依赖 WebSocket、TLS 长连接或持续轮询。节点短时间可用，不代表能够稳定维持一小时会议。
- 出口位置和路由：距离并非越近越好。某些节点虽然地理位置较近，但高峰期拥堵严重；稳定、低丢包的线路通常比瞬时速度更有价值。
- 本地业务兼容性：公司 VPN、内网域名、打印机、NAS 和国内办公平台通常不应经过代理。分流边界越清晰，出现登录验证或访问异常的概率越低。
还要注意，Zoom、Slack 和 Google Meet 并不一定只访问一个域名。登录、鉴权、更新、图片、文件和音视频服务器可能使用不同的主机名，并且会根据地区和网络情况动态调度。因此，不建议只凭一份过时的域名清单完成配置，最好结合 Clash 的连接记录观察实际请求。
DIRECT，优先检查规则顺序；若已经命中代理但仍频繁断开，再测试节点质量、DNS 和本地带宽。
Zoom、Slack 与 Google Meet 的分流规划
建议先建立一个专门的策略组，例如 REMOTE-WORK，并在其中放入延迟较低、晚高峰表现稳定的节点。不要把会议流量直接绑定到某一个临时节点，因为节点维护、线路调整或供应商更换出口后，配置可能突然失效。使用策略组的好处是可以在 Clash 界面中快速切换，也方便把 Zoom、Slack 和 Google Meet 统一迁移到新的稳定线路。
| 服务场景 | 常见请求类型 | 建议策略 | 重点观察 |
|---|---|---|---|
| Zoom 会议 | 登录、会议信令、音视频连接 | REMOTE-WORK |
延迟、丢包、上行稳定性 |
| Slack 协作 | 消息同步、WebSocket、文件与图片 | REMOTE-WORK |
长连接、消息到达速度、文件上传 |
| Google Meet | Google 登录、会议媒体与页面资源 | REMOTE-WORK |
登录链路、音视频质量、页面加载 |
| 国内办公系统 | OA、企业邮箱、内网 Git、打印服务 | DIRECT 或企业专用策略 |
内网解析、单点登录、访问权限 |
规则的核心是“按域名分类，而不是按软件名称猜测”。桌面应用的进程名有时无法被普通规则准确识别，尤其是应用通过系统组件、浏览器内核或动态端口建立连接时。域名规则通常更容易验证，也更适合在 Clash 的连接面板中追踪。
如果订阅配置支持自定义规则或覆写，可以把远程办公相关规则放在通用规则集之前。示意写法如下，策略组名称请替换为你实际配置中的名称：
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,google.com,REMOTE-WORK
- DOMAIN-SUFFIX,googleapis.com,REMOTE-WORK
- DOMAIN-SUFFIX,meet.google.com,REMOTE-WORK
- DOMAIN-SUFFIX,corp.example,DIRECT
- GEOIP,CN,DIRECT
- MATCH,DIRECT这段示例不能保证覆盖所有服务端主机，也不建议不加验证地把整个 google.com 都交给代理。若公司使用 Google Workspace，可能需要登录、文档、日历等多个 Google 服务；如果只是 Google Meet 会议，则应在连接日志中确认真实访问的域名，再缩小或补充规则范围。对于 Slack，也要留意工作区自定义域名、文件 CDN 和图片资源主机名，消息能同步但文件打不开，通常就是规则只覆盖了主站而遗漏了资源域名。
在 Clash Verge Rev 中完成配置与验证
下面是一套适合日常远程办公的操作顺序。它的重点不是一次写出“完美规则”，而是每完成一层就验证一次，避免多个变量同时变化后无法判断到底是哪一步生效。
第一步：准备配置文件和策略组
打开 Clash Verge Rev，先确认当前配置文件能够正常加载，节点列表不是空白，且代理内核处于运行状态。如果配置来自订阅服务，先执行一次更新，确认更新时间和节点数量正常。接着查看策略组列表，找到负责外网流量的组；如果没有专门的远程办公策略组，可以在配置覆写中新增一个，并手动选择两到三个候选节点。
选择候选节点时，不要只点击延迟测试结果最低的那个。分别在工作日上午、下午和晚间观察延迟变化，并进行一次较长时间的网页或视频会议测试。某些节点的测速延迟很漂亮，但建立长连接后会频繁重连；另一些节点延迟略高，却能让会议保持稳定。远程办公优先选择后者。
第二步：添加分流规则
将 Zoom、Slack、Google Meet 相关规则放到宽泛的规则集之前。例如，如果订阅中存在“所有海外域名走代理”的规则，应确保明确的远程办公规则排在它之前；如果存在“国内 IP 直连”规则，也要确认目标域名没有因为解析结果或规则集顺序提前命中直连。
保存配置后重新加载内核，并打开连接面板。不要只观察浏览器页面是否打开，而应在实际启动 Zoom、刷新 Slack 工作区、加入 Google Meet 后，搜索 zoom、slack、google 等关键词。重点核对三件事：第一，主机名是否是你预期的服务域名；第二，策略列是否显示 REMOTE-WORK；第三，连接是否反复重试或在短时间内大量失败。
第三步：进行会议前测试
正式会议前至少提前几分钟进行一次短测试。Zoom 可以进入音频设置检查麦克风、扬声器和网络状态；Google Meet 可以创建临时会议，打开摄像头并进行屏幕共享；Slack 则应发送一条测试消息，打开工作区中的图片或小文件，确认实时通知和资源加载都正常。
测试时最好关闭正在进行的大型下载、云盘同步和系统更新。否则，即使 Clash 分流正确，家庭网络的上行队列也可能造成会议卡顿。若办公室或家中有多个设备共用网络，可以先确认其它设备是否正在上传视频、备份照片或进行大型游戏更新。
第四步：决定是否启用 TUN
对于能够识别系统代理的 Zoom、Slack 和浏览器环境，通常先使用系统代理加规则分流即可。这样配置简单、影响范围可控，也不容易干扰公司 VPN 和本地设备发现。只有当某个程序明确不读取系统代理、连接面板看不到请求，或者应用始终绕过 HTTP 代理直连时，才考虑启用 TUN。
TUN 会在更底层接管流量，能够覆盖部分不支持代理环境变量的程序，但也会带来更大的排障范围。启用前应记录当前配置，并确认 Clash Verge Rev 已获得系统要求的网络权限。开启后，检查公司 VPN、局域网打印机、内网地址和远程桌面是否仍然可用。如果发现内网被错误送入代理，可通过私有网段、企业域名和局域网规则补充直连策略，而不是直接把所有流量切成全局代理。
DNS、节点与会议卡顿的排查方法
分流规则正确，并不代表整个链路一定稳定。DNS 解析异常会让域名指向不可用地址，或者使规则无法按照预期识别主机名。使用 fake-ip、redir-host 或其它 DNS 模式时，应保持配置中的 DNS 方案与内核文档一致，不要同时叠加多个相互冲突的 DNS 劫持工具。特别是在电脑上还运行企业 VPN、安全软件或其它代理客户端时，DNS 请求可能被不同组件重复接管。
可以按照下面的顺序排查：
- 确认客户端状态：检查 Clash 内核是否正在运行，系统代理是否已经打开，端口是否被其它代理软件占用。
- 确认规则命中：在连接列表查看实际域名和策略。若显示
DIRECT，先修正规则顺序；若没有任何记录，检查应用是否绕过系统代理或是否需要 TUN。 - 确认节点质量：在相同时间段切换两个候选节点，比较会议中的延迟、重连和音频断续情况。不要只用一次测速下结论。
- 确认本地带宽：暂停云盘同步、系统更新和大型上传，观察会议质量是否恢复。若恢复，问题可能在家庭网络拥塞，而不是 Clash 规则。
- 确认应用设置：检查 Zoom 或 Meet 是否自动降低画质、切换麦克风，以及 Slack 是否处于离线或重新连接状态。业务层错误不要全部归因于代理。
如果只有视频画面卡顿而语音基本正常，通常说明上行带宽或丢包需要优先检查；如果消息延迟、文件打不开，但网页访问正常，则应查看 Slack 的长连接和 CDN 域名是否使用了不同策略；如果登录页面一直循环跳转，则要检查鉴权域名、系统时间、浏览器 Cookie 以及企业单点登录策略。对于 Zoom 会议中途断开，建议记录断开时间、当前节点、连接日志和网络环境，之后再做单变量切换。
与只提供简单全局开关的代理工具相比，远程办公更需要可观察、可回退的分流能力：有些工具配置入口较少，遇到“Zoom 能用但内网 OA 变慢”或“Slack 消息正常但文件 CDN 失败”时，很难定位具体请求；Clash 则可以通过策略组、域名规则、连接日志和可选 TUN 分层处理，让会议流量走稳定节点，同时保留国内网站、企业内网和本地办公设备的直连路径。如果你正在寻找一套能够按应用场景调整、并方便逐条验证的远程办公代理方案，可以从 Clash 客户端开始配置。