现象：能进会议室，音视频却像「第二条网」
很多用户会先这样描述：Zoom 或 Teams 能打开、能登录，甚至能打字、看别人共享的议程，但一旦开麦、开摄像头或共享屏幕，就出现延迟飙升、声音断续、对口型不同步，或本方有画面对方听不到。也有人遇到更隐蔽的情况：同一台电脑，浏览器里开会略好，桌面客户端却频繁重连；手机热点一换又正常。这类问题在搜索里常被简单归因为「视频会议被墙」或「专线质量差」，但若你能在同一条线路上流畅看网页、下文件，更值得优先怀疑的是：代理是否只覆盖了 TCP、而忽略了 UDP；或者会议相关的子域名没有落入你为办公流量准备的同一策略组。
从协议角度看，会议软件的账号体系、日历同步、许可证校验等往往主要依赖常规的 HTTPS（TCP）；而音视频 RTP、FEC、带宽探测以及 NAT 穿透，大量使用 UDP，并会通过 STUN 交换候选地址，在复杂网络下再落到 TURN 中继。Clash 要把这套链路收敛到一致的出口，既要让域名规则提前命中正确的策略组，也要让UDP真正走过代理内核——否则就会出现「一半流量听指挥、一半流量自作主张」的拼接感，听感上就是卡与无声。
下文步骤刻意不做并发大改**：一次只动一类变量（例如先确认 TUN，再补域名），方便你对照连接日志归因。若你与流媒体点播换区（只看 TCP、CDN 路径相对静态）对比，会议场景的UDP与候选地址协商要活跃得多，排查重心也应随之偏移。
第 1 步：分清桌面客户端走的是「系统代理」还是「漏出去的 UDP」
在 Windows 与 macOS 上，许多浏览器内的会议链接会遵循系统 HTTP 代理设置；而独立安装的 Zoom、Teams 桌面客户端往往会发起大量直连 UDP，或对本地 SOCKS/HTTP 端口的支持与版本有关。若你只开启了系统代理模式的 Clash，HTTPS 管控流量可能被接管，音视频UDP却试图绕过内核——这时你再怎么改域名列表，日志里也看不到预期的命中。
本步请先确认两件事。第一，当前使用的是系统代理还是已开启 TUN / 虚拟网卡 模式。TUN 能把更多TCP 与 UDP纳入策略链，桌面端会议软件尤其常见这一需求；具体差异可阅读Clash TUN 与系统代理说明。第二，在会议进行中打开客户端自带的连接信息（不同版本入口略有差异），观察是否在同一出口地区下仍有UDP相关的 NAT 类型异常提示；再结合系统资源监视器或 Clash 连接面板，判断音视频流量是否流经本地混合端口。
第 2 步（Zoom）：把会议与控制平面域名收敛到同一策略组
Zoom 的用户入口与 CDN 会涉及多条后缀：常见的如 zoom.us、zoom.com，政企场景可能还有独立域名体系；下载、参会邀请、会议室短链也可能分散在不同子域上。若你的规则只写了主站一条 DOMAIN-SUFFIX，而GEOIP-CN、国内直连或宽泛的流媒体规则插在更前，就可能把某些媒体或信令相关的子请求送去与主会话不一致的出口，表现为反复重连、单方无声或画面冻结。
建议为视频会议单独建策略组（例如 MEETING），在规则段靠前位置用多条 DOMAIN-SUFFIX 覆盖你已观测到的后缀，并统一指向该组。下面是示意 YAML，请务必按你的内核语法、订阅策略组命名与合规要求调整，切勿原样照搬：
# Example only — align proxy-groups names with your profile
rules:
- DOMAIN-SUFFIX,zoom.us,MEETING
- DOMAIN-SUFFIX,zoom.com,MEETING
- DOMAIN-SUFFIX,zoomgov.com,MEETING
- DOMAIN-SUFFIX,zoom.edu,MEETING
要点有三。其一，邀请链接、客户端更新检测与会话并不一定共用你最熟悉的那条后缀；应以日志里真实出现的目标主机名为准逐步补齐。其二，规则顺序要让上述条目在过于宽泛的 MATCH 或 GEOIP 之前命中。其三，若使用 Rule Providers，请核对远程规则集是否被本地更粗糙的条目覆盖或重复，写法细节见YAML 与 Rule Providers 指南。
第 3 步（Teams）：Microsoft 365、Azure 与企业策略的叠层
Microsoft Teams 与 Zoom 的「一个 App 一口锅」不完全相同：Teams 往往与 Microsoft 365、Azure、SharePoint / OneDrive 等生态共用身份与 CDN；企业租户还可能开启条件访问、IP 信誉、DLP等策略。若你把 microsoft.com 或 office.com 笼统地塞进「全量直连」或「全量代理」的某一极，而未把会议媒体与登录与管控放在可预期的一组里，容易出现「Outlook 能上、Teams 会中掉线」或「Web 能上、桌面端异常」的割裂。
排错时建议分层看需求：个人版与商用版终结点清单会随微软文档更新而变化，最稳妥的办法仍是在会议室故障复现窗口抓取 Clash 连接日志中的目标主机名，把未命中的后缀补进 MEETING（或你拆分的「办公协作」组），并确保该组的位置在过于宽泛的规则之前。若公司 IT 要求特定地区出口以通过合规检测，更应让会议信令与媒体与检测结果所依据的 IP一致，而不是只看网页能打开。
第 4 步：理解 STUN、TURN 与「媒体终结点」在日志里的长相
STUN（会话穿透实用工具）帮助客户端发现自己的公网候选地址；当UDP直连不理想或对端不可达时，流量可能转到 TURN 中继。TURN 服务器可能在第三方云域名或固定端口策略之下——这正是为什么说「只代理 zoom.us」往往不够：你看到的卡顿，有时是TURN 域名走了直连而与会话主体代理不一致导致的握手抖动。
操作上请在会议建立后的前一两分钟密集查看日志：筛选UDP连接与可疑的中继域名，把它们与你在第 2、3 步写入的策略组对齐。若你发现某些终结点落在巨型 ASN 或多云任意播上而难以用域名穷举，可以在确认合规的前提下，谨慎评估是否要用更细的规则集或与管理员核对企业允许的出口范围，而不是盲目添加宽泛的 IP 规则。
第 5 步：DNS、Fake-IP 与「解析对了、会话却歪了」
会议建立前，终端需要解析网关、配置与候选服务的地址。若你使用 Fake-IP 模式，本地返回的 IP 与后续规则命中、真实出口期望之间一旦出现偏差，就容易表现为长时间连接中或间歇性单方无声。请先对照Fake-IP 与 Redir-Host 专文，检查 fake-ip-filter、nameserver-policy 是否对会议相关后缀有合理分流，并在日志里核对解析出的目标是否仍命中你期望的策略组。
对于双栈（IPv4/IPv6）环境，还要注意：若IPv6 路径与IPv4 代理出口表现不一致，也可能让 RTC 抖动得比网页加载更明显。可在理解对国内业务的影响后，做一次受控对照（例如暂时统一栈或收窄异常路径），再结合连接日志判断是否属于「解析/栈」问题而非「节点质量问题」。
第 6 步：确认 UDP 转发与内核、节点能力一致
RTC 依赖 UDP 承载实时媒体。若代理组或节点未开启 UDP、或本机防火墙、企业终端安全软件丢弃/重写了相关报文，就会出现无声、单向有声、延迟跳变。请在 Clash 系客户端中查看对应策略组是否允许 UDP（界面可能写作 UDP Relay、UDP 转发等）。若使用 Clash Meta（mihomo），也请核对内核版本与菜单项一致，可参考Meta 内核升级教程，避免出现「选项能点、内核实际未处理」的落差。
同时避免与另一套全局 VPN或游戏加速器并发劫持路由表：两套隧道争抢默认路由时，UDP 往往最先表现出抖动，却最难从单一应用的报错里一眼看穿。
第 7 步：用连接日志交叉验证「谁在走错出口」
最后一步是把主观体验落到可观测证据上：在会议的高峰时段过滤Zoom / Teams 相关主机名与UDP条目，确认它们持续命中你为会议准备的策略组，而不是落到 DIRECT、意外的默认节点或与你登录身份不符的地区。若文字频道阶段日志干净，音视频阶段突然出现大批量对不同 ASN的新连接，多半仍有子域或中继域名未纳入细则——回到第 2～4 步补齐。
与视频会议分流相邻的场景里，Discord 语音同样重度依赖 UDP 与网关域名；排查套路高度相似但域名清单不同，可参考本站Discord RTC 分流专文对照阅读，避免把两套应用的问题混为一谈。
常见误区：为什么「换节点」仍然卡
会议卡顿时，很多人的第一反应是反复切换国家或供应商。这在「出口 IP 被服务端拒绝」类问题里往往有效；但若根因是UDP 未进代理、策略组不一致或TURN 与主会话 split，换十个节点也可能听感相同。另一个误区是把全局模式当万能药：全局会让更多流量走代理，也可能把本应直连的局域网或国内加速域名一并送走，引入新的延迟源，反而让日志更难读。
也有人只关注「能打开会议首页」而忽略媒体期才出现的独立主机名：它们在会议开始几十秒后才大量出现，若你只在空闲时翻日志，会误以为「规则已经够用」。建议在真实开会、开麦、开摄像头的重载下取样。最后，室友或同事共用路由器时，QoS、家长控制或运营商侧对 UDP 的限制，也会让问题看起来「像代理的锅」——先用有线网络与单一设备单一隧道固定变量，再讨论节点才更省时。
对照表：七步里该盯什么
把下表当作现场排错速查：从上到下对应前文步骤，便于你向 IT 同事或远程队友一句话说清「可能卡在哪一层」。
| 步骤 | 核心检查点 | 若忽略会怎样 |
|---|---|---|
| 1. 路径 | 系统代理 vs TUN；桌面端 UDP 是否进 Clash | HTTPS 正常、音视频走旁路 UDP，易无声与断流 |
| 2～3. 域名 | Zoom/Teams 与 M365/Azure 后缀同组；规则顺序 | 信令与媒体出口不一致，握手抖动 |
| 4. STUN/TURN | 日志中的中继域名与主会话策略一致 | 穿透失败或频繁切候选，画面卡 |
| 5. DNS | Fake-IP、双栈与会话命中是否一致 | 连接中过久、间歇性单方无声 |
| 6. UDP | 代理组 UDP、内核与防火墙放行 | 媒体面直接崩或单向通 |
| 7. 日志 | 会议重载期的主机名与策略组命中 | 漏网子域长期难发现 |
写在最后：验收「能进会」与「能稳开麦」是两件事
Zoom、Teams 的登录与日程，和实时音视频并不是同一条管道：前者更容易被传统代理覆盖，后者强依赖 UDP、STUN/TURN 与完整的域名与出口一致性。在 Clash 中把企业会议相关后缀与观测到的媒体终结点纳入同一策略组、在需要时用 TUN 把桌面端流量与 UDP 纳入策略、再对照 DNS 与连接日志验证命中，你就能系统化地处理「无声画、卡顿」，而不是在同一节点上无效循环。相比仅调全局开关，Clash Meta 生态在规则表达与可观测性上一致性更好，熟练后视频会议分流的维护成本会明显下降。
若希望在一个入口获取各平台客户端并维护订阅链接，减少版本与配置来源混乱，可从我们的下载中心选择适合自己系统的发行版，把精力留给真正的策略与验收。
更多内容可继续浏览技术专栏中的 DNS、YAML 分流与 Discord 语音等专题，把「订阅 → 模式 → 规则 → TUN/UDP」串成完整闭环。