前言：远程办公为什么需要精细分流
对已经熟悉 Clash 基础操作的远程办公用户来说，真正影响效率的通常不是“能不能连接”，而是不同办公流量是否走在合适的路径上。你可能一边使用 Zoom 参加跨国视频会议，一边在 Slack 中处理消息、上传文件，还要通过 Google Meet 或 Google Workspace 协作。如果所有流量都强制走同一个节点，会议可能出现延迟和抖动，国内网站又会变慢；如果全部直连，Slack、Meet 或文档服务则可能加载失败。
因此，远程办公的重点不是简单开启“全局模式”，而是根据应用特征建立清晰的策略组：视频会议优先考虑低延迟、低抖动和稳定上行；即时通信更看重长连接可靠性；日常国内服务则继续使用 DIRECT。本文以 Mihomo 内核及 Clash Verge、Clash Verge Rev 等常见客户端为例，整理一套可直接修改的分流思路。
本文目标
让 Zoom、Slack 与 Google Meet 使用稳定的办公线路，同时保留国内网站直连，并通过 TUN 模式减少应用绕过代理造成的连接问题。
1先规划策略组：不要让所有办公流量混用节点
在修改规则之前，建议先检查订阅配置中是否已经存在“自动选择”“故障转移”或“手动选择”等策略组。如果所有域名最终都指向同一个默认组，规则写得再详细也很难获得稳定体验。远程办公至少可以准备两个独立策略组：一个服务视频会议，另一个服务协作工具。
| 策略组 | 适用流量 | 节点选择重点 | 建议模式 |
|---|---|---|---|
| Work-Meeting | Zoom、Google Meet | 低延迟、低抖动、上行稳定 | 手动选择或 url-test |
| Office-Stack | Slack、Notion、Google Workspace | 长连接稳定、丢包少、出口可靠 | 手动选择或 fallback |
| DIRECT | 国内网站、打印机、局域网设备 | 不经过代理 | 直连 |
视频会议不一定需要测速结果最低的节点。某些节点延迟只有 80 毫秒，但高峰期丢包严重，实际通话质量反而不如延迟 130 毫秒、线路稳定的节点。建议在工作时段进行一次真实测试：加入会议但关闭麦克风，观察画面是否频繁降质，再进行语音回环测试。对于 Slack，优先选择能够稳定维持 WebSocket 长连接的节点，避免频繁自动切换出口。
策略组命名建议
策略组名称可以自定义，但规则中的名称必须完全一致。本文使用 Work-Meeting 和 Office-Stack，请根据自己的配置文件替换。
2配置 Zoom、Slack 与 Google Meet 分流规则
Clash 规则通常按照从上到下的顺序匹配，越具体的规则越应该放在靠前位置。下面的示例适合添加到订阅配置的规则覆写、Merge 配置或自建配置中。若你的订阅已经包含同类规则，请先确认策略组名称，避免重复规则造成判断混乱。
视频会议规则
Zoom 和 Google Meet 都包含网页访问、登录验证以及实时媒体传输。域名规则可以覆盖大部分控制面流量，但实际音视频连接还可能使用 UDP、动态地址或 WebRTC。因此，规则配置完成后仍要配合 TUN 模式和系统权限检查。
Slack 与协作服务规则
Slack 的工作区域名、文件域名和消息服务并不总是集中在同一个主域名下。下面的规则可以覆盖常见访问路径；如果企业使用自定义工作区域名，还应将该域名补充到同一策略组。
不要盲目扩大规则范围
不要直接把所有 google.com 或所有企业域名都交给代理，否则可能影响本地服务、公司内网和登录验证。优先使用具体的域名后缀，并通过 Clash 日志确认实际命中结果。
3动手设置：在 Clash 客户端中完成一次办公配置
- 打开 Clash Verge、Clash Verge Rev 或其他 Mihomo 客户端，确认当前配置文件可以正常加载，并查看策略组列表。
- 在“配置”或“订阅”页面备份原始 YAML 文件。不要直接修改订阅源，避免下次更新时覆盖自己的规则。
- 通过 Merge、Script 或规则覆写功能加入
Work-Meeting与Office-Stack规则。若策略组不存在，先在配置中创建对应组。 - 重新加载配置后，打开 Clash 的连接日志，依次访问 Zoom、Slack 和 Google Meet，确认请求命中了预期策略组。
- 先选择一个固定节点进行测试，再比较第二个节点的会议画面、语音延迟和 Slack 消息发送速度。确认稳定后，不要在会议期间频繁切换节点。
测试时应区分“网页打不开”和“会议媒体质量差”两类问题。前者通常与域名规则、DNS 或节点不可用有关；后者则更多涉及 UDP、WebRTC、出口带宽和丢包率。建议在 Clash 日志中观察连接是否反复重试，同时在 Zoom 的统计信息中查看延迟、抖动和丢包，而不要只看客户端显示的延迟数字。
4开启 TUN 与 DNS 设置，避免应用绕过代理
仅开启系统代理时，浏览器和部分桌面软件能够正常使用 Clash，但会议客户端、后台更新程序以及 WebRTC 连接可能仍然绕过系统代理。对于需要稳定办公的电脑，建议在 Clash Verge Rev 或 Mihomo 客户端中开启 TUN 模式，并授予系统要求的网络扩展或管理员权限。
fake-ip 通常能让域名规则更稳定地接管应用请求，但局域网打印机、公司内网、NAS 和某些银行软件可能不适合使用假 IP。遇到内网访问异常时，应将相关域名加入 fake-ip-filter，或者暂时关闭 TUN 进行对照测试。macOS 用户还需要检查系统网络扩展是否被允许；Windows 用户则应确认虚拟网卡驱动安装成功。
办公前检查清单
确认规则模式已启用、TUN 状态正常、Work-Meeting 节点没有频繁切换、Slack 能保持在线，并提前测试麦克风、摄像头和企业 VPN 是否互不冲突。
5常见问题与稳定性优化
Zoom 能打开，但会议画面卡顿
先查看节点高峰期带宽和丢包，不要只更换地区。若当前策略组使用 url-test，可以适当延长测试间隔，避免会议过程中因探测结果变化而切换节点。必要时将会议策略改为手动选择，使用一个经过实际通话验证的固定节点。
Slack 一直显示 Connecting
这通常表示 WebSocket 或相关消息域名没有命中代理规则。检查 slack-edge.com、slack-msgs.com 和工作区自定义域名的请求记录；如果规则命中但仍然断开，应更换出口稳定的节点，并检查本地防火墙、企业安全软件是否拦截长连接。
开启 TUN 后公司内网无法访问
将公司内网域名、内网网段和局域网设备设置为直连，并保留本地 DNS 解析所需的例外。不要为了修复一个内网地址而关闭全部分流。完成调整后，分别测试公司门户、Git 服务、打印机和视频会议，确保办公链路没有相互影响。
最后，建议每次修改只调整一个变量，并记录节点、模式、规则命中情况和测试结果。这样即使订阅更新或客户端升级，也能快速恢复到稳定配置，而不是重新尝试全局、规则和直连模式。