远程会议卡顿不一定是节点速度不足，也可能来自 Wi-Fi 丢包、公司网络策略、规则误分流或 UDP 媒体通道受限。本文以 Shadowrocket 的 Config 分流为主，说明 Zoom、Teams 的连接特点、规则配置思路，以及如何分别在 Wi-Fi、蜂窝网络和公司网络中做对照测试。操作以用户已有自己的订阅和可用配置为前提；订阅地址从你的服务商处获取。
一、先判断是会议问题还是整条网络问题
会议开始前先用同一台设备做基线检查：关闭 Shadowrocket 连接，在当前网络打开一个平时可访问的网页，再进入 Zoom 或 Teams 测试音频、摄像头和屏幕共享。若网页也打不开，或系统提示 Wi-Fi 需要登录，应先处理本地网络；此时反复换节点或改规则，不能证明代理配置有问题。
会议中记录具体症状，而不是只记“卡”。声音断续、画面冻结、共享屏幕延迟和无法加入会议，可能分别对应丢包、抖动、带宽不足、DNS 解析或认证访问问题。若只有摄像头画面不流畅，先确认设备性能、上行带宽和其他应用占用；若会议加入页面都无法打开，再检查域名解析和规则命中。
延迟测试的单个数字不能代替真实会议。可以把丢包接近 0%、抖动较低且稳定作为排查目标；例如丢包持续超过约 1%、抖动达到数十毫秒，或延迟在会议期间明显跳变，都值得进一步检查。但这些是便于比较的经验观察值，不是 Zoom 或 Teams 对所有会议场景的统一保证。更重要的是在相同地点、相同时间段，用相同会议功能比较网络结果。
- 先记网络状态：记录使用的 Wi-Fi、蜂窝网络或公司网络，以及是否经过访客网络登录页。
- 再记故障范围：确认是一个应用、一个会议，还是网页浏览和其他实时通信也同时受影响。
- 避免同时改多项：每轮只变更网络、规则或节点中的一项，方便知道哪项变化带来结果。
二、理解 UDP：网页能开，不代表会议媒体畅通
网页登录、会议列表和部分 API 请求通常能通过常规 HTTPS 访问，但实时音视频还需要稳定的媒体传输路径。Zoom、Teams 会根据客户端、会议类型、网络条件和组织策略使用不同的连接方式；在允许的条件下，实时媒体可能优先采用 UDP，网络不支持时也可能尝试其他路径。因此，浏览器可以打开会议页面，不等于语音、视频和屏幕共享都已经具备良好链路。
一些企业网络会限制 UDP，或者只允许管理员配置的媒体目的地址与端口。端口和域名要求可能随产品、租户策略及客户端版本变化，不宜把网上流传的一组固定端口当作所有环境的通用配置。公司网络中的 Zoom 或 Teams 会议如果仅在开启代理后能加入，也不能据此推断代理就是正确的长期方案；应先确认公司 IT 对会议流量和 VPN 的要求。
实际排查时，把“能否登录”和“媒体是否稳定”分开判断。若会议已加入，但只有声音或画面断续，优先查看会议应用提供的网络统计、系统网络质量提示，并比较 UDP 受限与否；若始终停在登录或加入页面，再检查相关规则是否让认证、会议服务和必要的资源请求走到了合适的出口。不要仅通过放宽全部规则或把所有流量改为代理来掩盖问题。
三、用 Config 做有边界的会议分流
日常使用优先从 Global Routing 的 Config 姿态开始，让现有配置按规则决定连接路径。不要为了单次会议长期停在 Proxy，也不要把 Direct 当作必然更快的答案：适合的路径取决于当前网络、服务访问要求以及自己的配置。Config 中的策略名称必须与实际配置一致，例如规则写入 PROXY，配置中就必须存在对应策略；若实际名称不同，应按已有配置调整。
会议域名规则示意
- Zoom 示例
- DOMAIN-SUFFIX,zoom.us,PROXY
- Teams 示例
- DOMAIN-SUFFIX,teams.microsoft.com,PROXY
- 应用策略
- PROXY 必须是现有有效策略
- 规则位置
- 置于会匹配这些域名的宽泛规则之前
示例只说明规则写法，不是完整域名清单或适用于所有组织的建议。
修改前核对项目
- 默认姿态
- Global Routing → Config
- 目标范围
- 只处理有需要的会议服务域名
- 策略名称
- 与 Config 中的策略定义一致
- 公司设备
- 先确认管理员的网络要求
Zoom 和 Teams 可能依赖多个服务域名及第三方资源，单条规则不保证覆盖全部连接。
上面的域名仅为便于理解的规则示例，不代表 Zoom 或 Teams 的完整网络依赖。实际服务还可能使用不同的登录、内容分发、会议和媒体端点；组织租户也可能使用自定义策略。若服务商或组织管理员提供了明确的域名清单，应优先依据该清单整理规则，不要凭名称猜测并批量添加宽泛域名。
规则自上而下匹配时，会议域名规则必须位于会先行匹配的宽泛规则之前；同时还要确认规则结果指向的策略真实存在。修改后先保存 Config，再检查当前 Global Routing 是否仍为 Config。若一条会议规则没有改变实际路径，应先查看是否被前面的规则截获，而不是不断叠加重复条目。
四、动手操作：逐项测试 Wi-Fi、蜂窝与公司网络
中途测试建议沿用一场低风险的测试会议，尽量固定设备、会议应用、参与人数和时间长度。每次切换网络或设置后，等待会议连接稳定，再分别检查语音、摄像头和屏幕共享。若是正式会议，不要在会议进行中尝试会影响他人或导致掉线的配置变更。
-
记录当前配置
在 Home 记录当前选中的节点与连接状态，并在 Config 记下当前配置名称和相关规则。先不要删除原规则，保留可回退的状态。
-
测试 Wi-Fi
连接常用 Wi-Fi，确认网络登录已完成。以当前 Config 设置加入测试会议，分别观察声音、画面和共享是否稳定，并记录应用显示的网络统计。
-
测试蜂窝网
保持 Shadowrocket 与会议配置不变，切换至蜂窝网络复测。若蜂窝网络正常而 Wi-Fi 异常，优先排查 Wi-Fi 的 UDP 放行、DNS、信号质量或公共网络限制。
-
核对公司网络
在公司网络只按组织允许的方式测试。记录是否需要特定 VPN、代理或管理员提供的配置；若媒体受限或会议失败，向 IT 提供时间、网络类型和错误现象。
-
单项调整复测
需要调整时，每次只改一条明确相关的规则或一项既有策略，保存后重新加入测试会议。若表现变差，恢复刚才的改动，不要同时更改 DNS、全局路由和多个策略。
每轮记录至少包含网络类型、Global Routing 姿态、规则是否命中、会议表现和时间。切换 Wi-Fi 与蜂窝网络时，运营商路由、信号强度和网络拥塞也会改变结果；因此一次顺畅或一次卡顿不能证明配置永久有效。若只有特定时段出现问题，最好在相近时段重复测试，并把结果交给网络管理员或服务支持进一步判断。
五、按症状缩小范围，不要盲目改全局设置
会议故障可以按“登录与加入、音视频媒体、规则路径、网络环境”逐层排查。先确认 Home 中连接状态，再确认当前规则姿态和选中的 Config；接着用应用内网络统计或会议测试功能判断问题发生在加入前还是加入后。若只在一个网络环境中复现，优先检查该环境，而不是重建全部订阅或清空配置。
- 能加入但声音断续：检查 Wi-Fi 信号、上行占用、丢包和 UDP 媒体路径。关闭正在上传的大文件或高负载任务后复测；不要仅凭网页速度测试判断实时语音质量。
- 声音正常、画面冻结：核对摄像头编码负载、视频分辨率和上行带宽，并观察是否只有屏幕共享或摄像头受影响。必要时先降低会议视频质量，再比较网络表现。
- 会议页面或登录失败：检查 DNS 解析、认证相关规则及当前 Config 的规则顺序。确认不是公司网络登录页、账户验证或组织策略导致，再尝试调整明确相关的域名规则。
- 只有公司网络异常：记录网络环境和错误提示，询问管理员是否限制 UDP、要求特定代理方式或禁止个人网络配置。不要自行添加宽泛规则绕过策略。
- 切换网络后恢复：保持会议配置不变，回到原网络复测一次；若故障随网络变化，优先定位网络路径，而不是把偶然恢复归因于某个节点。
网页能打开，为什么会议还是断断续续？
网页可访问不代表实时媒体路径稳定。查看 Zoom 或 Teams 的会议网络统计，并在同一配置下对比 Wi-Fi 与蜂窝网络；若只有 Wi-Fi 出现丢包或媒体异常，优先检查该网络对 UDP 和 DNS 的处理。
是不是把 Global Routing 改成 Proxy 就会更稳？
不一定。Proxy 会改变更大范围的流量路径，可能引入额外延迟，也可能影响公司网络访问。先使用 Config 和明确的规则逐项测试；只有在合法且符合组织要求的情况下，才评估其他姿态。
加了 Zoom 或 Teams 规则，还是无法加入会议？
示例规则不是完整服务清单。先检查规则是否被前序条目截获、策略名称是否有效，再确认组织提供的域名与访问要求；不要把整个域名空间或所有流量一概改为同一策略。
六、保留可回退配置，并按平台获取客户端
远程办公的配置应当可解释、可回退。新增规则前记录原有顺序与策略名称；验证失败时先撤销最近一次改动，再检查是否恢复基线。不要在公司设备上删除受管理的配置，也不要把包含订阅地址、认证信息或内部域名的截图和配置文件公开分享。Shadowrocket 是闭源商业应用，客户端本身不会自动提供会议服务或线路。
Shadowrocket 覆盖 iPhone、iPad、Mac（Apple 芯片与 Intel）、Windows、安卓和 Linux。iPhone / iPad 版在 App Store 以 $2.99 一次性付费获取；Mac、Windows、安卓和 Linux 版免费，平台入口见本站客户端下载页。客户端买断 ≠ 线路套餐；本文所有网络测试均以用户已有自己的订阅和合规网络权限为前提。