远程办公用 Shadowrocket 稳定开 Zoom：分流与节点配置技巧

一、先把会议流量和资料检索分开判断

远程办公时，视频会议、公司内部系统、网页检索和文件下载可能连接不同的服务端。把所有流量都设为 PROXY，可能让会议额外经过一段代理路径；全部设为 DIRECT，则可能无法访问某些需要代理的资料站点。更稳妥的方式是先确认每类流量的实际需求，再按域名或现有配置支持的规则类型分开处理。

Zoom 或 Teams 的会议连接不一定只访问一个域名，也可能使用不同的媒体、登录、更新和诊断服务。组织管理的网络还可能要求特定地址直连、开放特定端口，或通过公司 VPN 接入。不要仅凭应用名称猜测域名清单，也不要把网上找到的规则片段直接当作适用于所有账户和地区的完整配置。优先参考组织的网络要求；个人设备则可通过 Shadowrocket 的请求记录观察实际请求，再逐项验证规则。

分流规则处理的是流量该走哪种策略，不会替代公司网络准入、账户权限或会议应用本身的设置。若公司要求所有业务通过指定网关，应遵守组织规定，不要为了改善个人访问而绕过安全策略。本文中“节点”指你已有配置里的连接条目，相关订阅和连接资料应从你的服务商处获取。

二、先检查本地网络、连接条目与 UDP

在修改规则前，先建立一个可重复的基准。选一场可短暂测试的会议，记录使用的网络、会议应用、当前 Global Routing 姿态、所选连接条目，以及通话中的延迟提示、声音中断和画面冻结情况。先在稳定的 Wi-Fi 下测试，再在允许的情况下用蜂窝网络做对照；测试期间尽量不要同时进行大文件下载、云盘同步或系统更新。

节点延迟低，不等于视频会议一定稳定。延迟反映往返时间的一部分，持续抖动、丢包、上行带宽不足、Wi-Fi 干扰和网络切换都可能造成声音断续。还要留意 UDP：实时语音和视频常依赖低时延传输，但实际使用方式会受应用、网络和代理服务支持情况影响。Shadowrocket 中某个连接能完成测试，不足以证明所有会议媒体流都能经它稳定传输；应以真实通话表现和组织网络要求为准。

• 先测直连基准：在不影响工作要求的前提下，使用 DIRECT 参加短时测试，观察会议是否稳定。若公司政策要求代理或公司 VPN，不要为测试擅自关闭。
• 再测现有连接：选择你已有配置中可用的连接条目，比较相同时间段、相同会议和相近网络环境下的表现，避免同时更换网络与规则。
• 记录变化而非猜测：记下应用的网络质量提示、语音是否连续、视频是否冻结，以及 Shadowrocket 请求记录中相关请求命中的策略。
• 检查网络波动：若切换 Wi-Fi 与蜂窝网络时问题明显，先处理覆盖、拥塞或网络切换；频繁换连接条目可能让问题更难定位。

可以用数字帮助比较，但要把它们当作个人测试记录，而不是通用门槛。例如，同一网络下某条连接连续测试数次都显示更低的延迟，却在会议中出现更多声音中断，说明单看延迟无法得出结论。比较时优先看同一环境下的重复结果和实际通话质量；不要把一次测速结果写成长期稳定性的保证。

三、用 Config 让会议与检索各走所需路径

按规则分流时，先确认当前配置文件确实被 Shadowrocket 使用，并在 Home → Global Routing 选择 Config。若选择 Proxy 或 Direct，实际流量可能不按预期的域名规则处理。下面只演示规则结构，meeting.example.com 和 research.example.net 是保留示例域名，不是 Zoom、Teams 或任何实际服务的完整域名清单。请将其替换为组织确认的域名，或经请求记录核实的目标域名。

[Rule]
DOMAIN-SUFFIX,meeting.example.com,DIRECT
DOMAIN-SUFFIX,research.example.net,PROXY
FINAL,DIRECT

DOMAIN-SUFFIX 按域名后缀匹配域名本身及其子域名。会议服务如果使用多个不同域名，必须分别核对；不要为了省事把范围很大的域名后缀设为 DIRECT 或 PROXY。规则通常按配置中的排列顺序匹配，较具体的规则应放在可能覆盖它的宽泛规则之前，FINAL,DIRECT 则为未命中前序规则的请求提供直连兜底。

域名规则不能保证捕获所有情况。例如，应用可能连接未预先列出的服务域名，或者请求记录显示的域名与预期不同；如果规则未命中，先查明实际请求和组织网络要求，再补充具体规则。不要把完整会议服务都简单等同于一个主域名，也不要通过添加大范围 IP 段来替代确认。

四、按顺序应用配置并做同条件对照

改规则前先保留原配置，避免把临时测试直接覆盖成日常配置。测试时一次只改变一个因素：先验证 Global Routing 和规则命中，再比较 DIRECT 与已有连接，最后单独改变网络环境。这样才能判断改善来自规则、连接条目还是 Wi-Fi 状态。

1. 备份配置

   进入 Config，找到当前使用的配置并保留副本。确认待编辑的是实际启用的文件；如果配置来自订阅，留意更新是否会覆盖本地修改。

2. 核对域名

   从组织网络说明或 Shadowrocket 请求记录中确认会议和资料检索涉及的具体域名。不要直接照抄未经核实的公共规则列表，也不要把网址路径或端口写入域名字段。

3. 添加分流

   在当前配置的 [Rule] 段加入具体的 DOMAIN-SUFFIX 规则，检查英文逗号、域名拼写和策略名称。保留现有必要规则，将 FINAL,DIRECT 放在规则段末尾，并确认没有更靠前的宽泛规则抢先匹配。

4. 启用 Config

   保存后回到 Home → Global Routing，选择 Config。确认 Home 中选中的是预期连接条目，再启动连接；不要在 Proxy 或 Direct 姿态下判断域名规则是否生效。

5. 测试会议

   用相同会议、相同设备和相近网络条件进行短时测试。查看会议应用的网络质量提示与 Shadowrocket 请求记录，确认相关域名命中了预期策略，再观察声音和画面是否稳定。

6. 测试检索

   打开需要代理的具体资料站点，确认请求命中 PROXY；再打开一个应直连的办公站点，确认没有被宽泛规则带入代理。每次只修改一条规则或一个连接条件后重复对照。

如果会议中途从 Wi-Fi 切换到蜂窝网络，原连接可能短暂中断；这不一定是规则错误。完成修改后，应在稳定网络下重新开始一场测试，而不是只凭切换网络瞬间的表现判断配置好坏。

五、比较现有连接时，不要只按延迟排序

若直连符合组织要求但会议质量仍差，先排查本地网络、上行带宽、设备负载和组织会议服务状态。若必须使用代理，则在已有配置中选择连接条目做逐项对照。不要把某个条目的一次低延迟结果当成长期稳定的保证，也不要在会议进行中反复切换条目来“碰运气”。

• 先看连续性：在相同网络下重复测试，记录多次结果；偶尔出现的低延迟值不能代表整场会议的质量。
• 再看 UDP 表现：若资料或服务商说明该连接支持 UDP，可将其作为测试条件之一，但仍要实际验证会议中的媒体流。连接可用与 UDP 媒体稳定是两项不同检查。
• 观察上行与丢包：视频会议会持续发送声音、画面或屏幕共享数据。上行拥塞或丢包时，即使下载速度看起来不错，也可能出现语音断续和画面停顿。
• 固定变量：对照连接时保持设备、网络、会议应用版本和规则不变。一次只换连接或网络，否则结果无法说明具体原因。
• 区分局部与全局：只有某一会议服务出问题时，检查对应域名和策略；所有网站都变慢时，优先检查网络或连接状态，不要盲目扩展会议规则。

使用公司设备或受管理网络时，先确认是否需要公司 VPN、指定 DNS 或特定出口。Shadowrocket 的域名分流不能代替组织要求的安全接入方式。若设置与公司策略冲突，应停止自行调整并联系管理员确认，而不是尝试用规则绕开网络限制。

六、按症状排查，保留可复现的结果

“会议不稳”可能来自本地 Wi-Fi、线路拥塞、连接条目、UDP 传输条件、规则命中或会议服务本身。建议记录日期、网络类型、Global Routing、连接条目、请求命中策略和会议表现。下次出现同类问题时，可以按相同条件复测，而不是一次改动多个设置后无法回溯。

调整完成后，保留一份经过实际测试的配置副本，并在需要更新订阅或规则文件前确认本地修改是否会被覆盖。会议稳定性的判断应以实际通话为准：同一网络下重复测试、请求命中符合预期，且声音与画面持续正常，比单次延迟数字更有参考价值。