This guide is for people who already have their own subscription in Shadowrocket and want to reduce avoidable interruptions during Zoom or Teams meetings. It covers connection selection, UDP checks, domain-based routing, and a repeatable pre-call test. The goal is not to send every work connection through a proxy: use the routing mode and rules that fit the services you actually need, then compare office Wi-Fi with mobile data before an important call.
1. Start with a reliable baseline before changing rules
A meeting can fail for several different reasons: the local network may be unstable, the selected connection may be slow or overloaded, the connection may not carry the traffic the meeting needs, or a routing rule may send a service to an unsuitable path. Changing several settings at once makes these causes harder to distinguish. First establish what works on your current setup, then adjust one variable at a time.
In Shadowrocket, open Home and confirm that the connection you intend to use is present and selected. If you normally use rules, check that the correct file is selected in Config, then set Global Routing to Config. A selected connection and an active connection are not the same thing; check the connection switch and system VPN status as well. If you use a different routing mode, record it before testing so you can restore it later.
Choose a quiet test window and keep the conditions consistent. Pause large uploads, cloud backups, and downloads if possible. Use the same device, meeting app, test contact, and approximate call duration for each comparison. Record the network name, connection selected in Home, routing mode, and any visible call-quality warnings. A single good call is useful, but it does not prove that a setup will remain stable at a different time of day or on a different network.
Start with a short call or meeting test rather than waiting for a critical presentation to reveal a problem. Check whether audio remains clear while video is enabled, then try screen sharing. If the meeting is stable without Shadowrocket for a particular work service and your network policy permits direct access, note that as a baseline too. This comparison is about identifying the route that works in your environment, not assuming that a proxy is always faster or required.
- Write down the exact network and selected connection; do not rely on a server label as proof of its location or performance.
- Keep the active configuration unchanged while collecting the initial results.
- Test at least once with the actual meeting app, because a generic connectivity check cannot reproduce a live audio and video call.
2. Choose a connection and check whether meeting traffic works
Use Home → Connectivity Test to compare available connections under the same conditions. Treat the results as a screening tool, not a guarantee of meeting quality. A low latency result can indicate a quick response to the test target, but it does not by itself show how a connection handles sustained audio, video, screen sharing, or packet loss. Repeat tests at comparable times and include failures or timeouts in your notes rather than recording only the best number.
Next, test the actual meeting service. Join a short test meeting or a low-risk call and check whether both incoming and outgoing audio work. Enable video, then screen sharing, and observe whether the call degrades when more than one feature is active. If the app reports network quality or connection warnings, record the exact wording and the time. A call that connects but has one-way audio is different from a call that never establishes a session.
Real-time meetings may use UDP for media when the service, network, and connection path support it. A successful TCP-based page load does not prove that UDP media will work. Conversely, finding a UDP-related option in a server configuration does not prove that every endpoint or network on the path will pass UDP correctly. The setting name and availability can vary by connection type, so inspect the selected connection’s details rather than assuming that all entries behave alike.
-
Check the entry
In Home, select one existing connection and open its details. Confirm that its address, port, and protocol are the intended ones from your own configuration. If the details expose a UDP relay or UDP support option, note its current state; do not change it yet.
-
Run a baseline call
Use the current configuration for a short Zoom or Teams call. Check two-way audio first, then video and screen sharing. Record whether the call connects, whether sound is one-way, and whether quality changes when video starts.
-
Change one variable
If UDP support is available and appropriate for that connection, change only that option, reconnect, and repeat the same call test. If no such option is shown, do not invent a setting or assume the connection supports UDP; use the actual meeting result as evidence.
-
Compare networks
Repeat the same test on office Wi-Fi and mobile data. Reopen the meeting or start a fresh test call after changing networks so the result is not affected by a session established on the previous path.
Interpret the outcome carefully. If a call works on mobile data but not office Wi-Fi, the difference may be the office firewall, Wi-Fi congestion, or its DNS and routing environment—not necessarily the selected connection. If it fails on both networks, check the connection entry and the active routing rules before concluding that UDP is the cause. When a change makes things worse, restore the previous setting and confirm that the baseline returns.
Decision rule: trust the repeatable call, not one latency result
Keep a connection only when the same meeting test is consistently usable on the network where you need it. Connectivity Test can narrow the candidates; it cannot replace a real call with audio, video, and screen sharing enabled.
3. Route meeting domains without proxying every work connection
When only selected services need a proxy, rule-based routing can be more precise than sending all traffic through a proxy. In Config, review the active configuration’s [Rule] section and identify the policy name used by your own setup. Rules are evaluated in order, so a broad rule placed above a specific meeting-service rule may match first and make the later rule ineffective.
The following lines illustrate the shape of domain rules; they are not a complete Zoom or Teams endpoint list and are not a ready-made configuration. Replace PROXY with a policy that already exists in your active configuration. Confirm that the domain suffixes you choose are relevant to your account and environment using the service’s current network guidance. Meeting services can use additional domains for sign-in, content delivery, telemetry, and media, and those endpoints can change.
[Rule]
DOMAIN-SUFFIX,zoom.us,PROXY
DOMAIN-SUFFIX,teams.microsoft.com,PROXY
FINAL,DIRECTIn this example, matching requests for the listed suffixes use the named policy, while requests that do not match reach the fallback. The example intentionally does not claim that two suffixes cover every meeting feature. For instance, sign-in or media may involve other service domains, and a work organization may use a managed tenant or network policy. Add only domains you have a reason to route, and keep the original configuration available so you can reverse a test.
Use the rule order as a troubleshooting aid. If you already have a rule that sends a wider Microsoft or video-conferencing domain group to DIRECT, a more specific proxy rule may need to appear before it. If your configuration ends with FINAL,PROXY, unmatched work traffic may still use the proxy even when you add only a few meeting rules. Read the complete rule list, including the fallback, before deciding that a domain-specific change will keep unrelated traffic direct.
Can I proxy only Zoom or Teams?
Often you can route selected domains by rule, but the domains used for a complete meeting can extend beyond the app’s main website. Start with the active configuration’s rule order and the service’s current network documentation; test sign-in, audio, video, and sharing separately.
Why does the meeting connect but have no audio?
Connection establishment and media transport are separate checks. Confirm the selected connection, inspect any available UDP support option, then compare a fresh call on Wi-Fi and mobile data. Avoid treating a loaded webpage as proof that call media is working.
Should I set Global Routing to Proxy for a call?
Only use Proxy when you intentionally want all traffic handled by Shadowrocket to use that route for the test. For selective routing, use Config with verified rules and a suitable fallback, then check the resulting behavior before the meeting.
Remember that an app can reuse connections created before a rule change. After saving a configuration, reconnect in Shadowrocket and close and reopen the meeting app, or start a fresh call. If results remain ambiguous, temporarily test one routing mode at a time and restore the intended configuration after the comparison. Do not leave a broad global mode enabled simply because one short test appeared to improve.
4. Use a pre-call checklist for office Wi-Fi and mobile data
For an important call, test the route you expect to use rather than relying on a result from another location. Office Wi-Fi may have congestion, captive access, firewall rules, or restrictions on particular traffic. Mobile data follows a different network path and can also vary with coverage and signal conditions. A successful result on one does not establish that the other will behave the same way.
Before the meeting, confirm that the correct connection is selected in Home, the intended configuration is active, and Global Routing is set to the routing mode you tested. Check that the system VPN connection is active if your setup requires it. Open the meeting app and verify its account and device permissions, including microphone and camera access. These checks do not alter routing, but they prevent a permissions problem from being mistaken for a network failure.
- On office Wi-Fi: join the expected network, complete any required sign-in, and run a short audio test. If the call fails only here, note whether the failure starts at sign-in, call setup, audio, video, or screen sharing.
- On mobile data: disable Wi-Fi only if that is how you normally test cellular, wait for the mobile connection to settle, and start a fresh call. Check the device’s data availability and any organization restrictions before relying on it as a fallback.
- Before the call: stop large transfers, close unnecessary live streams, and avoid updating subscriptions or editing rules at the last minute. If a change is unavoidable, repeat the short test before joining.
- After a network switch: reconnect and open a new meeting session. Existing calls and long-lived connections may continue using the path established before the switch.
If office Wi-Fi is the only failing path, ask the network administrator whether meeting traffic is restricted and provide the failure stage and time. If mobile data is the only failing path, repeat the test where signal is stable and check whether the same connection and routing rules are still active. If both fail, return to the known baseline and verify the subscription entry, selected configuration, and rule order before making further changes.
Keep the final setup modest: route only the services that need the selected path, retain a predictable fallback, and document the configuration and connection that passed the test. A clear note such as “office Wi-Fi, Config mode, fresh call, two-way audio and sharing worked” is more useful than “the proxy was fast.” If the service updates its network requirements or your organization changes its network, repeat the test rather than assuming old domain rules still cover every meeting feature.