前言：办公网络不必一律走代理
远程办公时，视频会议、即时消息和文档协作往往同时运行。网络出现问题，未必只是“节点慢”：会议媒体流可能对延迟和抖动敏感，Slack 的长连接可能反复重连，Google Meet 也可能因为 UDP 不通而切换传输方式。若把所有流量都交给同一个自动选择组，故障时就很难判断究竟是本地网络、规则顺序还是节点质量造成的。
更稳妥的做法是先保持 Clash 的规则模式，再按工具和使用场景建立清晰的策略：访问国内服务走直连，确实需要代理的协作服务进入固定、稳定的代理组；会议则根据实际线路测试决定直连还是代理。需要注意，Clash 负责按规则选择路径，并不能保证任意节点都适合实时语音视频，也不能替代运营商网络和服务端的质量。
配置目标
让 Zoom、Slack 与 Google Meet 的流量路径可观察、可单独调整；减少不必要的代理，并在会议前用实际通话验证延迟、丢包和连接稳定性。
1先确认客户端、模式与策略组
本文示例采用 Mihomo 常见的规则写法，适用于使用 Mihomo 内核的 Clash Verge、Clash Verge Rev 等客户端。不同客户端的菜单名称、配置合并方式和内核版本可能略有差别；Clash for Windows、ClashX 或移动端客户端也应先确认当前内核是否支持相关规则。不要仅凭界面名称判断功能，尤其要区分系统代理与 TUN 接管。
- 选择规则模式：如果客户端处于全局模式，规则列表通常不会按预期发挥作用。切换到 Rule（规则）模式，并确认配置已经成功载入。
- 检查策略组名称：下文的
Work-Meeting、Office-Stack和DIRECT都是示例。引用策略组前，必须确保你的配置中存在同名策略组；若机场订阅已有“手动选择”“自动选择”组，可把示例名称替换为实际名称。 - 明确规则写入位置：规则通常按从上到下匹配，先命中的规则会优先处理。把办公应用规则放在宽泛的规则集和最终兜底规则之前；不要将它们放到
MATCH之后。 - 备份再修改：订阅配置可能在更新时覆盖手工改动。优先使用客户端提供的 Merge、覆写或规则提供者功能，并在修改前保存原配置。若客户端不支持合并，不要直接编辑后又误用订阅更新覆盖文件。
先从域名规则开始
域名分流通常比按应用进程分流更容易验证，也更便于跨平台维护。只有在已启用 TUN、确认客户端支持进程匹配并知道实际进程名时，再考虑使用 PROCESS-NAME；进程名规则并非所有平台和运行模式都能生效。
2为 Zoom 选择适合会议的路径
Zoom 的会议体验不仅取决于网页能否打开。音视频流对延迟、抖动和丢包更敏感，而屏幕共享、会议控制和登录等请求也可能使用不同域名或连接方式。把所有 Zoom 流量盲目交给一个拥挤节点，可能出现“能加入会议，但说话延迟明显”或画面质量不断下降的情况。
方案 A：先测试直连
如果本地网络可以稳定访问 Zoom，且公司网络策略允许直连，可以将常见 Zoom 域名设为 DIRECT。这能避免代理节点增加的往返延迟。但不同地区、企业网络和服务端线路差异很大，直连不应被视作所有用户的固定最佳答案。示例域名用于展示规则思路，实际覆盖范围还应结合客户端连接记录确认。
方案 B：为会议指定稳定代理组
如果直连无法稳定连接，或公司的网络环境要求通过代理访问，可把规则目标改为专用会议组。优先测试固定节点或手动选择组，尽量避免在一场会议中频繁切换出口。自动测速组可用于初步筛选，但“网站测速延迟最低”不等于“实时音视频质量最好”；节点的上行带宽、丢包、负载和 UDP 支持都需要单独验证。
会议媒体流不一定只靠域名规则
Zoom 可能使用 UDP 媒体传输以及动态地址。单纯增加域名规则，不代表所有媒体流都已进入预期策略组。若连接记录中看不到相关流量，先检查是否启用了系统代理或 TUN、规则是否命中，以及当前网络是否允许相应传输；不要照搬来源不明或可能过期的 IP-CIDR 列表。
3让 Slack 消息与文件连接更稳定
Slack 除了网页和桌面端登录请求，还会使用长连接保持消息实时更新，并通过相关域名处理静态资源、附件或消息服务。出现“Connecting...”提示、消息发送后迟迟未同步、文件预览加载不完整时，可以先在 Clash 的连接或日志页面检查对应请求命中了哪个策略组，再针对确认过的域名调整规则。
对经常需要代理访问的工作环境，可以把 Slack 放入单独的协作工具组，选择稳定、负载较低的节点。不要把整个 google.com、云平台或所有 CDN 域名都粗略地划入办公代理组，否则可能连带改变其他应用和国内服务的路径。
确认配置中已存在 Office-Stack 策略组后，将以下规则放在通用规则和最终匹配之前。服务域名可能随产品功能调整，遇到未命中的请求时，以客户端连接记录和 Slack 实际使用的域名为准。
如果部分桌面端请求没有被域名规则覆盖，可在确认 TUN 和 Mihomo 进程识别功能正常后，再评估按进程分流。不同系统上应用进程名称可能不同，浏览器版 Slack 又会与浏览器内其他网页共用进程，因此不要未经验证就把整个浏览器进程强制送入办公代理组。
4配置 Google Meet，并处理 UDP 与回退
Google Meet 的会议控制页面和实时媒体传输并非完全相同的流量。规则可以帮助指定常见会议域名的策略，但实际音视频连接还受 TUN 接管能力、网络是否允许 UDP、代理协议以及浏览器实现影响。若网页打开正常而通话质量差，应该先检查通话诊断和 Clash 连接记录，不能仅凭页面加载成功判断媒体路径正常。
可以先让明确的会议域名进入专用会议组，再进行一对一测试。对于其他 Google 服务，避免为了 Meet 将整个 Google 域名空间统一代理；这样可能让搜索、邮箱、云端文档等原有规则也发生变化。
如果当前节点或网络不支持 UDP，媒体流可能改用其他传输方式，表现为延迟上升、画面不稳定或加入会议耗时变长。可分别比较直连和代理路径，并确认选用的内核、代理协议和网络环境是否支持所需传输。不要为追求“全代理”而忽略本地路由、企业防火墙或浏览器权限问题；公司设备还应遵循组织的安全与网络要求。
避免把测试结果当成永久结论
家庭宽带、公司 VPN、手机热点的出口和 UDP 策略可能完全不同。建议在常用办公网络下分别测试，并记录每次使用的模式、策略组和节点，方便问题复现与回滚。
5用实际通话验证规则是否生效
修改完成后，不要只看规则文件是否通过解析。按照“规则命中—连接建立—实际体验”的顺序逐项确认，能避免把 DNS 解析、节点质量或服务端故障误判成规则问题。
- 检查配置是否生效：保存并重新载入配置，确认客户端没有 YAML 缩进错误、策略组不存在或规则格式错误等提示。若使用规则合并功能，也要确认合并后的规则确实出现在有效配置中。
- 观察连接命中情况：启动 Zoom、Slack 或 Google Meet 后查看连接列表和日志，核对域名及命中的策略组。若看到连接命中更靠前的通用规则，调整规则顺序；若没有相关记录，检查是否由当前代理模式接管。
- 先做短时对照测试：用同一设备、同一网络，分别测试直连和会议代理组。每次只更改一个变量，并记录节点、延迟、丢包、音频延迟、视频清晰度以及是否掉线。
- 测试真实工作流程：进行至少几分钟的双向通话，试用麦克风、摄像头、屏幕共享和文件发送。单纯打开会议主页或运行一次延迟测速，不能代表长时间会议的稳定性。
- 保留可回退配置：如果修改后连接变差，先恢复原策略或删除新增规则，再确认问题是否消失。避免一次导入多个规则集、切换 DNS 和更换节点，否则难以定位故障来源。
建议把办公策略简化为可理解的几类：会议组负责 Zoom 和 Meet 的线路测试，协作组负责 Slack 等消息工具，常见国内流量继续使用原有直连规则。不同服务不一定必须使用不同节点，但分组能让你在会议前快速选择和排查。若某个办公服务经常无法直连，就只对确认过的必要域名设置代理，而不是切换全局模式。
最后，规则配置不应绕过单位的访问控制、数据保护要求或服务条款。使用公司设备和企业网络时，优先遵循 IT 部门提供的代理方式；涉及会议录音、文件传输和账号安全的操作，也应按组织政策执行。合适的 Clash 配置应当让网络路径更清楚，而不是削弱办公环境的安全边界。