Shadowrocket Remote Work Setup for Stable Zoom and Teams Calls

1. Plan the routes before changing settings

A video meeting depends on more than whether a web page opens. The meeting app may use several domains for sign-in, presence, chat, media relay, and file sharing; a call may also establish separate media connections. A rule that matches the sign-in page does not automatically cover every service used during a meeting. Likewise, a successful browser test does not prove that live audio and video are using the intended route.

First decide what “split routing” should mean for your work device. One common arrangement sends specific work services through a proxy and leaves unrelated traffic direct. Another sends selected work services direct while the rest follows the active proxy configuration. Choose based on your organization’s network requirements, the location of the services you use, and the rules already in your Config. Do not assume that one choice is universally faster or more private.

In Shadowrocket, Home → Global Routing → Config applies the rules in the active Config. Proxy routes traffic through the proxy policy, while Direct routes traffic directly; neither is a substitute for testing Config rules. If you change rule text but Global Routing is set to Proxy or Direct, the result may not reflect the rules you edited.

Before editing, make sure your existing connection works and that you can identify the active Config and selected proxy policy. If you use a subscription, obtain its link from your own service provider. Keep a copy of your current rule section so you can restore it if a work app stops connecting. Do not paste a private subscription URL, account details, or meeting information into screenshots or public troubleshooting posts.

2. Choose a routing policy that fits your work services

For a selective setup, list the work apps and services you actually need, then decide which of them should use the proxy. Avoid adding a broad rule for an entire company domain just because one Teams sign-in page uses it: that domain may also serve unrelated services, and a wider match can send more traffic than intended. Domains and service endpoints can change, so use the organization’s current network guidance where available.

The following is a syntax illustration, not a complete Zoom or Teams domain list and not a working connection profile. Replace the example policy and domains only after confirming that the entries belong in your own Config. The fallback shown sends unmatched traffic direct; change it only if that matches your intended policy.

[Rule]
DOMAIN-SUFFIX,zoom.us,PROXY
DOMAIN-SUFFIX,teams.microsoft.com,PROXY
FINAL,DIRECT

A domain rule routes requests that match its domain pattern; it does not identify an application by its name. A video client can contact services beyond the two examples, and a domain change can make a previously working rule incomplete. Add a rule only when you have a clear reason, and avoid treating an illustrative list as a complete endpoint inventory.

Rule order matters. Put a narrow exception before a broader rule that could match the same request, and keep the final fallback at the end of the rule section. If the active Config uses policy groups rather than a simple PROXY policy, make sure each rule refers to a policy name that actually exists. A misspelled or unavailable policy can produce a different result from the one you intended.

3. Edit the Config and verify the match

Make one change at a time. That way, if a call or another work service stops working, you can identify whether the cause was a rule, the fallback, or the selected connection. The menu wording and editing controls can vary by platform, but the checks below apply to the active Config and its routing behavior.

1. Confirm the baseline

   On Home, select a connection you already know works. Confirm that Shadowrocket connects and that a normal test page or work sign-in page loads before changing rules. Record the current Global Routing option and the name of the active Config.

2. Back up the rules

   Open the active Config and copy or otherwise preserve the existing [Rule] section. Keep the backup private because configuration text can include service or account details. Do not replace unrelated DNS, proxy, or other settings while making a routing change.

3. Add one target rule

   Add a verified work-domain rule with the intended policy, such as DOMAIN-SUFFIX,example.com,PROXY for an illustrative domain. Do not use example.com as a real work endpoint. Check spelling, commas, and the policy name before saving.

4. Set Config routing

   Return to Home → Global Routing and select Config. Check that the intended Config is active and that the connection is on. If you leave Global Routing on Proxy or Direct, you are not testing the selective rules in the same way.

5. Check a live request

   Open the relevant work app or page and inspect Shadowrocket’s request or connection records, when available. Look for the requested host, the matched rule, and the resulting policy. Test one unrelated site as well so you can confirm that the fallback behaves as expected.

Do not judge a rule only by the page that appears. A cached sign-in page, an existing meeting session, or a previously established connection can make a configuration look correct when new requests are not matching. Close and reopen the work app after a rule change, then make a fresh connection attempt. If the log shows a different host from the one you expected, investigate the actual request before adding broad domain rules.

4. Choose a responsive connection, not just a low-latency result

A latency check is useful for narrowing down candidates, but it is not a complete measure of call quality. A connection can respond quickly to a small test request and still have jitter, packet loss, congestion, or poor media routing during a live meeting. Conversely, a slightly higher latency result may feel steadier if it varies less over time. Prefer a connection that remains consistent under the conditions in which you work.

When comparing connections already available in your own configuration, keep the test conditions consistent. Use the same device, network, location, and approximate time of day. Check more than one candidate, then make a short test call and listen for delayed speech, gaps, robotic audio, or repeated video freezes. Do not treat a displayed latency value or a successful connectivity test as a guarantee of good Zoom or Teams media.

• Start with stability: Prefer a candidate that gives repeatable results over one isolated low reading.
• Check the route: The proxy endpoint’s location and the route from it to the meeting service both affect the result.
• Keep the comparison fair: Avoid changing Wi-Fi, cellular service, rules, and connection choice all at once.
• Retest at work time: Network load can vary. A result outside your usual meeting hours may not describe peak conditions.
• Use your own service details: Select only connections supplied through your existing service. This guide does not provide or recommend nodes or subscriptions.

If audio is clear but video freezes, or if the problem appears only when several people are sharing video, consider congestion or loss rather than immediately changing every routing rule. If both sign-in and media fail, check the active connection and rule match first. If only one work service fails, compare its requests with the rules and your organization’s current network requirements.

5. Test UDP and media behavior separately

Many real-time meeting systems can use UDP for media when the network path and service support it. That does not mean every Shadowrocket connection supports UDP relay, or that every meeting session will use the same transport. Support depends on the selected proxy protocol, the service configuration, the network in use, and the remote meeting service. Do not assume that an app setting or a successful TCP-based web test proves UDP media is working.

Start by checking whether your existing connection and service provider’s settings support UDP for the selected protocol. If the provider documents a UDP requirement or setting, follow those values rather than guessing. Do not enable unrelated transport options or change protocol fields at random: that can make a connection fail without telling you whether UDP was the original problem.

To compare UDP behavior usefully, keep the meeting, device, and network conditions as similar as possible. First make a short call using your usual setup. Note whether audio is continuous, whether speech arrives in order, and whether video remains usable. Then change one variable—such as the selected connection or network—and repeat. If the issue follows one network but not another, that is useful evidence for a network-path problem; it does not by itself identify the exact device or service responsible.

6. Handle Wi-Fi, cellular, and meeting-day changes

Remote work often means changing networks during the day. Moving from home Wi-Fi to a phone hotspot can change DNS behavior, routing, firewall rules, and the public network path. An established meeting may not recover cleanly from a network switch even if Shadowrocket reconnects. When practical, avoid switching networks during an important call. If a switch is unavoidable, expect to rejoin the meeting and verify audio and video again rather than assuming the old session recovered.

Use the following sequence when a call becomes unstable after a network change. First confirm the device has internet access without changing the Config. Then check Shadowrocket’s connection state and the selected Global Routing option. If it is meant to use split rules, confirm Config is selected and the correct Config is active. Finally, make a new call and inspect the relevant request records. This separates a general network outage from a routing mismatch or a media-path issue.

• Before a meeting: Connect to the network you expect to use, check Shadowrocket’s connection, and open the work app early enough to test a fresh call.
• After changing networks: Recheck connectivity and the active route, then rejoin if the meeting’s audio or video does not recover.
• When rules stop matching: Check the actual requested host in the records. Work services may use endpoints not covered by an older rule list.
• When only one app is affected: Compare that app’s requests and documented network requirements before changing the fallback for all traffic.
• When using a managed device: Follow your organization’s VPN, DNS, and data-handling requirements. Do not bypass controls by adding broad rules.

Once the setup works, keep the final rule section and the chosen Global Routing option documented for yourself. Record what changed and the network on which you tested it, but never include credentials or private subscription links. If a later update changes the work service’s domains or your network environment, repeat the rule and call checks instead of assuming the earlier result still applies.