Shadowrocket Remote Work Setup: Smoother Zoom and Teams Calls

1. Prepare for a work call before changing routing

A call that freezes or has one-way audio is not automatically a Shadowrocket problem. The cause might be weak Wi-Fi, a captive portal, a busy mobile connection, a company firewall, the remote meeting service, or a proxy route that does not carry the traffic a call needs. Establish a simple baseline before changing settings: with Shadowrocket disconnected, confirm that the device can reach the internet and that the meeting app can sign in. If your organization requires a managed connection or approved network path, follow its policy before routing work traffic elsewhere.

Write down the conditions of one test call. Note the device, network type, selected server, Global Routing mode, and whether the problem affects audio, video, screen sharing, or joining the meeting. Change one variable at a time. If you switch networks and servers while also editing rules, a better call afterward does not tell you which change helped.

• Confirm basic access: Turn the Shadowrocket connection off briefly and open a site that should work on that network. On public or office Wi-Fi, complete any sign-in page before testing a meeting.
• Record the baseline: Make a short test call with the usual network and current settings. Note whether the call connects, whether both sides can hear each other, and when any interruption occurs.
• Keep work policies in view: An organization may restrict VPN use, require a corporate VPN, or block unapproved proxy connections. Ask the administrator before changing the route for work services.
• Protect credentials: Subscription URLs and server details can contain access credentials. Do not paste them into meeting chats, public screenshots, or support posts.

Shadowrocket is available for iPhone, iPad, Mac with Apple silicon or Intel, Windows, Android, and Linux. iPhone and iPad versions cost $2.99 as a one-time App Store purchase; the other platform versions are free. App availability and installation steps are platform-specific, so use the download page for computer and Android options. App purchase does not include a connection service. This guide assumes you already have your own subscription; get its URL and connection details from your service provider. This site does not provide, sell, or recommend servers or subscriptions.

2. Understand UDP, audio, and video symptoms

Real-time meeting apps commonly use UDP for some audio, video, or screen-sharing traffic because it can avoid the delays caused by retransmitting every lost packet. The exact transport depends on the app, call type, operating system, network, and service-side decisions. A meeting may also use TCP or other fallback paths in some circumstances. Consequently, a browser test or a successful server latency check does not prove that a live call’s media path is working well.

Also distinguish the protocol used between Shadowrocket and your selected server from the protocol used by the meeting media. A proxy server may accept a client connection successfully yet fail to forward a particular UDP flow, or the network between your device and the server may restrict UDP. Support depends on the configured protocol and service. Do not assume that every node or subscription supports UDP simply because ordinary websites load through it.

• Call joins, but audio is choppy: Check signal quality, packet loss, and whether the same call works with Shadowrocket disconnected. A low or fluctuating latency result can be more relevant than a single good reading.
• Audio works, but video or sharing fails: The media components may take different paths or use different traffic patterns. Test each feature separately and avoid concluding that all meeting traffic is covered by one successful browser request.
• Only one side can hear the other: This can indicate a blocked or unstable media path, but it can also be caused by device permissions, an audio device selection, or meeting settings. Check those before editing routing rules.
• The call works on mobile data but not office Wi-Fi: The office network may impose its own firewall, DNS, or VPN policy. Do not try to bypass workplace controls; ask the administrator whether the required meeting traffic is allowed.

Use the information available in the meeting app, such as its call-health or network diagnostics, alongside Shadowrocket’s connection state. A VPN indicator only says that the local tunnel is active; it does not certify that the meeting service, authentication, DNS, and every media flow are reachable end to end.

3. Choose a routing approach for each network

Global Routing determines the broad traffic posture. Config applies rule-based routing, Proxy sends traffic through the selected proxy more broadly, and Direct avoids proxying. For everyday work, Config is usually the most controlled starting point when you have a known-good configuration. Proxy can be a useful temporary diagnostic if permitted, but it changes the path for much more than the meeting app. Direct can help isolate whether proxy routing is involved, but it may not be appropriate for services or destinations that require a particular network path.

These are test postures, not guarantees that a particular mode will improve a call. Keep the same device, meeting, server, and approximate location when comparing modes. If the call is better on one network but worse on another, retain that distinction in your notes rather than applying a change globally.

4. Run a controlled call test and adjust one setting

On iPhone and iPad, the interface labels below refer to Home, Config, and Settings. Other platforms may arrange the same functions differently. Before editing anything, make sure you can restore the original Global Routing selection and rules. If your current configuration is managed by your workplace, do not modify it without permission.

1. Record the current state

   On Home, note the selected server and whether the connection is on. In Config, note the active configuration; in Settings, review any relevant On Demand conditions. Record the network type and meeting app symptoms before changing a value.

2. Check the baseline

   Make a brief test call on the network you want to use. Confirm microphone and camera permissions, selected audio devices, and whether both directions of audio work. Use the meeting app’s call-health information if available.

3. Test the connection

   On Home, select the server you intend to evaluate and run the available connectivity or latency test. Treat the result as a check of that test destination, not as proof of call-media support. If the call uses UDP, confirm support with your provider or administrator.

4. Compare one mode

   Where permitted, compare the existing Config behavior with one temporary Global Routing alternative. Keep the meeting, device, and network as close to the baseline as possible. End the call before switching modes if the change interrupts the system VPN.

5. Retest and restore

   Repeat the same short call and record the difference in audio, video, and sharing. If the comparison does not help, restore the original mode and move to the next variable, such as another supported server or another network.

Do not make several rule edits based on one brief interruption. A momentary improvement may reflect a changing Wi-Fi channel, cellular signal, or meeting-server selection rather than the setting you changed. A useful test is repeatable: compare the same symptom more than once, and keep the original configuration available until you know the result.

5. Use split routing without relying on a brittle domain list

Split routing means rules direct some destinations through a proxy and others directly, rather than treating all traffic identically. It can be useful when a work environment requires ordinary company services to remain on the normal network while selected destinations use a proxy. But meeting apps do not necessarily send every function to one fixed hostname. Sign-in, meeting signaling, media relays, content delivery, and regional services may use different hostnames or IP addresses, and those endpoints can change.

For that reason, adding a single guessed Zoom or Teams domain to Config is not a dependable way to route every part of a call. A rule may cover the sign-in page but miss a media relay; an IP-based rule may become stale; and a broad suffix rule may route more traffic than intended. Use only rules and destinations supplied by your organization or supported by the configuration you trust. Do not copy an unverified list from a public post and assume it is complete.

• Inspect the rule order: Config rules are evaluated according to their configured order and matching behavior. A broader rule placed earlier may capture traffic before a narrower rule can apply. Review the active configuration rather than editing an unused file.
• Keep rules narrow: Change only the intended destination or policy. Avoid routing an entire company domain or a broad group of IP ranges unless the administrator has confirmed that scope.
• Account for DNS: Different DNS answers can lead an app to different service endpoints. If login works but media does not, DNS and the selected route may both deserve review.
• Do not assume per-app routing: Domain-based rules and per-application VPN controls are different mechanisms. Whether per-app control exists depends on platform and device management; do not expect a domain rule to identify every request from one app.
• Recheck after updates: A service can change its infrastructure. If an old rule stops matching, verify the current guidance from your administrator or service provider instead of expanding the rule blindly.

If you cannot determine which destination or policy should be used, pause rule changes and ask the network administrator. For a managed work device, preserving the approved Config is usually safer than trying to recreate a split-tunnel policy from memory.

6. Interpret common symptoms and keep the setup recoverable

Use symptoms to decide which layer to inspect, not to guess at a protocol change. If all apps lose access when the Shadowrocket connection starts, investigate the local connection and active routing configuration first. If web pages load but a meeting has no media, look at UDP support, firewall policy, meeting diagnostics, and app permissions. If only office Wi-Fi fails, the office network’s policy is a likely variable and should be checked with IT.

Keep a brief record of the working combination: device, network, Global Routing mode, active Config, selected server, and observed call behavior. If you need to ask for support, share the symptom and sanitized settings—not a subscription URL, password, or access token. If a change makes connectivity worse, restore the recorded mode and configuration before trying another adjustment.