Shadowrocket Remote Work Setup: Improve Zoom and Teams Calls

1. Understand what Shadowrocket routes

Shadowrocket applies routing to network requests from the device. Its rules select an action for traffic based on the configured routing mode and the rules that match a request; they are not, by themselves, a per-app Zoom or Teams switch. A rule that sends a destination through PROXY can affect requests to that destination from more than one app. Conversely, setting a work-related domain to DIRECT does not guarantee that every connection made by a meeting app is direct, because a call can involve multiple hosts and connection types.

Start by deciding what you want to test: all device traffic through one selected proxy, only requests that match specific rules, or direct traffic with a small number of destinations routed through a proxy. Those choices have different effects on apps outside the meeting. Keep your current configuration available before testing, especially if it contains rules maintained by your provider.

A meeting can appear connected while its media path is struggling. Sign-in, chat, calendar, and call signaling may use different requests from voice and video. A successful webpage load or a low latency-test result therefore cannot confirm that the audio and video path is stable. Judge a setup during a real test call, using the same device, network, meeting type, and approximate duration each time.

2. Choose a routing approach before editing rules

Check Home → Global Routing before changing anything. Proxy sends traffic through the selected proxy rather than testing individual domain rules. Config uses the active configuration’s rules, so it is the relevant mode when you want to verify split routing. Direct bypasses the proxy. If the current mode is Scene, check the scene’s applied settings as well; don’t assume that the rule list alone describes the active route.

There is no universally best route for every call. A direct route may avoid an unnecessary extra network hop, but it depends on the local network and destination reachability. A proxy route may help when the direct path is unreliable, but it adds another connection segment and can fail if the selected proxy or transport does not carry the required traffic. Keep work traffic and other device traffic in mind when you choose a policy.

3. Compare your existing connection options for calls

Choose from entries already present in your own configuration. Do not compare a node on home Wi-Fi with another on cellular and attribute the difference to the node: the local network, congestion, signal strength, and routing mode all change the result. If your subscription needs an update, follow your provider’s instructions and note that its entries or parameters may change. Keep access links and credentials private.

For each candidate, record the selected entry, network, routing mode, whether the app connects, and what happens to audio and video during a short test call. Repeat the same call test at least three times when possible. A single latency figure is useful context, but it cannot show whether media packets are lost, whether UDP is working, or whether the call remains stable under load.

• Check stability: Note repeated freezes, audio gaps, delayed speech, or a call that reconnects. Distinguish these from a one-time delay while the meeting is starting.
• Check both directions: Speak and listen, then enable video if the meeting needs it. A route that carries audio acceptably may still behave poorly when video is active.
• Keep the test comparable: Use the same device, meeting settings, and network for each candidate. Avoid changing DNS, rules, and the selected entry together.
• Keep a rollback note: Record the original selected entry and Global Routing mode before trying a temporary change.

Prefer repeatable call quality over the lowest displayed latency. If one candidate has a slightly higher test value but consistently avoids interruptions, that may be more useful for meetings than an option with a lower number and unstable media. If all candidates fail only on one network, investigate that network before rebuilding your configuration.

4. Run a controlled test in Shadowrocket

Make one small, reversible test before editing a large rule set. Keep the original configuration and note what you changed. The steps below separate basic connectivity, routing mode, and real call behavior so the result points to a useful next check rather than encouraging several unrelated changes at once.

1. Record the baseline

   In Home, note the selected entry and connection state. Note the current value in Home → Global Routing, then identify whether the device is on home Wi-Fi, cellular data, or office Wi-Fi.

2. Check basic access

   With the intended network connected, confirm that the device can reach ordinary websites. If the network requires a sign-in page or other authorization, complete that first. Do not treat a successful web request as proof that meeting media works.

3. Test an entry

   Select one entry already in your configuration and run the available Connectivity Test from Home. Record the result and method shown by the app. Repeat for other candidates under the same network and routing conditions.

4. Make a test call

   Join a low-risk test meeting or a meeting where a brief interruption is acceptable. Check joining, two-way audio, video, and whether quality changes after several minutes. Record symptoms instead of relying only on the call’s initial connection.

5. Restore or refine

   Change one rule or routing choice only if the test gives you a reason to do so. Repeat the same call test, then restore the original configuration if the change makes no improvement or affects other work apps unexpectedly.

Keep a small note with columns for network, routing mode, selected entry, test result, and call symptoms. This avoids confusing a change in local Wi-Fi quality with a change in proxy behavior. If the result changes after moving from Wi-Fi to cellular, repeat the original condition before deciding that a rule or entry caused the difference.

5. Check UDP and split-routing rules carefully

Real-time meeting media can use UDP, while other parts of the service may use HTTPS or additional destinations. A successful TCP-based test, an open webpage, or a connection indicator does not establish that the selected route supports UDP end to end. The proxy entry, the remote service, the local network, and the active routing policy all matter. If Shadowrocket or the entry’s configuration provides a UDP-related setting, inspect it without assuming that the setting alone guarantees successful media delivery.

Rules can only route requests they match. The following lines illustrate the form of domain rules; they are not a complete or current allowlist for either meeting service. A service may use additional hosts, and hostnames can change. Confirm the destinations relevant to your own call using the service provider’s current documentation and Shadowrocket’s available request information before relying on a narrow rule set.

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

These illustrative rules route matching domains to PROXY and send unmatched requests to DIRECT. They do not establish that all Zoom or Teams signaling and media destinations match. A media connection may use another hostname or address, and a domain rule cannot route traffic by a “Zoom app” or “Teams app” label. If a policy group or named proxy is used in your configuration, use the policy name that actually exists there rather than copying an example destination blindly.

• Check rule order: In Config, rules are evaluated from top to bottom. A broad rule earlier in the list may match before a more specific exception.
• Check the active mode: Domain rules do not determine routing when the current Global Routing choice bypasses configuration rules.
• Check more than one destination: Do not assume that a rule for a sign-in page also covers the call’s media path.
• Keep a fallback: Preserve the existing configuration and make temporary test edits in a copy when possible. Do not put rules after FINAL and expect them to take effect.

If your test shows that a destination is not matching as expected, inspect the request information available in Shadowrocket and compare the matched policy with the active rule order. Avoid adding broad rules for an entire work domain just to fix one call symptom: that can redirect unrelated services and make it harder to find the actual cause.

6. Adapt the test to home, cellular, and office networks

Home broadband, mobile data, and office Wi-Fi have different constraints. Keep a separate baseline for each one instead of assuming that a setting that works at home will behave identically elsewhere. A result on one network can help isolate the cause, but it does not guarantee that the same destination, UDP behavior, or proxy route is available on another.

If a meeting works on cellular but fails on office Wi-Fi, that points toward a difference in the network path or its policies; it does not prove that the proxy configuration is wrong. If direct traffic works at home but a proxy route fails everywhere, check the selected entry and its supported transport. If both routes fail only on one network, resolve access or network restrictions with the network administrator or service provider before adding more rules.

For mobile data, repeat a test while stationary so changes in signal do not obscure the comparison. For home broadband, pause large uploads or downloads during a baseline call, then repeat under normal household conditions if that reflects how the connection is usually used. For office Wi-Fi, use only routes and settings permitted by your organization. The goal is a reliable, policy-compliant call—not routing every work request through the same path.

After testing, keep the simplest configuration that meets your needs and restore any temporary changes that did not improve calls. If only one destination fails, investigate its matched rule and the network path rather than replacing every setting. A stable baseline, one change at a time, and a real call test provide a more dependable basis for remote-work routing than a latency number alone.