本文面向使用 Shadowrocket（小火箭）处理远程办公流量的用户，说明怎样为 Zoom 与 Teams 会议筛选连接、确认 UDP 条件，并在 Config 中添加范围有限的域名规则。会议质量还取决于 Wi-Fi、蜂窝网络和服务端状态；配置后应使用实际会议功能复测，而不是只看一次延迟数字。以下操作以用户已有自己的订阅和连接资料为前提。
先判断会议问题出在网络哪一段
视频会议包含登录、信令、音视频媒体和屏幕共享等不同请求。网页能打开、账号能登录，只说明部分访问正常，不代表实时语音和视频链路也稳定。音频断续、画面冻结、加入会议慢、共享屏幕卡顿，可能对应不同环节；若一开始就不断切换节点和规则，很难知道哪项调整真正有效。
建议先记录会议发生时的网络类型、Shadowrocket 连接状态、Global Routing 模式、所选连接，以及 Zoom 或 Teams 显示的具体现象。若同一会议在关闭 Shadowrocket 后恢复正常，可能是当前代理路径、规则或 UDP 转发存在差异；若直连和代理都不稳定，则还需检查无线信号、网络拥塞、设备负载或会议服务状态。公司网络还可能施加访问策略，不能把所有限制都归因于客户端配置。
在 Home 确认连接确实已建立，再检查 Global Routing。需要按规则分流时，使用 Config，并确认 Config 页面选中的文件就是当前要测试的配置。Proxy 会改变流量处理方式，可用于短时对照；Direct 则用于观察目标在当前本地网络下的访问表现。对照时尽量保持设备、会议账号、地点和网络不变，每次只改一项。
- 只有登录或加入会议失败：先确认对应域名请求是否被规则送往预期策略，并查看是否有账户验证或组织策略提示。
- 语音、视频断续：优先测试 UDP 能力、网络丢包与 Wi-Fi 信号，不要只依据 Home 中的连接延迟判断。
- 屏幕共享卡顿：减少并行上传和下载，再比较同一网络下的共享表现；共享所需带宽与延迟条件可能不同于普通网页加载。
筛选连接：低延迟只是初筛条件
在 Home → Connectivity Test 对已有连接进行比较时，固定测试方式与网络类型。先用 Wi-Fi 测试就不要中途切到蜂窝网络；测试期间暂停云盘同步、系统更新和大文件传输。对少量候选各测三次，记录成功、超时和波动，而不是只抄下最低一次结果。不同测试目标或测试方式所得数字不宜直接放在一起排序。
测试通过后，再选中候选连接并重新建立会议应用的新请求。已经存在的会议或长连接可能继续沿用先前路径，不能仅凭切换连接后的旧会议判断新配置。比较时关注实际加入用时、音频是否连续、视频是否反复降质，以及屏幕共享能否持续，而不是只看某次测速数字。
实时会议还需要核对 UDP。部分协议或服务端配置可能支持 UDP 转发，部分则可能不支持，或只在特定配置下可用。Shadowrocket 能否把 UDP 请求交给当前连接，取决于连接协议和服务端能力；应用界面中的连接已建立，并不能单独证明会议媒体正通过 UDP 正常转发。应查看现有连接资料或服务说明中的 UDP 支持情况，不确定时向自己的服务商确认，不要通过猜测端口或随意添加规则来代替核验。
-
固定测试网络
先选 Wi-Fi 或蜂窝网络中的一种，记录网络名称或信号情况。暂时停止大文件传输，避免背景流量让候选比较失去一致性。
-
比较候选连接
在 Home → Connectivity Test 使用同一种测试方式，对少量已有连接分别重复测试三次。记录超时和波动，不只保留最低延迟。
-
确认 UDP 条件
核对当前连接协议及服务端是否支持 UDP 转发。若资料没有明确说明，先向自己的服务商确认，不把“连接开关已打开”当作 UDP 可用的证据。
-
验证实际会议
选中一个候选并新建会议或重新加入，测试语音、摄像头和屏幕共享。一次只换一个候选，保留每次结果与网络类型。
低延迟但 UDP 不通、丢包明显或高峰时段波动大的连接，可能不适合实时会议。相反，延迟略高但连续性更好的候选，实际通话体验可能更稳。把延迟看作筛选指标，而不是会议质量的保证；最终以自己的会议应用、时间段和网络环境复测结果为准。
按 Zoom 与 Teams 域名分流
要让会议相关请求按预期走代理，应在 Config 当前生效的配置中检查规则，而不是只在 Home 选择连接。域名规则的策略名称必须对应当前配置中实际存在的策略；示例中的 PROXY 是常见写法，如果配置使用策略组或其他名称，应替换成已有且正确的策略。规则按顺序匹配，范围更具体的规则应放在可能覆盖它的宽泛规则之前。
下面只展示规则结构和可能涉及的服务域名，不能视为 Zoom 或 Teams 的完整域名清单。服务端点会因功能、账户、组织设置和服务调整而不同。规则未命中时，还会受后续规则及 FINAL 的处理影响；添加规则后应在 Data 或可用的请求记录中确认目标请求实际命中了哪条规则。
[Rule]
DOMAIN-SUFFIX,zoom.us,PROXY
DOMAIN-SUFFIX,zoom.com,PROXY
DOMAIN-SUFFIX,teams.microsoft.com,PROXY
DOMAIN-SUFFIX,teams.live.com,PROXY
FINAL,DIRECT这是帮助理解匹配方式的示例，不是可直接套用于每个组织的完整配置。请先确认自己的配置确实有名为 PROXY 的策略，并留意已有规则是否在前面处理了这些域名。若原文件的 FINAL 不是 DIRECT，不要为了复制示例而改写兜底策略；保留原有行为并针对目标请求逐项验证。
- 先处理明确的服务域名。对照请求记录或组织提供的信息，确认会议相关请求使用了哪些域名，再添加精确范围的规则。不要把看到的登录域名直接扩大成所有 Microsoft 域名。
- 谨慎处理共享域名。
microsoft.com、office.com等宽泛后缀可能覆盖其他工作服务。把它们整体交给代理，可能改变邮件、文件和组织登录等非会议请求的路径。 - 不要把域名规则当成端口规则。
DOMAIN-SUFFIX按域名后缀匹配，不会因为会议使用某个网络端口就自动检查 UDP 转发是否可用。 - 修改后重新发起请求。保存配置后重新加入会议，检查新请求的匹配结果；修改前建立的长连接可能不会立即采用新规则。
如果规则命中了预期策略，但媒体仍不稳定，应回到 UDP、丢包和网络限制继续排查。如果没有命中，逐条检查域名拼写、规则顺序、当前启用的 Config 文件和 Global Routing 状态。不要一次加入大量来源不明的域名，也不要把“登录成功”当作音视频域名已正确分流的证明。
开会前测试：分别处理蜂窝网络与公司 Wi-Fi
会议开始前预留几分钟，使用平时会用的网络和账号完成一次实际测试。最好让测试包括加入会议、双向语音、打开摄像头和短暂屏幕共享。只打开 Zoom 或 Teams 首页，无法验证实时媒体是否正常；只运行延迟测试，也不能确认会议全程不会中断。
Wi-Fi 下网页正常，会议还是断续怎么办？
保持同一 Wi-Fi，在 Home → Connectivity Test 比较现有连接，并确认当前连接是否支持 UDP 转发。再新建会议测试语音和视频；若 Direct 与 Config 表现不同，检查实际命中的规则和连接路径。
公司 Wi-Fi 连接成功却无法加入会议？
先确认公司网络是否要求门户认证、设备登记或特定 VPN 使用方式。若组织限制 UDP 或代理流量，不要绕过管理策略；请网络管理员核对允许的会议访问方式，再按获准条件测试。
切到蜂窝网络后声音变好了，接下来查什么？
记录 Wi-Fi 和蜂窝网络下的连接、路由模式与会议表现，再逐项对照。检查蜂窝数据是否允许目标应用使用，并留意信号变化、数据限制和后台下载；不要只凭一次切网结果改动整份配置。
Zoom 能开会，Teams 却无法连接吗？
两项服务可能使用不同的域名和组织访问策略。分别查看失败请求与规则命中情况，只为确认过的目标添加规则；不要因一个服务正常就推断另一个服务也使用相同域名和路径。
使用蜂窝网络时，确认设备没有关闭会议应用的蜂窝数据权限，并观察信号是否稳定。若在 Wi-Fi 与蜂窝网络之间切换时连接状态发生变化，应重新发起会议请求，避免旧会话造成误判。公司 Wi-Fi 则应尊重组织的网络与设备管理要求；遇到认证页面或明确的访问限制，先按公司流程处理，不能将受限网络视为需要强行绕开的故障。
测试结束后保留一份简短记录：日期和时段、Wi-Fi 或蜂窝网络、Global Routing、所选连接、UDP 支持确认结果，以及会议中的具体表现。下一次只调整一项并复测，就能判断变化来自连接、规则还是接入网络。若改动后出现更差结果，恢复刚才记录的原值，避免叠加多个未经验证的设置。
结论：会议稳定性要用真实通话验证
先用重复测试缩小候选，再核实 UDP 条件和规则命中，最后在目标网络里实际测试语音、视频与共享。低延迟、连接开关已打开或网页能访问，都不能单独证明 Zoom 与 Teams 的会议媒体链路稳定。
需要核对 Shadowrocket 各平台获取方式时，可查看下载页；需要继续熟悉已有连接的导入和基本操作，可查看教程。客户端本身与用户的网络服务是不同项目，本文的测试和规则设置均以用户已有自己的连接资料为前提。