远程办公时，先分清会议、协作与国内访问
在居家办公网络中，Zoom、Google Meet、Slack 和国内网站并不是同一类流量。视频会议需要稳定的实时传输，聊天与文件协作更依赖登录、消息同步和附件下载，而国内办公平台、网银或本地服务通常希望保持直连。把所有流量一股脑设为全局代理，可能让会议请求走到不合适的地区，也可能增加国内网站的绕行延迟；全部直连则可能导致部分服务无法正常访问。Clash 的实际价值，是让不同目标按域名和规则进入明确的策略组，再用连接日志核实流量是否真的按预期走。
会议稳定不等于测速页面显示的延迟最低。一次通话会持续传输语音、视频和屏幕共享数据，短时丢包、抖动、节点拥塞以及本地 Wi-Fi 干扰，都可能让画面冻结或声音断续。即使网页能打开，也不代表实时媒体链路稳定。Zoom 和 Google Meet 会依据网络状况选择传输方式；在部分网络环境里，媒体流可能使用 UDP，遇到防火墙、代理节点或客户端不支持的情况时，也可能回退到其他传输方式。因此，选节点时应同时关注连续通话表现、丢包和抖动，而不是只比较一次延迟测试。
还要留意「浏览器能用」与「桌面客户端能用」并不总是等价。Clash 的系统代理通常接管遵循系统 HTTP/HTTPS 代理设置的应用，但有些桌面程序会使用自己的网络栈，或者直接发起 UDP 请求；TUN 模式则可在更底层接管系统流量，但会改变更多网络路径，也更容易与公司 VPN、终端防护或虚拟网卡冲突。排查时先确认具体应用是否出现在 Clash 的连接列表，再决定是否需要调整模式，避免一开始就同时改规则、端口和 TUN 设置。
为 Zoom、Google Meet、Slack 与国内网站规划分流
建议先建立清晰的策略意图，而不是把大量域名直接堆进一条规则。可以在配置中使用类似 MEETING、COLLAB 和 DIRECT 的组名：会议相关流量交给适合实时通信的节点，Slack 及其协作资源交给可稳定访问的出站，国内网站则优先直连。实际名称不必照抄，关键是能从策略组名称看出用途，发生异常时也能迅速在界面中切换。
Zoom 的客户端、网页和会议媒体不一定只访问一个主机名；Google Meet 也可能依赖 Google 账户、网页资源、媒体服务和相关 API。Slack 同样涉及工作区、消息、文件及静态资源等不同请求。规则覆盖范围会随着客户端版本、地区和组织设置变化，不能把某个网上流传的域名清单视为永久完整。更稳妥的做法是先使用自己配置中已有的规则集，再通过 Clash 连接日志观察实际请求；发现某个必要域名走错策略时，才添加粒度适当的规则。
规则类型也需要选对。对服务域名使用 DOMAIN-SUFFIX，通常比把零散子域逐条硬编码更容易维护；但不应为了省事，把整个 google.com 或其他大型服务商域名都送进同一个代理组。宽泛规则可能同时影响搜索、云端文档、登录和其他并非本次会议所需的服务。对于跨服务共享的域名，应结合日志和实际需求判断；能使用可靠、持续维护的规则集时，优先采用规则集并保留必要的本地覆盖。
国内办公门户、视频会议以外的本地服务以及通常可直连的国内网站，可以由现有国内规则集处理，或在明确需要时设置直连规则。避免在规则列表前部添加过宽的关键词规则，否则类似域名可能被意外匹配。Clash 规则一般按顺序匹配，较具体的例外应放在会抢先命中的宽泛规则之前；文件末尾还应保留适合当前配置的兜底规则。修改前先备份原配置，并确认客户端实际加载的是你编辑的那份配置。
节点选择应围绕工作地点和实际会议对象进行测试。离你较近的节点不一定拥有更好的跨境链路；距离较远的节点也可能因线路质量较好而更稳定。优先测试少量候选节点，观察同一场会议中声音、画面与屏幕共享是否持续稳定，同时确认节点是否支持所需的 UDP 转发。若会议只能连接但媒体质量明显下降，不要只盯着网页测速结果，也要检查连接日志、节点状态及当前客户端的代理模式。
桌面端动手配置：备份、分组、验证
下面的流程适用于 Clash Verge、Clash Verge Rev、Mihomo Party 等使用 Mihomo 内核的桌面客户端。不同版本的菜单名称可能不同，但核心步骤一致：确认当前配置、建立或选择策略组、添加必要规则、切换出站并验证连接。若配置完全由订阅更新覆盖，直接修改订阅生成的文件可能只在本次运行中生效；先确认客户端提供的覆写、规则补丁或本地配置管理方式，再决定把变更放在哪里。
- 确认当前配置与运行状态。在客户端检查当前激活的配置、内核是否正常运行，以及系统代理或 TUN 当前是否开启。先记录原来的模式和关键策略组，复制一份配置作为回滚备份。若同时运行公司 VPN、其他代理客户端或安全软件，记下它们的状态，以免后续把冲突误判为规则问题。
- 准备会议与协作策略组。在 Proxies 或配置编辑器中找到现有代理节点和策略组。优先复用订阅已经提供的自动选择、手动选择或延迟测试组，再为会议和协作流量设置清楚的路由目标。若新增组，必须确保组内引用的节点名与配置中的实际名称完全一致；不要仅凭客户端卡片上的显示文字猜测 YAML 中的节点标识。
- 按实际域名添加规则。从 Zoom、Google Meet 或 Slack 的连接日志中记录相关请求，先判断它们命中了哪条规则，再把确认需要改变出站的域名加入规则。示意结构如下，策略组名称应替换成配置中真实存在的名称，域名也应以你自己的日志及规则集为准：
规则结构示意
rules:
- DOMAIN-SUFFIX,example-meeting.com,MEETING
- DOMAIN-SUFFIX,example-collab.com,COLLAB
- DOMAIN-SUFFIX,example.cn,DIRECT
- MATCH,PROXY这段示意配置不是可以原样套用的完整域名清单；其中的示例域名需要替换，最后一条兜底策略也要与现有配置保持一致。如果配置已包含同类规则，不要重复添加。加入规则后检查缩进、逗号分隔和策略组拼写，再通过客户端的配置检查或重新载入功能确认内核能够解析。
- 先验证浏览器，再验证桌面应用。在规则模式下打开目标服务的登录页或会议入口，观察连接日志是否显示预期规则和出站。随后分别启动 Zoom、Meet 或 Slack 客户端，尝试登录、加入测试会议、发送消息和下载一个小附件。每次只测试一个应用，便于把新增连接与当前操作对应起来。
- 只在有依据时切换系统代理或 TUN。如果浏览器命中规则而桌面应用没有相关连接记录，先检查该应用是否遵循系统代理、是否有独立的代理设置，以及连接是否被其他网络组件接管。需要尝试 TUN 时，一次只调整一个设置，并确认公司 VPN、局域网打印机和内部办公系统仍可访问。测试后及时恢复不再需要的模式。
用通话结果和 Clash 日志定位故障
验证不要只做「网站能不能打开」这一项。至少分别检查入会、双向语音、摄像头画面、屏幕共享以及 Slack 消息和文件传输。会议开始前短暂测试只能发现明显故障，无法代表长时间通话表现；最好在相近的时段进行一段持续测试，并留意丢包、抖动、音画不同步和反复重连。若问题只在屏幕共享时出现，可能涉及额外的媒体连接或本地上传带宽，不宜简单归因于网站主域名规则。
打开 Clash 的 Connections 或日志面板，在重现故障的同时观察新连接。重点核对请求域名、命中的规则、出站策略和连接状态：若必要请求命中直连而应走代理，先修正规则顺序或匹配范围；若已经走到预期策略组，但节点连接失败或频繁重连，再测试另一个节点并查看内核日志。连接记录中的域名可能受到 DNS 解析、嗅探能力和客户端行为影响，未显示完整域名时不要贸然新增大范围规则，可先用客户端诊断信息和实际失败时间缩小范围。
会议质量差时，也要排除代理之外的变量。使用无线网络的设备可能受到路由器拥塞、信道干扰或弱信号影响；云端会议会同时占用上行带宽，家庭成员上传文件也可能拉高排队延迟。可暂时改用网线或靠近路由器测试，暂停其他大流量任务，并确认操作系统没有启用另一个 VPN。若只有某一个节点表现差，而直连或其他节点正常，应优先比较出站线路；若所有节点都相似，则应继续检查本地网络和运营商链路。
规则更新后如果仍出现异常，先确认客户端确实重载了刚才修改的配置，而不是仍在使用旧配置或另一个 Profile。可以逐条检查规则是否位于兜底规则之前、组名是否拼写一致、域名后缀是否过宽，以及订阅刷新是否覆盖了本地改动。排障时每次只调整一个变量，并保留前后日志与测试结果；这样即使回滚，也能知道是哪一项改动影响了会议或国内访问。
远程办公的分流目标不是让所有请求都绕远路，而是在会议稳定、协作服务可用和国内网站快速直连之间取得可验证的平衡。相较于只能统一设置系统代理、缺少规则日志的简易代理工具，Clash 配合 Mihomo 内核能提供可观察的规则命中、策略组切换与连接记录；不过它也需要你根据实际网络维护配置，不能替代公司网络政策或终端安全要求。如果你希望用桌面界面管理配置并按本文思路逐项验证，可以前往下载 Clash V.CORE，再从规则模式和少量必要的分流规则开始。