远程办公时，Zoom 或 Google Meet 会议突然卡顿、Slack 消息转圈，未必是「节点速度不够」这么简单。视频会议同时包含信令、音视频传输和屏幕共享流量，Slack 也可能从不同域名加载消息、文件与图片；如果把所有流量都切到同一出口，国内办公系统可能变慢，会议媒体流也未必因此更稳定。更实用的思路是让 Clash 按规则分流：协作服务按需进入代理策略组，国内服务与企业内网继续直连，再通过连接记录确认实际命中结果。
本文以 Clash Verge Rev 和 Mihomo 常见能力为例，介绍适用于 Windows、macOS 桌面端的配置思路。不同客户端版本、订阅规则和企业网络环境会影响菜单名称与可用模式，因此请以自己的界面和单位网络政策为准。文中域名是排查起点，不代表 Zoom、Google Meet 或 Slack 的完整官方域名清单；遇到服务更新或企业定制登录流程时，应以连接面板中实际观察到的主机名为准。
先分辨问题：节点、规则还是会议网络
配置前先记录故障发生时的具体表现。若网页和聊天消息正常，只有视频画面冻结、音频断续，问题更可能出在实时媒体链路、Wi-Fi 丢包、节点上行拥塞或 UDP 转发能力，而不是单纯的网页代理规则。若会议能加入但无法登录，或 Slack 文件反复加载失败，则应检查对应域名是否命中预期策略、DNS 是否正常，以及系统时间和账号认证是否有异常。
建议在一次故障期间打开 Clash 的连接面板，分别搜索 zoom、slack、meet 等关键词，查看连接的主机名、进程、命中规则和策略组。重点不是只看「代理已开启」，而是确认目标请求是否进入 Mihomo、实际命中了哪条规则、当前选择的节点是否可用。若面板完全没有相关连接，应用可能没有使用系统代理，或者媒体流量走了独立的 UDP 路径；这时反复调整域名规则通常无济于事。
- 登录或网页打不开：先检查浏览器连接是否进入代理策略组，再确认 DNS 和认证页面能否加载。
- 消息正常、会议卡顿：优先测试有线网络、Wi-Fi 信号、节点负载与 UDP 支持，不要只看网页测速结果。
- 桌面端正常、浏览器端异常：核对两个应用的系统代理设置、扩展程序和进程规则是否一致。
- 切换节点后问题仍在：记录连接面板中的最终策略，并排除单位 VPN、防火墙或会议服务自身故障。
选择合适模式：规则分流优先，TUN 按需启用
日常办公通常先从规则模式开始。它让 Clash 根据域名、IP 或规则集决定流量出口，便于把协作服务放入代理策略组，同时保留国内网站、打印机、NAS、公司门户和内网代码仓库的直连路径。使用规则模式时，浏览器通常较容易遵循系统代理；但并非每个桌面应用、子进程或实时音视频连接都会自动使用 HTTP 系统代理。
TUN 模式可以在网络层接管更多应用流量，适合 Zoom、Meet 或 Slack 桌面程序不遵循系统代理、连接面板里又看不到相关请求的情况。不过，TUN 会影响更多网络连接，可能与企业 VPN、终端安全软件、虚拟机网卡或其他代理程序冲突。遇到公司网络访问异常、内网域名解析变化或 VPN 断连时，应先关闭 TUN 回到原有网络状态，再逐项检查路由与 DNS，不要把多个网络接管工具同时开启后凭感觉判断。
媒体流量还需要单独看待。Zoom 和 Meet 的视频、语音连接可能使用 UDP；仅设置系统 HTTP 代理，不能保证这类流量一定经过代理。Mihomo 是否能接管并转发对应流量，取决于客户端模式、TUN 配置、内核能力和节点支持。若组织要求媒体流量必须走指定出口，请与网络管理员核实；若没有此要求，可先让网页信令按规则处理，并直接测试会议媒体质量，避免在不了解拓扑时强行把所有 UDP 流量塞进代理。
建立协作服务策略组与分流规则
先检查订阅配置中是否已经有可用的代理策略组，例如名为 PROXY、节点选择 或 自动选择 的组。规则最终引用的策略组名称必须与当前配置一致；下面的名称只是示例，不能不经核对直接粘贴。若配置允许覆写或添加自定义规则，可将面向协作服务的规则放在较宽泛的规则集、GeoIP 和最终兜底规则之前，避免前面的规则先把请求判成 DIRECT。
# 示例：将协作服务相关域名交给代理策略组
- DOMAIN-SUFFIX,zoom.us,PROXY
- DOMAIN-SUFFIX,zoom.com,PROXY
- DOMAIN-SUFFIX,slack.com,PROXY
- DOMAIN-SUFFIX,slack-edge.com,PROXY
- DOMAIN-SUFFIX,slack-files.com,PROXY
- DOMAIN,meet.google.com,PROXY
- MATCH,DIRECT这段示例采用常见 Clash 规则格式，PROXY 必须替换为配置里真实存在的策略组。Zoom、Slack 和 Google 服务的域名可能随功能、客户端版本和区域变化；例如会议登录、文件预览、更新检查或企业单点登录可能使用其他主机。不要为了图省事就把整个 google.com、googleapis.com 或所有云服务域名一概代理，这可能改变搜索、云盘、办公套件等无关服务的出口，也增加排查范围。更好的做法是先从连接面板找出失败请求，再添加范围尽可能小的规则。
国内服务直连通常由已有的国内域名规则和 IP 规则处理。不要把一条宽泛的协作服务规则放到它们后面，也不要盲目添加过大的 DOMAIN-SUFFIX 条目；规则匹配遵循配置中的顺序，过早命中的规则会让后续细分规则失效。若公司门户、内部工单或企业 SSO 使用公共云域名，先确认其访问要求，再决定该域名应直连、走单位 VPN，还是进入代理策略组。配置文件由订阅托管时，优先使用客户端支持的覆写方式，并保留原始配置副本，避免刷新订阅时自定义改动丢失。
Zoom、Meet 和 Slack 不一定适合共用同一个节点。可以先将它们指向同一代理策略组，确认分流工作后，再按实际体验拆成「会议」和「协作」两个组。会议策略组宜选择上行稳定、丢包较低的线路；Slack 以消息和文件访问为主，可优先考虑连接稳定、区域符合账号与单位要求的节点。自动选择组的延迟测试只能反映测试时的连接状况，不等于真实会议质量，也不一定测到音视频 UDP 链路。
桌面端操作：导入、验证、再逐步优化
在 Clash Verge Rev 中，先确认当前配置已成功载入、核心运行正常，并查看系统代理开关和模式选择。菜单名称会随版本变化，一般可在配置或订阅页面更新配置，在代理页面选择策略组和节点，在设置页面查看系统代理、TUN 与端口选项。若你使用其他 Mihomo 前端，操作入口可能不同，但验证原则相同：先确认配置生效，再观察目标连接，而不是只看开关的颜色。
- 备份当前配置：记录配置名称和现有模式；若将编辑覆写内容，先保存副本，避免订阅更新后无法恢复。
- 检查策略组：确认规则引用的组名真实存在，并选择一个延迟与负载都合适的节点作为初始测试对象。
- 加入小范围规则：先添加 Zoom、Slack 或 Meet 当前确实使用的域名，确保它们位于可能提前命中的规则之前。
- 重载配置并观察连接：刷新或重载后启动对应应用，在连接面板核对主机名、规则类型和策略组，必要时搜索应用进程。
- 实际加入短会议：测试语音、摄像头、屏幕共享和文件发送；只看节点延迟或网页能打开，不能代替这一环节。
- 逐项调整：若请求命中错误规则，修规则顺序；若命中正确但媒体差，测试节点或网络；应用流量未被接管时，再评估 TUN。
策略组的延迟测试适合先剔除不可连接的节点，但不要只选数字最低的节点。高峰时段的丢包、持续带宽、上行质量和到会议服务的实际路由，往往比一次短连接测试更能影响体验。建议在你通常开会的时间做两到三次测试，并在同一网络、同一会议应用下比较结果。每次只换一个节点或模式，同时记下结果，避免多个变量一起变化后无法判断哪个设置起作用。
减少会议中断的维护与排障方法
稳定分流不是一次写完规则就永远不动。应用更新、订阅规则调整、网络切换和公司安全策略变化，都可能让原先有效的配置出现偏差。平时可以在重要会议前快速检查 Clash 是否运行、目标策略组是否选中可用节点、系统代理或 TUN 状态是否符合预期，并确认浏览器与会议客户端没有各自启用互相冲突的代理设置。若会议对稳定性要求很高，不要在会议进行中临时改规则或切换多个网络接管模式。
排查时按照「命中 → 节点 → 网络 → 应用」的顺序收敛问题。先看连接面板里目标请求的最终规则；命中错误就修规则顺序或域名范围。命中正确但仍失败，再切换同一策略组中的另一个节点，并观察失败是否随节点变化。若所有节点表现接近，测试有线连接或另一个可信网络，检查 Wi-Fi 丢包、路由器负载和企业 VPN。最后确认应用版本、账号状态、企业防火墙与会议服务状态。出现 401、权限不足或账号策略提示时，不要把它当成代理故障处理。
也要避免把安全与稳定性问题混为一谈。订阅链接、节点凭据和完整配置可能包含敏感信息，不要上传到公开的在线规则转换器，也不要在公开截图中暴露账号、内网域名或连接详情。企业设备应遵守单位对代理、数据跨境和终端安全的要求；未获许可时，不要通过更改 DNS、绕过受管网络或关闭安全软件来追求某一种网络路径。
常见问题
系统代理已经开启，为什么会议还是卡？
系统代理主要影响遵循 HTTP 代理设置的应用和连接，会议音视频可能使用 UDP 或独立网络路径。先检查连接面板中是否出现会议相关连接，再测试有线网络、节点负载和 TUN 是否适用于你的环境。若连接根本没有进入 Clash，仅增加域名规则通常不会改善媒体流。
要不要把所有 Google 域名都加入代理？
通常不建议。宽泛规则会连带改变搜索、云盘、办公套件和账号服务的网络出口，可能引入新的登录或企业访问问题。先从 Meet 实际失败时的连接记录确认具体主机，再添加最小必要范围；企业账号还应遵循管理员提供的网络要求。
怎样判断哪个节点最适合 Zoom？
先用延迟测试排除不可用节点，再在常用会议时段做实际语音、摄像头和屏幕共享测试。连续观察丢包、声音断续和画面冻结，记录同一网络下的结果。短时延迟低不代表上行稳定，也不能保证节点支持适合会议的 UDP 转发。
开启 TUN 后内网访问异常怎么办？
先关闭 TUN，恢复到之前能访问内网的模式，确认是否与企业 VPN、DNS 或虚拟网卡冲突。然后一次只调整一个路由或 DNS 设置；如果设备由单位管理，应联系网络管理员确认允许的接入方式，不要直接关闭安全组件或绕过策略。
有些只提供简单全局开关的代理工具，在远程办公场景里容易让国内门户、企业 VPN 与会议流量一起改变出口；而把所有域名都手动堆进一份规则，又会增加维护负担。Clash 的策略组、规则顺序和连接面板提供了更清楚的分流与核验路径：国内服务可继续直连，协作请求按需选择节点，异常时也能从命中记录定位问题。如果你希望在桌面端按本文思路管理配置，可以先了解适合自己平台的客户端与使用方式。