一、先把现象拆开：进会慢、共享失败、音视频断续不是一回事
进会慢通常发生在会议前：拉取会议配置、校验许可、下载会议资源或连接网关阶段，某些 HTTPS 请求长时间 pending 或反复 TLS 握手。此时你可能尚未看到视频画面，但任务栏里的 Zoom 已在疯狂建连。
共享屏幕失败更偏向带宽与上行路径：桌面编码、通过 Zoom 的媒体通道上传，对稳定 RTT与丢包比「能打开网页」敏感得多。若控制面走代理而媒体面直连，或相反，常见表现是对方看到你共享「卡住」或分辨率骤降。
音视频断续往往与 WebRTC 类UDP 媒体流、区域媒体节点以及 NAT 行为有关。仅开系统代理时，UDP 常常不会自动进 Clash；若信令与媒体出口 IP 不一致，服务器侧可能频繁切换中继，听感上就是卡顿与爆音。
把三类现象分开记录时间点，有助于判断该先补 Zoom CDN 分流 还是先开 TUN 统一 UDP。若尚未导入可用订阅或不清楚策略组名称，建议先完成《Clash 订阅链接怎么用？机场配置文件一键导入完整教程》，避免改的是未生效的配置副本。
二、两类根因：全量代理误伤，还是 CDN 与媒体链路未对齐
全量代理误伤指：Zoom 的部分主机名本应直连或走国内优化链路（例如部分落地页、企业 SSO 或本地会议控制器），却被一刀切送进海外节点，导致握手慢、证书链拉取慢或企业防火墙二次审查。另一类误伤是把所有流量直连，但你的网络环境访问 Zoom 边缘必须走代理，于是出现「浏览器里别的站点都通，唯独 Zoom 半通」。
CDN 与媒体链路未对齐则是更隐蔽的一类：zoom.us 主站与会议网关已走代理，而承载静态资源、插件或媒体边缘的另一组主机名仍 DIRECT，或落在与你节点地理不一致的地区。此时 UI 能打开，进会却卡在「连接中」，或视频能亮一两秒又掉帧。
判断是哪一类，核心证据是连接日志里同一秒内是否混用策略。若同一会议准备阶段既有 PROXY 又有 DIRECT，且 DIRECT 对应失败请求，就应把这些主机名并入与会议主链路同一策略意图，而不是继续换节点碰运气。
三、推荐排查顺序：先模式与日志，再 DNS，最后微调规则
下面顺序刻意把「换节点」放在中后段，先证明流量确实进了内核，且规则没有自相矛盾。
- 确认当前是系统代理还是TUN，以及 Zoom 是否被安全软件或公司策略设为「绕过代理」；必要时以连接日志为准。
- 复现进会慢时，在连接面板过滤
zoom、zoomus、cloudfront、awsglobalaccelerator等关键字（以你本地日志为准），观察每条连接的策略与远端地区是否一致。 - 单独复现音视频断续：关注是否出现大量 UDP、是否对特定 IP 段超时；若 TUN 未启用或内核未处理 UDP，应回到模式讨论而非继续堆域名。
- 检查 DNS：是否启用
fake-ip、海外域名的上游是否可达；解析与连接目标不一致时，优先调整nameserver-policy或等价字段（以所用 Mihomo 文档为准）。 - 把日志里失败或长时间 pending的主机名分为「会议控制与网页」「静态与插件 CDN」「媒体与实时」，再在规则中显式指向同一策略意图或你拆好的两组。
- 在规则顺序已合理的前提下，再为会议与共享分别选择延迟方差小、UDP 表现稳定的节点，避免对同一主机名过于激进的自动切换。
端口占用、订阅拉取失败等通用问题，可对照《Clash 常见报错解决方案》；本文只聚焦 Zoom Clash 场景下的多域名与实时流量。
四、Windows 上系统代理与 TUN：WebRTC 与 UDP 是否进了内核
仅开启系统代理时，遵循系统代理的应用会把 HTTP(S) 流量送到 Clash 的 mixed 端口；但UDP 媒体通常不会自动走 HTTP 代理端口。于是常见状态是：会议聊天或部分控制请求正常，视频与语音仍按系统路由表直连，与信令所见的「对外 IP」不一致，从而触发中继迁移或限速。
若你已确认「能加入会议但音视频极差」，可评估TUN 模式：在网卡层接管路由，使 TCP 与 UDP 更一致地经过内核分流。开启前建议阅读《Clash TUN 模式开启方法》，并在启用后回到连接日志，确认 Zoom 相关连接确实经 Clash 显示，而不是仍落在 DIRECT。
与站内《Windows 上 Discord 更新卡在 0% 且语音常掉线？用 Clash 分流 CDN 与 RTC 逐步修复》类似，核心差异是 Zoom 的主机名集合与客户端更新通道不同，但「信令 TCP + 媒体 UDP」拆分验证的思路一致：不要只盯着网页能否打开。
若你从 Microsoft Store 安装 Zoom 或依赖组件，且发现「浏览器已通、商店或 UWP 仍不走代理」，可另读《Windows 应用商店下载失败？用 Clash 为 UWP 开启回环代理完整步骤》，避免把 UWP 隔离误判成节点故障。新手也可先按《Clash Verge Rev 完整配置教程》跑通基础链路，再叠加本文的 Zoom 条目。
五、Zoom CDN 与控制面：进会慢时优先对齐主机名出口
加入会议时，客户端通常会请求会议元数据、许可与地区调度信息，并可能从多家CDN 边缘拉取脚本或插件。若 zoom.us 或企业网关类主机名已走代理，而实际承载资源包的边缘主机名被前置规则打成 DIRECT，就会表现为长时间停在「正在连接」或反复重试。
建议在复现时打开实时连接列表，按时间排序，关注长时间无响应或反复 TLS 握手的条目。若同一秒内既有代理命中又有直连命中，且直连侧对应下载或静态域，就应把这些主机名并入与会议控制相同的策略组，或单独建立 ZOOM_CDN 组并在规则里显式挂载。
与站内《Steam 商店与创意工坊打不开？用 Clash 分流 Steam CDN 与下载域名（实测步骤）》类似，核心思路都是以连接日志为准做 Zoom CDN 分流，而不是凭记忆堆后缀。Steam 与 Zoom 的主机名集合不同，请勿照搬规则条目，只借鉴排查顺序。
六、WebRTC 与屏幕共享：带宽、UDP 与「半代理」状态
会议中的音视频与共享桌面，除了依赖控制面请求，还依赖UDP 到媒体中继的稳定路径。若信令走代理而 UDP 直连，可能遇到运营商对 UDP 的限速或 NAT 类型不匹配，表现为断续、延迟抖动或共享画面定格。
在 Mihomo 系内核上，是否处理 UDP、是否对特定进程做绕过，取决于你的模式、策略与可能的进程规则。务实的做法是：先在日志里确认会议阶段的 UDP 连接是否出现、策略命中是否符合预期；若完全看不到 UDP 经内核，则说明流量仍绕开了当前模式，应回到上一节的 TUN 与系统路由讨论。
若你对传输协议与丢包特性不熟，可对照《Shadowsocks vs Trojan vs Hysteria2》，结合自身网络选择更抗波动的线路，再把 Zoom 相关规则挂到对应策略组。会议场景对「测速榜第一名但抖动大」的节点往往比网页更敏感。
七、域名怎么归类：以日志为准，表格仅作自检方向
Zoom 会调整边缘节点与主机名，任何静态清单都可能过期。下表给出排查时常见的分类方向，请始终以你本地连接日志与实际失败请求为准。
| 类型 | 常见主机名方向（示例） | 配置提示 |
|---|---|---|
| 主站与会议入口 | zoom.us、zoom.com、企业自定义域名 | 与登录、会议邀请链接保持同一策略意图，避免被宽泛「国内直连」误伤。 |
| 会议控制与 API | 日志中出现的 *.zoom.us、*.zoomgov.com 等方向 | 鉴权与会议配置常与进会速度强相关；半通时表现为能开客户端、进会卡住。 |
| CDN 与静态资源 | 日志中的云厂商边缘、具体下载主机名 | Zoom CDN 分流先加观测到的 DOMAIN，再考虑后缀，避免波及其他业务。 |
| 媒体与 WebRTC | 日志中的语音/视频中继、UDP 会话 | 与 TCP 规则分开验证；必要时为会议媒体单独策略组并选用 UDP 友好节点。 |
若你希望「浏览与进会」和「会议媒体」使用不同节点，可在 proxy-groups 中定义两个组，例如 ZOOM_WEB 与 ZOOM_MEDIA，再在规则里按主机名分别挂载。名称变更后务必保持 YAML 自洽，防止配置无法加载。
八、DNS 与 fake-ip：半通状态从哪里来
启用 fake-ip 后，解析阶段与连接阶段的一致性更依赖内核行为与规则顺序。Zoom 这类依赖大量子域与第三方边缘的产品，一旦部分请求在解析路径上不一致，就可能出现TLS 握手重试、资源长时间 pending 或进会进度假死。
务实的顺序是：先确认 DNS 上游本身可达、无污染；再考虑为 zoom.us、zoom.com 等后缀配置更明确的解析策略。若调整 DNS 后失败请求显著减少，说明瓶颈在解析链路，此时再微调 Clash 分流会更省力。
九、分流规则：示例片段（请替换策略组名）
下列 YAML 演示如何把常见 Zoom 后缀显式指向代理组。将 PROXY 换成你的策略组名，并保证片段位于过于宽泛的 GEOIP 或 MATCH 之前，且不与订阅自带的「国内直连」条目冲突。
# Example only — replace PROXY with your policy group name
rules:
- DOMAIN-SUFFIX,zoom.us,PROXY
- DOMAIN-SUFFIX,zoom.com,PROXY
- DOMAIN-SUFFIX,zoomgov.com,PROXY
- DOMAIN-SUFFIX,zoom.com.cn,PROXY对日志中出现的具体 CDN 主机名，按需追加 DOMAIN 规则。若某后缀与其他站点共用，则需权衡是否改用更窄的匹配或进程级规则（视内核与客户端能力而定）。媒体若主要体现为 IP 段而非域名，可能还需要结合路由与 TUN 文档中的高级选项，本文不展开具体内核开关，以免与版本差异冲突。
十、与订阅规则冲突时怎么收敛
许多订阅自带「国内直连、国外代理」的大块规则。Zoom 部分主机名可能被误判为应直连，或相反被错误地套进不适合的代理组。处理方式是：把 zoom 相关后缀写成靠前、更具体的规则，并在修改后观察连接日志是否整体统一到预期策略。
若你同时开启局域网共享给其他设备，注意网关与 DNS 是否一致指向运行 Clash 的机器，可参考《Clash 开启局域网代理：Windows 与 macOS 多设备共享完整步骤》，避免只有本机 Zoom 正常、旁路设备仍异常。
十一、节点选择：稳定与 UDP 表现优先于测速榜
进会与共享场景会并发大量短连接与长时 UDP。测速第一的节点未必适合后者：短时抖动会让媒体中继反复迁移，听感上就是断续与掉线。更稳妥的是选择一段时间内延迟方差小、UDP 丢包可控的线路，并避免对 Zoom 相关主机名过于频繁地自动故障转移。
十二、小结：把「卡顿」拆成可验证的主机名与协议清单
Zoom Clash 与 Windows 会议卡顿场景下的进会慢、共享失败与音视频断续，多数是模式、DNS、规则顺序、UDP 与节点稳定性叠加的结果，而不是单一坏节点。按本文顺序，你可以在连接日志里看到明确命中记录，再决定要不要为 Zoom CDN 分流 与 WebRTC 媒体分别建策略组。
当你希望少手写 YAML、用图形界面统一管理连接记录与策略切换时，成熟客户端在 Mihomo 内核上的整合度较高，也能降低配置错误率。相比零散工具组合，一体化体验在长时间会议与共享场景里往往更省心。→ 立即免费下载 Clash，开启流畅上网新体验