远程会议的稳定性不只取决于 Shadowrocket 是否显示已连接，还与会议流量走直连还是代理、当前服务器是否支持 UDP、Wi-Fi 或蜂窝网络质量，以及工作网站的路由规则有关。Zoom、Teams 的会议连接可能使用多个域名、动态地址和媒体传输端口，因此不能只添加一条域名规则就假定所有音视频流量都已覆盖。
本文以用户已有自己的订阅和工作网络权限为前提，说明如何检查现有服务器、设置分流并在会议前做对照测试。规则示例用于解释思路，具体策略名称和服务端点应以当前生效的 Config、组织网络要求及服务的官方网络说明为准。
先在 Home → Global Routing 中确认使用 Config，再分别判断会议、工作网站和普通浏览流量应直连还是代理。会议前用同一网络测试现有服务器，确认 UDP 支持与实际音视频质量；切换 Wi-Fi 和蜂窝网络后重新检查，不把一次成功的 Connectivity Test 当成会议质量保证。
一、先划分会议流量、工作网站与普通访问
远程办公不宜一概把所有连接交给同一种路由。公司内网、身份验证页面或受组织管理的工作网站，可能要求从指定网络直连；某些工作资源则可能需要通过用户已有的代理路径访问。Zoom 和 Teams 的信令、登录、屏幕共享与实时媒体也未必使用完全相同的域名或连接方式。
开始设置前，先列出会议应用、必须访问的工作网站，以及组织提供的网络要求。对于公司管理的设备或网络，应遵循组织的安全策略；不要为了让某项连接成功而绕过访问控制，也不要把工作凭据、会议链接或内部域名写进公开求助内容。
- 会议应用：明确 Zoom 或 Teams 的登录、加入会议、语音、视频、屏幕共享是否都要测试。进入会议后能听到声音，不代表屏幕共享和视频上行也正常。
- 工作网站：分清内部域名、身份验证入口和公共网站。若组织要求内网直连，按其说明设置，不要把所有工作域名笼统交给 PROXY。
- 普通访问：明确哪些流量继续使用现有 Config 规则，避免为了单场会议把日常路由整体改成 Proxy 或 Direct。
- 当前网络：记录使用的是 Wi-Fi 还是蜂窝网络、是否有门户认证，以及连接期间是否切换过网络。
先记录 Home 中当前选中的服务器条目和 Global Routing 姿态。Home 的服务器选择与 Config 内的策略组可能是两套决策：Config 规则命中某个策略组时，最终采用的服务器可能由该策略组决定。因此，不能只看 Home 上选中的名称，就断定会议流量一定经过它。
结论：先确定业务边界，再动分流规则
如果组织对工作资源有明确的直连或代理要求，先按要求分类；只有在边界清楚后才添加例外规则。这样可以减少规则冲突，也避免为修复会议问题影响登录、内部网站或其他工作连接。
二、Zoom 与 Teams：检查 UDP 和媒体连接
视频会议的实时音频、视频通常对延迟、抖动和丢包更敏感。即便网页能打开、登录也成功，实时媒体连接仍可能受限。会议软件可能尝试 UDP 媒体传输；网络不允许 UDP 时，应用有时会改用其他路径，但表现和质量取决于应用、网络及服务端条件，不能仅凭连接开关判断。
常见的网络要求资料会提到 Teams 媒体相关 UDP 端口范围 3478–3481，Zoom 也可能使用 UDP 媒体端口。端口与网络要求可能随产品配置、组织策略和服务更新而变化；这些数字不是 Shadowrocket 中可以直接照抄的通用规则，也不意味着开放端口就能保证会议稳定。需要按当前服务官方网络要求及组织防火墙策略核对。
检查路由路径
- Global Routing
- 日常按规则分流时使用 Config
- 会议域名
- 只按当前配置支持的规则类型核对
- 策略名称
- 确认规则引用的 PROXY 或策略组确实存在
- 工作内网
- 按组织要求判断是否应为 DIRECT
规则命中只说明选中了相应策略，不代表目标服务已连通。
检查媒体条件
- UDP
- 确认所选服务器和网络路径支持所需 UDP 流量
- 蜂窝网络
- 与 Wi-Fi 分别测试，不假设两者限制相同
- 实际会议
- 测试麦克风、扬声器、摄像头和屏幕共享
- 质量表现
- 观察延迟、抖动、丢包及中断是否持续
Connectivity Test 不能替代真实会议中的媒体测试。
不要为 Zoom 或 Teams 随意添加一组看似完整的域名后缀规则。会议服务可能使用不同区域的入口、云端地址和动态媒体端点；单靠 DOMAIN-SUFFIX 可能覆盖登录页面，却漏掉媒体连接。若要调整规则，应以自己当前 Config 的语法与组织提供的网络清单为依据，并一次只改一条，改后核对实际命中的策略。
当会议卡顿时，可以比较 Config 下的会议表现与临时 Proxy 下的表现，但先记录原设置，且只在符合组织策略时进行。若 Proxy 下改善而 Config 下不改善，重点检查会议相关规则和策略组选择；若两种姿态都卡顿，则还需检查当前网络、服务器负载、UDP 可达性和设备本身，而不是继续堆叠域名规则。
三、会议前按步骤检查 Shadowrocket
建议在会议开始前留出几分钟完成检查，而不是在通话中连续切换多个设置。以下步骤先确认配置，再检查连接和媒体；路径中的界面名称保留英文，若当前版本的字段排列不同，应按实际界面含义操作。
-
记录当前状态
打开 Home，记下当前选中的服务器、连接开关状态和网络类型。进入 Home → Global Routing，确认日常设置是否为 Config；如果需要临时改变路由，先记下原值以便会后恢复。
-
核对 Config
进入 Config，确认当前生效的配置文件包含所需规则，并核对引用的策略名称与策略组。不要把订阅中的服务器列表误认为已经配置好会议分流规则。
-
确认服务器
回到 Home，确认目标服务器仍在列表中且已正确选中。若订阅刚更新过，重新核对条目和策略组选择；只使用自己已有且获准使用的配置。
-
检查连接
确认设备本身可以联网，打开 Shadowrocket 连接开关，并在 Home 执行 Connectivity Test。记录测试结果和当时使用的网络，不把测试成功视为 Zoom 或 Teams 媒体连接已通过。
-
试用会议设备
在 Zoom 或 Teams 的测试入口或低风险通话中，分别检查麦克风、扬声器、摄像头和屏幕共享。观察是否出现断音、画面冻结或共享失败，再决定是否需要检查规则。
-
恢复日常设置
若为对照测试临时切换过 Global Routing 或服务器，测试后恢复记录的日常状态。确认工作网站和内网资源仍按组织要求访问。
如果只有一个会议功能失败，例如音频正常但屏幕共享无法开始，记录具体功能和发生时间，比“会议连不上”更有助于定位。一次只改变一个条件，例如先固定 Wi-Fi、再比较一个服务器；避免同时更换路由、DNS、服务器和规则，否则即使结果改变，也难以知道是哪项设置起作用。
四、怎样从已有服务器中选择会议用项
远程会议不应只按列表中显示的延迟数字选择服务器。延迟测试通常只是某个时点、某个测试目标的结果，不能完整代表持续音视频的丢包、抖动、上行稳定性或 UDP 转发能力。本文不提供服务器或订阅；应仅在用户已有的配置中，按相同网络条件做可重复的对照。
- 先排除明显不可用项：使用 Connectivity Test 和实际网页访问检查基本连通性。连续失败时记录结果，不要把超时一次就解释为永久失效。
- 再测试会议功能：在相同 Wi-Fi 下依次测试候选项，保持同一场测试的设备位置、会议功能和网络条件一致，记录音频、视频、共享是否稳定。
- 关注持续表现：通话过程中观察是否反复断音、延迟突然增加、视频冻结或共享中断。短时延迟较低但持续丢包的路径，未必适合长会议。
- 单独验证 UDP：若网页和登录正常但实时媒体异常，核对服务器配置与当前网络是否允许所需 UDP 流量。TCP 访问正常不能证明 UDP 也可用。
- 保留备用方案：把测试过且符合工作要求的现有选项记下来。备用项也应在会议前验证，临时切换到未经测试的条目可能增加排错时间。
如果某个候选项只有在特定网络下表现正常，备注测试环境，例如“办公室 Wi-Fi”或“蜂窝网络”，但不要把认证信息、订阅 URL 或公司内部地址写入备注。家庭宽带、公共 Wi-Fi 与蜂窝网络的路由、拥塞和 UDP 限制可能不同，结果不能直接互相替代。
五、Wi-Fi 与蜂窝网络切换时怎么处理
iPhone 从 Wi-Fi 切换到蜂窝网络，或反向切换时，网络接口、出口地址和路由条件都会变化。VPN 连接可能短暂重建，会议应用也可能需要重新建立媒体通道。即使 Shadowrocket 的开关仍显示开启，也应确认会议是否已经恢复传输。
- 会议前固定网络：能使用稳定、获准的网络时，尽量避免在会议中途切换。开始前确认 Wi-Fi 已完成必要的网页认证，蜂窝网络也有稳定信号。
- 切换后重新观察：如果必须更换网络，等待连接状态稳定，再检查会议音频和视频。必要时重新加入会议，但先确认组织对重新连接的要求。
- 分开记录结果：Wi-Fi 与蜂窝网络分别记录 Connectivity Test、会议媒体和服务器选择。不要只在其中一种网络测试后，就认定另一种网络也适用。
- 检查系统限制：确认设备允许应用使用蜂窝数据，并留意低数据模式、信号弱或网络拥塞等影响。具体系统选项以设备当前设置为准。
如果切换网络后只剩会议画面、没有声音，先判断这是短暂重连还是持续故障；随后检查 Shadowrocket 是否仍连接、Global Routing 是否仍为预期姿态，以及会议应用是否显示音频设备异常。不要在不稳定的会议中同时改 DNS、删除订阅或重置所有配置，这些操作会引入新的变量。
操作建议：会议中断后先记下发生时的网络、Global Routing 和具体故障表现，再做单项检查。涉及公司网络或会议数据时，优先遵循组织的 IT 支持流程。
六、常见现象的定位顺序
排查时先区分“应用登录失败”“网页可用但媒体卡顿”“只有某个工作网站失败”和“所有流量都异常”。错误范围不同，优先检查的层次也不同。以下问答卡不替代组织网络策略或服务端状态检查，目的是帮助固定下一步的验证动作。
网页能打开，为什么会议一直断音？
网页成功只证明对应网页连接可用。先在同一网络下检查服务器和 Config 策略，再验证会议媒体是否需要 UDP、当前服务器是否支持相关转发，并在 Zoom 或 Teams 中分别测试音频、视频与共享。
Connectivity Test 成功，会议还是卡？
测试结果对应特定目标与时刻，不覆盖持续媒体流量。记录会议卡顿时的网络类型和具体表现，再用相同条件比较已有服务器；不要仅凭一次测试成功判定线路适合长时间通话。
只有一个工作网站打不开怎么办？
先确认该网站是否属于组织内网，以及组织要求 DIRECT 还是代理访问。再检查 Config 中相关域名规则的顺序、目标策略是否存在，并一次只调整一个匹配项；不要直接把全部工作流量改成 Proxy。
规则故障通常表现为特定域名或某类服务失败，而基础连接故障可能影响多个目标。检查 Config 时，注意规则从上到下的匹配顺序、策略名称是否有效，以及规则是否仅覆盖登录域名而未覆盖实际媒体端点。未经核实，不要将示例域名直接当成 Zoom 或 Teams 的完整域名清单。
若所有网络和所有目标都异常，先确认设备本地网络可用，再检查 Shadowrocket 连接状态、当前服务器条目和服务端可用性。若只有公司资源异常，联系组织的 IT 支持并提供不含凭据的错误现象、发生时间、网络类型与测试步骤。订阅链接、密码、UUID、私钥及会议邀请信息都应保持私密。
远程办公的可靠设置来自明确的路由边界、可复现的测试和会议前检查，而不是不断增加规则。保持日常 Config 简洁，按组织要求处理工作资源，并在 Wi-Fi 与蜂窝网络下分别验证实际会议功能，才能更清楚地判断问题位于规则、网络还是服务器路径。