本文速览

远程办公时，Zoom 或 Teams 会议卡顿，不一定是节点延迟高，也可能与丢包、网络切换、UDP 转发或分流规则有关。本文适合已有自己的订阅、需要在 Shadowrocket 中调整会议连接的 iPhone / iPad 用户：先比较已有节点的实际表现，再核查 UDP 条件，最后用小范围规则和真实会议做验证。规则示例仅供理解语法，不是完整服务域名清单。

一、先确定问题出在什么环节

视频会议的“卡”可能表现为接入会议慢、声音断续、画面冻结、共享屏幕延迟，或会议中途掉线。不同现象对应的排查方向并不相同：接入慢可能与域名解析或连接建立有关；声音断续、画面冻结更需要关注实时链路的稳定性；切换 Wi-Fi 与蜂窝网络时掉线，则应重点观察网络切换和隧道重连。

先记录会议发生时的网络类型、Shadowrocket 连接状态、当前节点、Global Routing 姿态，以及 Zoom 或 Teams 显示的连接质量信息。若使用公司管理的设备或网络，也应遵循组织的 VPN、代理和数据安全政策；不要为绕过管理策略而改写办公流量路由。

二、筛选已有节点：关注稳定性，不只看延迟数字

只从用户自己已有的订阅条目中挑选候选节点，不需要为测试另行更换订阅。先在相同网络环境下，对几条当前可用的候选连接分别执行 Shadowrocket 提供的延迟或连通性测试；若界面显示的测试项目因版本或配置而不同，以设备实际显示为准。单次结果容易受瞬时网络状况影响，适合把测试分成几轮观察，而不是只选一次数字最低的条目。

比较时应尽量保持手机位置、Wi-Fi 或蜂窝网络、Global Routing 姿态和测试时段一致。记录各候选节点的响应时间、是否超时，以及连续测试结果是否大幅波动。Shadowrocket 显示的延迟只反映该测试请求的表现；如果测试没有报告丢包或抖动，就不能把这些指标推断为零。

3 类观察
响应时间、超时情况、连续结果波动
2 种网络
Wi-Fi 与蜂窝网络分开记录
1 项变量
每轮只改变节点或网络等一项条件

延迟较低但结果时好时坏的节点，不一定适合长时间会议；延迟略高但连续表现平稳的节点，有时更适合作为候选。最终应以真实会议中的声音连续性、画面表现和会议应用提供的连接质量信息判断。会议期间还要留意本地 Wi-Fi 信号、其他设备的大流量传输和系统网络切换，这些因素不由节点测试结果涵盖。

判断：把节点测试当作筛选，不当作会议保证

先排除频繁超时或响应波动明显的候选，再用实际会议验证剩余选择。不要把一次低延迟结果直接等同于 Zoom 或 Teams 的稳定通话能力。

三、核查 UDP：确认路径支持，再观察实际通话

实时音视频可能使用 UDP 传输媒体数据，但实际采用的传输方式会受到会议应用、网络环境、组织策略及服务端条件影响，也可能发生回退。仅凭 Shadowrocket 已连接、网页能打开，不能确认会议媒体流一定通过 UDP 正常传输；反过来，单凭通话卡顿也不能断定 UDP 被阻断。

先核实当前使用的节点和服务端是否支持并允许 UDP 转发，再查看公司网络是否限制相关实时通信流量。如果服务商提供连接参数说明，以其对当前节点的说明为准；如果办公网络由组织管理，则向网络管理员确认会议所需的网络策略。不要将未经核实的端口或网上找到的整段规则直接加入 Config：Zoom 与 Teams 的服务地址和网络要求可能随产品、租户及部署方式变化。

按网络归属选择排查方向

个人网络
  • 核对已有节点的 UDP 转发说明
  • 分别测试 Wi-Fi 与蜂窝网络
  • 记录会议应用的连接质量提示
公司网络
  • 先确认组织允许的代理与 VPN 使用方式
  • 询问会议流量是否有专门策略
  • 不要自行扩大规则或开放网络范围

UDP 是否可用需要结合服务端说明、当前网络策略和真实会议表现核对，应用内连接已建立并不等于媒体传输条件已满足。

如果可以加入会议但音频断续，先在同一设备、同一网络下对照不同候选节点，并观察会议应用自己的连接质量信息。若切换到另一网络后问题明显改变，应优先查网络路径或组织限制，而不是立刻扩大规则范围。测试期间避免同时开启大文件上传、云同步等任务，以免把带宽竞争误判为节点故障。

四、配置会议分流：从精确目标开始，不要整类服务一概代理

需要按规则分流时，在 Home → Global Routing 确认选择的是 Config，并检查 Config 页面当前启用的文件。Global Routing 的 Proxy、Direct 与 Config 是不同路由姿态：Proxy 和 Direct 用于全局处理，Config 才会按当前配置中的规则判断。若正在使用其他姿态，新增规则可能不会按预期参与当前流量处理。

Zoom 与 Teams 可能涉及多个域名、媒体服务地址和动态连接目标。只添加一个域名后缀，不能保证覆盖该服务的全部会议流量；把整个 Microsoft 相关域名范围都设为代理，也可能改变邮件、登录、云文件或其他办公服务的路径。应优先根据组织的官方网络要求和 Shadowrocket 的连接记录，确认实际目标，再逐条决定策略。

[Rule]
DOMAIN-SUFFIX,zoom.us,PROXY
DOMAIN-SUFFIX,teams.microsoft.com,PROXY

上面的两行只用于说明规则格式，不能当作 Zoom 或 Teams 的完整域名清单，也不代表所有环境都应使用 PROXY。应确认目标域名确实出现在本次会议连接中，并核对当前配置中 PROXY 对应的出站可用。若组织要求会议流量直连，则应遵循组织策略，而不是照搬示例。保留现有的其他规则与 FINAL 策略，不要为了测试整段替换 Config。

配置规则并不能单独保证 UDP 媒体流使用指定线路。规则主要决定符合条件的连接如何处理；节点的 UDP 转发能力、网络允许情况以及会议应用实际采用的传输方式仍需分别确认。若公司的办公政策规定特定流量必须走指定网络，应以管理员提供的准确目标和策略为准。

五、按步骤完成一次可回退的会议测试

正式修改前，保存当前配置副本，记录 Home → Global Routing 的选择、正在使用的 Config 和候选节点。测试时保持会议账号、设备位置和网络条件尽量一致；不要在一次对照中同时改变规则、节点、网络和会议应用设置。

  1. 记录当前状态

    在 Home 记下当前节点与 Global Routing 姿态；在 Config 确认当前启用的文件。另记 Wi-Fi 或蜂窝网络、会议异常现象和发生时间，避免凭记忆比较。

  2. 比较候选节点

    在相同网络下测试已有的候选节点，记录 Shadowrocket 显示的响应时间与超时情况。测试结果只用于初筛，不将它当作丢包或会议质量报告。

  3. 确认 UDP 条件

    核对自己使用的服务端是否支持 UDP 转发；公司网络用户同时确认组织对会议流量的要求。条件不明确时，先向对应的服务提供方或网络管理员核实，不猜测端口。

  4. 添加单条规则

    在 Config 中仅针对连接记录或组织文档已确认的目标调整一条规则，保存后确认 Home → Global Routing 仍为 Config。先不扩大到整个办公服务域名范围。

  5. 重新发起会议

    退出当前会议并重新加入，观察音频、视频、共享屏幕和应用显示的连接质量；再核对连接记录中的目标与策略是否符合预期。已有连接可能不会因规则保存而改变，重新建立连接有助于验证新设置。

  6. 单项调整并回退

    若表现没有改善，先恢复最近一条规则，再只换候选节点或只换网络做对照。把出现变化的条件记录下来，避免连续叠加修改后无法定位原因。

六、仍然卡顿或掉线时，按现象缩小范围

测试完成后，不要只用“能不能打开网页”判断会议设置是否成功。浏览网页与持续传输音视频的网络特征不同；更可靠的对照是在类似的会议场景下，观察声音连续性、画面冻结、共享屏幕延迟和会议应用自身的网络提示。若问题只在会议高峰时段出现，也应考虑本地网络拥塞或组织网络负载。

延迟测试很低，会议还是卡怎么办？

重新加入会议，查看应用内连接质量，并核对同一时段的网络是否稳定。延迟测试不等于丢包、抖动或 UDP 媒体测试；再用另一条已有候选节点进行单变量对照。

Shadowrocket 显示已连接，就代表 UDP 正常吗？

不代表。先确认当前节点支持 UDP 转发，再结合组织网络策略和实际会议表现判断；不要仅凭隧道状态推断媒体流传输方式。

加了 Zoom 或 Teams 规则，为什么没有变化？

先确认 Home → Global Routing 为 Config、编辑的是当前启用的配置，并检查连接记录中的目标是否命中该规则。目标可能不同于示例域名，也可能被前面的规则先行匹配。

如果换网络后会议恢复，而节点和规则保持不变，优先排查原网络的限制、信号质量或拥塞；如果只有特定节点出现问题，记录对应的测试时间和现象，再核实该节点的连接条件。若公司网络要求特定配置，不要自行持续扩大代理范围，应把必要的时间、网络类型和错误表现提供给组织管理员，并避免分享包含账户凭据或订阅信息的记录。

完成排查后，保留已验证有效的最小改动，并删除不再需要的临时规则。远程会议稳定性来自节点、UDP 条件、规则匹配、网络质量和会议服务策略共同作用；逐项核对并保留回退路径，比一次性改动多个设置更容易找出真正原因。