远程办公时，Shadowrocket（小火箭）不必默认把所有流量都送进代理。更稳妥的做法是先确认当前连接对 UDP 的支持，再用 Config 让 Zoom、Teams 和必要的办公服务按规则分流，并让不需要代理的流量保持直连。本文以用户已有自己的服务器或订阅资料为前提，说明会议前的检查、规则示例、操作步骤和故障定位方法；域名示例用于解释写法，不是完整的服务端点清单。
先看连接条件：延迟、丢包与 UDP
视频会议是否流畅，不只取决于延迟测试中的一个数字。语音和画面会持续发送实时数据，网络抖动、丢包、上行带宽不足或 Wi-Fi 信号变化，都可能造成声音断续、画面冻结和共享屏幕延迟。延迟较低但波动很大，实际体验仍可能不稳定；延迟略高但连接持续、丢包少，有时反而更适合长时间通话。
Zoom 和 Teams 的会议媒体可能使用 UDP，也可能在网络条件或服务端策略影响下采用其他传输方式。Shadowrocket 能否把 UDP 请求转发到远端，取决于所选协议、服务器端实现和已有配置，不是只打开客户端连接开关就能保证。若服务提供方没有说明 UDP 是否可用，或相关连接配置不支持 UDP，规则写得再完整也无法凭空补出这项能力。
测试时固定同一台设备、同一网络和同一条已有连接，分别观察会议加入速度、语音连续性、屏幕共享及重连情况。不要只用一次 Connectivity Test 代替真实会议：测试结果可以帮助确认连接是否有响应，但不能代表 Zoom 或 Teams 的每条媒体链路表现。
会议卡顿时先区分“连接质量差”和“规则没有按预期分流”。代理路径无法修复本地 Wi-Fi 丢包，也不能保证远端服务在所有时段都稳定。
选择路由方式：日常优先从 Config 开始
Home → Global Routing 决定当前采用哪种路由姿态。若目标是会议和部分办公服务走代理、其余请求按配置处理，通常应先检查 Config 页面中选用的文件，再在 Home → Global Routing 选择 Config。仅仅在 Config 中看见规则文件，并不等于当前流量正在按它分流。
Proxy 可用于短时间对照：在同一网络和同一服务器下，临时观察会议是否有变化。如果 Proxy 下表现改善、Config 下出现问题，应优先检查规则命中、策略名称和规则顺序。对照结束后恢复日常设置，避免把临时全局代理误当作最终分流方案。Direct 则可用来观察不经过代理时的网络表现；它不适合验证代理规则是否命中。
根据当前配置中的规则和策略处理请求，可将会议相关请求、办公服务与普通流量分别安排。
适合：日常远程办公与按需分流。
用于临时对照整体代理路径表现，不能替代按域名、IP 或策略整理规则。
适合：短时排查 Config 下的分流差异。
用于检查当前网络直接访问的情况。连接开关开启，也不表示请求一定经过代理。
适合：建立本地网络表现的对照基线。
为会议与办公应用建立最小规则
规则应从“实际需要经过哪条路径”出发，而不是先把宽泛的域名后缀都加入代理名单。Zoom 和 Teams 可能使用多个域名、内容分发地址及动态媒体端点；仅凭应用名称推断全部域名，容易遗漏会议依赖项，也可能把其他不相关流量一并送往代理。先查看配置当前已有的规则、策略组和最终规则，再做小范围调整。
下面仅示范规则结构。PROXY 必须替换或对应到当前配置中实际存在的策略名称；示例域名也不能视为完整端点列表。若会议能登录却无法加入、没有声音或共享画面异常，应结合 Shadowrocket 的请求记录和服务端点要求检查，不要不断扩大域名范围。
[Rule]
DOMAIN-SUFFIX,zoom.us,PROXY
DOMAIN,teams.microsoft.com,PROXY
FINAL,DIRECT| 流量类别 | 建议检查 | 规则设计注意点 |
|---|---|---|
| Zoom 会议 | 会议登录、加入、语音、摄像头与屏幕共享是否都正常 | 示例域名不覆盖全部服务端点；确认所用策略及 UDP 转发能力 |
| Teams 办公 | 登录、聊天、文件访问与会议媒体是否分别可用 | 避免未经验证就代理宽泛的 Microsoft 域名范围 |
| 普通网页 | 未命中目标规则时实际采用的路由 | FINAL,DIRECT 是示例兜底，须符合当前配置意图 |
规则通常按配置中的顺序匹配。目标域名规则需要放在可能提前匹配它的宽泛规则之前；FINAL 则用于前面规则均未命中时的兜底。若原配置的最终策略并不是 DIRECT，不要直接覆盖成示例内容。配置还可能包含规则集、策略组或其他最终处理逻辑，修改前先保留原文件，确认改动的是当前选用的配置。
判断：先验证一项会议功能，再扩展规则
先用一场短会议检查加入、双向语音和共享屏幕，再按实际失败的功能补查请求记录与服务端点。每次只改变一项规则，才能知道哪次调整真正改善了连接。
动手配置：按顺序检查并进行会议验证
开始前确认手中已有可用的服务器资料或订阅，并且知道当前使用哪份配置。客户端购买与线路服务是两件事；本站不提供、不销售、不推荐节点或订阅。不要把规则示例中的域名或策略名称当作连接服务资料。
-
记录当前状态
在 Home 记下当前选中的 SERVER、Global Routing 模式及使用的网络。先进行一次会议基线测试，记录加入时间、语音是否连续、画面是否冻结。
-
确认配置文件
进入 Config，确认选中的文件包含预期规则，并保留可恢复的原配置。核对策略名称是否真实存在，避免规则指向不存在的策略。
-
检查 UDP 能力
核对所用协议、服务器端及服务说明是否支持 UDP 转发。不要因为网页通过 HTTPS 可访问，就推断实时会议媒体也一定能正常转发。
-
加入小范围规则
在配置中只加入已经确认需要代理的目标规则，放在可能提前匹配的宽泛规则之前。保留原有 FINAL 意图，不要用示例整段覆盖整份配置。
-
启用 Config
返回 Home → Global Routing，选择 Config，确认选中的 SERVER 后开启连接。首次连接按系统提示允许添加 VPN 配置。
-
复测并比较
加入同一会议，依次验证语音、摄像头和屏幕共享。若仍有问题，记录发生时间与功能表现，再一次只调整一项规则或网络条件。
如果需要比较 Proxy 与 Config，应保持设备、网络、服务器和会议条件不变，只切换 Global Routing。Proxy 仅作为短时对照；测试完成后恢复 Config。不要同时更换服务器、改 DNS、编辑多条规则，否则无法确认改善或故障来自哪一项变化。
按症状排查：区分网络、规则和媒体问题
会议能登录但媒体不稳定，并不自动说明域名规则写错。登录与会议媒体可能走不同请求路径；一项功能正常，不代表所有会议连接都可用。先判断问题是否只发生在代理开启时，再检查 UDP 转发、当前策略、规则命中和本地网络状况。
- 加入会议失败：确认当前 SERVER 已选中，Home 显示连接状态正常；检查会议相关请求是否命中预期规则，以及策略名称是否可用。
- 语音断续或延迟明显：检查 Wi-Fi 信号、上行网络和丢包表现，再确认 UDP 转发条件。单纯增加域名规则不一定解决媒体链路问题。
- 摄像头正常但共享屏幕失败：分别检查共享功能涉及的请求和策略，不要假设所有媒体共用同一域名或传输路径。
- 会议正常但办公网页异常：确认普通办公服务是否被宽泛规则提前匹配，检查最终规则及目标请求实际采用的策略。
- 切换网络后才出问题：在 Wi-Fi 与蜂窝网络之间分别测试。网络策略、信号质量和可达路径可能不同，记录差异后再调整配置。
Connectivity Test 可帮助观察连接是否有响应，但它不是会议质量评分，也不能替代真实通话。若 Shadowrocket 中显示请求未按预期分流，优先核对 Config 是否已选中、Global Routing 是否为 Config，以及规则顺序和策略目标；若请求已经走到预期策略但会议仍不稳定，应继续检查线路质量、UDP 支持和本地网络。
Zoom 能登录，为什么进会议后没声音？
登录成功不代表媒体连接也正常。先用同一网络检查语音与屏幕共享，再确认当前服务器和协议是否支持 UDP 转发，并查看会议请求是否命中预期策略。
规则写了 teams.microsoft.com，Teams 就全覆盖了吗？
不一定。单条域名规则只匹配它所描述的域名，不能证明所有登录、文件和会议媒体端点都已覆盖。依据实际请求与服务端点要求逐项核验，避免扩大到不必要的域名范围。
要不要把所有流量都切到 Proxy？
不建议把它作为默认修复方式。可以在相同条件下短时切换 Proxy 做对照；若表现不同，再回到 Config 检查具体规则，测试后恢复日常分流。
保持可维护：留存基线，避免过度代理
远程办公配置的目标不是让规则越多越好，而是让问题出现时能快速判断发生在哪一层。保留修改前的配置副本，记录采用的服务器、Global Routing 模式、测试网络和会议症状；每次只改变一项设置。这样既能复现结果，也能在规则调整带来副作用时恢复原状。
对日常工作而言，优先使用已经验证过的 Config 分流。会议服务、办公系统和普通网页分别检查，特别留意看似相关但实际使用不同端点的登录、文件传输与实时媒体。若服务端点或网络环境变化，应重新验证规则，而不要把旧测试结果当作永久保证。
Shadowrocket 是 Apple 平台的付费客户端，获取请以 App Store 页面为准。客户端本身不会提供会议线路或服务器订阅；使用前需准备用户已有的连接资料。保持规则范围清晰、UDP 条件明确，并用真实会议复测，比临时把全部流量交给代理更容易定位问题，也更适合长期维护。