远程办公时，视频会议是否稳定，取决于网络持续传输、UDP 路径、DNS 与分流规则等多个环节，不是单看一次延迟测试。本文以 Zoom 和 Teams 为目标服务，介绍如何在 Shadowrocket 中比较直连与代理、检查 UDP 是否可用，并分别处理家用 Wi-Fi、蜂窝网络和公司网络。操作以用户已有自己的订阅和连接配置为前提；订阅链接请从你的服务商处获取。
先把“通话稳定”拆成可检查的指标
视频会议对网络的要求不只是“连得上”。通话过程中，画面和声音会持续传输；如果网络时好时坏，即使开始时连接很快，也可能出现声音断续、画面冻结、共享屏幕延迟或短暂重连。反过来，延迟稍高但传输连续的网络，有时比延迟低却频繁丢包的网络更适合开会。
可以把一次会议拆成几个观察点：加入会议所需时间、音频是否连续、画面是否频繁降质、共享内容是否跟手，以及切换 Wi-Fi 或蜂窝网络后是否需要重新连接。每次记录时，尽量固定设备位置、会议类型和参与方式；如果一边换节点、一边改规则，又同时切换网络，就很难确认改善来自哪项变化。
延迟测试也有边界。Shadowrocket 的 Connectivity Test 能帮助判断所选连接的测试结果，但测试通过不等于 Zoom 或 Teams 的媒体流已经正常，更不能单独证明 UDP 可用。若会议能加入但音视频不稳定，应结合会议本身的连接诊断、实际通话表现和当前网络条件判断。
先比较直连与代理，不预设代理一定更好
会议软件能否稳定直连，取决于当前网络到服务端的实际路径和组织网络策略。家用网络或蜂窝网络下，直连可能路径更短、额外环节更少；如果直连出现反复中断，用户已有的代理连接可能提供另一条可测试的出站路径。代理会增加一段连接链路，若节点负载高、UDP 受限或路径绕远，也可能令通话更差。
按规则决定会议流量走 Proxy 或 DIRECT。先让非会议流量保持原有处理方式，再针对会议服务逐步验证。
适合：日常办公、需要保留其他分流规则
会议请求直接通过当前 Wi-Fi 或蜂窝网络连接，不经代理出站。是否可用取决于本地网络及服务端路径。
适合：先建立基线、公司政策要求直连
临时将请求统一交给当前代理选择，用于对照测试；它不能修复 UDP 被限制、节点异常或错误的服务配置。
适合：短时排查分流，不作为默认会议方案
建议先在会议软件和组织允许的范围内测试直连，再用已有连接做对照。可在相近时间分别进行一次简短测试会议，记下加入时间、声音连续性、画面状况和共享屏幕表现。只有当代理路径在多次对照中表现更稳定，且符合服务条款和组织政策时，才考虑把相关请求纳入 Config 分流。
结论：以整场表现决定路由
延迟数值只描述一次测试，不能替代持续通话观察。先保留直连作为对照，再用相同会议条件复测代理；优先选择掉线少、音频连续的一种路径，而不是最低的单次延迟。
检查 UDP 路径，别把端口测试当成通话证明
Zoom 和 Teams 的实时音视频可能使用 UDP 传输，但所需地址、端口和媒体路径会随产品配置、会议功能、网络环境及服务端安排变化。某个端口在一份旧说明中出现，不代表所有会议都必须使用它；也不应把一组固定端口当成适用于所有组织的规则。企业网络还可能要求经指定的防火墙、代理或安全网关处理。
| 现象 | 可能说明 | 检查方法 |
|---|---|---|
| 能加入会议，音频间歇中断 | 媒体传输路径可能受限或不稳定，也可能是 Wi-Fi 拥塞 | 在同一网络重测，再用蜂窝网络作对照；查看会议软件提供的网络诊断 |
| UDP 测试没有结果，但网页正常 | 测试目标或测试方法未覆盖实际会议路径 | 不要据此断定所有 UDP 不可用；以实际会议媒体状态和网络管理员说明为准 |
| 直连失败，Proxy 下可以加入 | 两种出站路径的可达性或策略不同 | 进一步观察完整通话与共享屏幕，不要只以加入会议成功下结论 |
| Wi-Fi 正常，蜂窝网络频繁重连 | 蜂窝信号、网络切换或运营商路径可能影响持续连接 | 保持节点与规则不变，换信号较稳定的位置复测 |
Shadowrocket 中测试节点的连接状况，与会议软件建立媒体传输不是同一件事。若服务商提供的协议本身使用 UDP，仍需确认当前网络允许该流量通过，并确认所选连接的参数完整。若代理连接只能承载部分请求，会议可能出现“可以登录、但音视频不稳定”的情况。此时不要通过随意更改端口、TLS 或协议字段尝试修复；先对照服务商提供的原始参数，并确认目标网络是否限制相关传输。
在公司网络上，UDP 被限制可能是有意的安全策略。不要试图绕过公司要求；应向网络管理员确认 Zoom 或 Teams 的允许方式、目标范围及组织指定的连接路径。若公司要求使用其批准的网络配置，应以组织规定为准。
用 Config 规则安排会议流量
要只调整会议服务的路由，应先确认 Home → Global Routing 当前使用 Config，并核对 Config 中选中的配置文件。规则自上而下匹配，较早命中的规则会先决定请求采用的策略。因此，会议服务的例外规则要结合现有规则顺序检查；如果前面已有范围更大的规则，后续新增条目可能不会生效。
会议走代理
- 策略
- 匹配会议服务的规则使用 PROXY
- 适用条件
- 直连多次不稳定，且组织允许代理出站
- 核对位置
- Home → Global Routing → Config
- 风险提示
- 代理路径若不支持所需 UDP，媒体质量仍可能变差
先核对规则是否命中，再判断代理路径是否改善实际通话。
会议走直连
- 策略
- 匹配会议服务的规则使用 DIRECT
- 适用条件
- 本地网络可用，或组织要求会议直连
- 核对位置
- Config → [Rule] 及 Home → Global Routing
- 风险提示
- DIRECT 仍受本地网络出口与防火墙策略影响
规则直连不代表任何网络环境都能连接会议服务。
Zoom 和 Teams 的服务地址并非单一域名；会议、登录、共享内容和媒体连接可能涉及不同请求。不要仅凭一个域名后缀就声称规则已覆盖全部会议流量，也不要把不确定的 IP 地址长期写成固定规则。添加规则前，应依据当前服务文档或组织网络团队提供的目标清单，并确认 Shadowrocket 当前配置支持相应规则写法。
[Rule]
DOMAIN,meeting.example.com,PROXY
FINAL,DIRECT上面的 meeting.example.com 是规则格式示例，不是 Zoom 或 Teams 的真实服务地址，不能直接复制为可用配置。若使用 DOMAIN-SUFFIX、IP-CIDR 或其他规则类型，应先确认匹配范围、规则优先级以及现有 FINAL 的位置。修改前保存或备份当前配置，方便发现误分流时恢复。
动手对照：固定网络、姿态与会议条件
下面的顺序用于找出问题发生在哪条路径，不代表任何节点或网络的性能结论。开始前记录当前 Home 选中的连接、Global Routing 姿态和网络类型；如果是工作设备或公司网络，先确认允许使用的配置范围。
-
记录基线
保持当前网络与规则不变，使用 Zoom 或 Teams 进行一次短测试会议。记录加入时间、音频是否连续、画面是否冻结及共享屏幕是否延迟，不要同时改动节点和 DNS。
-
确认连接
在 Shadowrocket 的 Home 确认当前选中的条目与连接状态。必要时先执行 Connectivity Test，但把结果仅作为连接检查，不当作会议 UDP 或实际媒体质量的证明。
-
验证直连
在组织允许的前提下，将相关会议请求按现有 Config 规则设为 DIRECT，或在 Home → Global Routing 临时选择 Direct。用相同会议类型和相近时段再测一次，并记录观察结果。
-
对照代理
切回 Config，使用自己已有的连接，并仅对确认过的会议目标应用代理策略。若需短时选择 Proxy 做排查，应在测试后恢复原有姿态，避免将临时设置留作日常全局路由。
-
核对规则
回到 Config 检查会议请求是否可能被更早的规则匹配；确认规则顺序、策略和当前配置文件一致。若仍无法判断，先恢复备份，再结合会议诊断与网络管理员提供的信息排查。
为了减少偶然因素，可在同一网络条件下重复每种方案，并记录每次的路由姿态和结果。如果直连稳定而代理不稳定，优先保留直连，不必为了“全局代理”改变会议路径；如果只有代理路径稳定，也要确认该路径符合服务使用要求，并在完整会议中验证，而不是只测试加入阶段。
按家用 Wi-Fi、蜂窝与公司网络调整
同一条连接在不同网络下表现不一样并不罕见。家用路由器可能存在无线干扰，蜂窝网络会因信号和基站切换改变路径，公司网络则可能有明确的防火墙与访问策略。应先定位网络条件，再调整 Shadowrocket 的分流，避免把局部问题误判成节点故障。
远程会议：先选网络基线，再选择路由
家用 Wi-Fi 与蜂窝网络
- 先在 Wi-Fi 下测试直连，尽量靠近路由器并减少同网大流量传输。
- 保持规则与连接配置不变，再用蜂窝网络复测，区分本地 Wi-Fi 与远端路径问题。
- 会议稳定优先于单次延迟；不要在会议中途频繁切换路由姿态或连接条目。
公司网络
- 先确认组织对 VPN、代理和会议媒体流量的使用要求。
- 若公司规定直连或指定出站方式，不要用其他策略绕过限制。
- 遇到 UDP 受限或会议中断时，向网络管理员提供时间、网络类型和脱敏后的现象记录。
每次只改变网络或路由中的一项，并在测试结束后恢复不需要的临时设置。
在家用 Wi-Fi 下，先排除路由器距离、无线干扰和同网设备占满上行带宽等因素；视频会议的上行传输也会受到影响。蜂窝网络测试时，记录信号是否稳定以及是否发生 Wi-Fi 与蜂窝之间的切换。若切换网络后会议中断，先判断是系统网络切换还是规则行为变化，不要在通话中反复调整配置。
公司网络下，Shadowrocket 的配置不能替代组织批准的网络策略。公司可能只允许指定的会议服务地址、端口或安全网关；不确定时先询问管理员。向管理员反馈时可记录会议时间、网络类型、直连或代理姿态、错误现象和复现步骤，但应遮盖订阅链接、密码、密钥及其他访问凭据。
Connectivity Test 通过，会议还是卡怎么办？
它只能说明测试环节有响应，不能证明会议媒体流已稳定。保持当前节点和网络不变，分别观察直连与代理下的完整通话表现，并查看 Zoom 或 Teams 提供的网络诊断。
会议规则该全部设为 PROXY 吗？
不必预设。先用直连建立基线，再确认哪些会议请求需要另一条路径；按服务或组织提供的目标范围调整 Config，并检查前序规则是否已匹配。
公司 Wi-Fi 下 UDP 不通，能否直接改规则？
先核对公司的网络要求。若 UDP 限制来自组织策略，应向网络管理员确认获准的连接方式，不要自行扩大代理范围或尝试绕过限制。
结束前检查配置与隐私
视频会议排查通常会产生连接记录、订阅信息和会议诊断数据。订阅链接可能包含访问凭据，节点字段也可能包含密码、密钥或服务器信息。公开截图或向他人求助前，应遮盖这些内容；分享会议诊断时也应遵守组织的数据处理要求。
- 临时使用 Proxy 或 Direct 做对照后，回到 Home → Global Routing 恢复原先使用的姿态。
- 确认 Config 中当前文件、规则顺序与预期一致；不要把示例域名或未经验证的地址直接当成生产规则。
- 若会议只在一种网络失败，保留这个差异作为排查线索，优先检查该网络路径，而不是同时修改所有连接参数。
- 订阅更新、节点更换或网络切换后，重新核对实际选择的条目；订阅来源请从你的服务商处获取。
稳定方案应来自可重复的对照，而不是一次偶然成功。以完整会议表现为判断依据，先确认直连基线，再核实 UDP 与组织网络策略，最后用 Config 为确有需要的目标安排路由；这样既能保留日常分流，也能在问题出现时更快定位环节。