A reliable Zoom or Teams meeting depends on the whole path between your device, Shadowrocket, your selected server, and the meeting service—not just a low latency-test result. This guide is for people who already have their own connection details and want to organize work traffic on an iPhone or iPad. It explains how to compare connection behavior, check whether UDP can pass through the chosen route, use Config rules carefully, and test a real call without assuming that one server or rule set works for every office and network.
1. Define what “reliable” means before changing routing
A video call has several requirements that a basic connection check cannot measure at once. The app must reach its sign-in and meeting services, media packets must travel with acceptable delay and loss, and the route must remain usable as you move between Wi-Fi and cellular. A page loading successfully or a VPN status showing Connected confirms only part of that picture. Neither proves that audio, video, screen sharing, and meeting controls will all work reliably.
Start by separating the possible causes. If you cannot sign in, the issue may be account access, DNS, or a service endpoint. If sign-in works but audio is one-way, media transport or the network path may be involved. If the call works until you share a screen, the problem could be specific to that media flow or to a change in network conditions. Record what fails and when before editing rules; otherwise, several simultaneous changes can make the result hard to interpret.
Also distinguish the app purchase from network access. Shadowrocket is a paid Apple-platform app, obtained through the App Store; buying it does not provide a server or subscription. This guide assumes you already have your own service and connection details. This site does not provide, sell, or recommend servers or subscriptions. Before purchasing, verify the developer, Shadow Launch Technology Limited, and app ID 932747118. Check the App Store listing for current compatibility and system requirements.
- Connection status: Shows whether Shadowrocket has established its local VPN connection on the device; it is not a guarantee that every remote service is reachable.
- Latency test: Helps compare response time to a selected destination. It is not a measurement of call jitter, packet loss, or microphone and camera quality.
- Meeting test: A short real call is the practical check for audio, video, and screen sharing on the network you actually plan to use.
2. Check the server path and UDP behavior
Zoom and Teams use multiple network services for sign-in, meeting setup, and real-time media. HTTPS traffic commonly uses TCP port 443, but a call may also use UDP for media when the app and network can establish that path. The exact destinations and ports depend on the service, its current configuration, and the meeting environment. Do not treat one remembered port list as universal, and do not open broad access or add speculative rules simply because a call is unstable.
In Shadowrocket, first confirm that the entry selected under SERVER is the one you intend to test. Check its address, port, protocol, and other supplied connection parameters against your own provider’s current details. A name in the list is not proof that the entry is current or correctly configured. If your connection details describe a protocol or transport option that the entry does not match, resolve that mismatch before trying to tune meeting rules.
Latency results are useful as a comparison, not a verdict. Test the same selected entry more than once under similar conditions, and note whether the result varies substantially. A consistently lower response time can be a reasonable starting point, but a small difference in the test does not predict call quality. A route with slightly higher latency may work better if it has less packet loss or supports the media transport your meeting needs.
- Run a test on your normal Wi-Fi, then repeat on cellular if you expect to join meetings there.
- Compare the same server entry and test destination; changing both at once makes the results difficult to interpret.
- During a meeting test, check two-way audio first, then video, then screen sharing. Note the first feature that fails.
- If the meeting app reports network or media diagnostics, use those results alongside Shadowrocket’s test rather than substituting one for the other.
UDP support is an end-to-end property of the route, not a label that can be confirmed by a low latency number. The selected protocol, remote server, transit network, local Wi-Fi, and the meeting service all affect whether media packets can pass. If your provider’s documentation describes UDP availability or restrictions, use that information to choose among your own available entries. If the route cannot carry the required media, changing a domain rule alone will not create UDP support.
Practical decision: let a real call decide between close test results
If two entries have similar latency, run the same short meeting on each and compare two-way audio, freezes, and recovery after briefly switching networks. Prefer the entry that performs consistently in your actual work conditions, not simply the one with the smallest single test result.
3. Choose a routing mode that matches the workday
Global Routing determines how Shadowrocket handles traffic at a broad level. For an existing configuration that contains rules and policies, Config is usually the appropriate starting point for split routing. Proxy sends traffic through the proxy policy broadly, while Direct bypasses that policy. Those modes are useful for controlled diagnosis, but they are not substitutes for verifying the configuration and the selected server.
When testing a meeting, write down the current Global Routing selection and keep it unchanged during the first test. If you switch from Config to Proxy or Direct, you have changed the route for many apps at once. That can show whether the broader route matters, but it will not tell you which specific meeting domain or media connection caused the original problem. Return to the intended everyday mode after any temporary comparison.
Applies the selected configuration’s rules and policies, allowing work traffic to be routed separately when the rules support that design.
Best for: everyday use with an existing, understood rule set
Uses the proxy policy broadly, which can help as a short, controlled comparison when a Config rule may be affecting the result.
Best for: temporary diagnosis, not an automatic fix for UDP issues
Connects directly rather than using the proxy policy. Whether a meeting works this way depends on the local network and service availability.
Best for: a brief comparison where direct access is permitted and available
A successful test in Proxy but not Config suggests that the configuration’s routing decisions deserve review; it does not prove that every meeting request must use Proxy. A successful Direct test may indicate that the proxy route or its rules are involved, but the direct path may not be suitable or permitted on another network. Treat these tests as controlled clues, not universal recommendations.
4. Configure work traffic without guessing at service domains
For split tunneling, the goal is to send the necessary work requests through the intended policy while leaving unrelated traffic under the rest of your configuration. The challenge is that a meeting app does not necessarily use just one domain. Authentication, meeting setup, content delivery, diagnostics, and real-time media can involve different endpoints. Some services also use changing or shared infrastructure. A rule for a single familiar hostname may therefore leave part of the app on a different route.
Before editing Config, identify the active configuration and preserve a copy of its current contents. Check whether its rules already include the work services you need and how unmatched requests are handled. Rules are evaluated in order, so an earlier broad match can determine the policy before a later, more specific line is reached. Keep the existing fallback behavior unless you understand why it should change. Do not replace an entire configuration with a few example rules: doing so may remove DNS settings, policies, or other required sections.
Use the official network requirements supplied by your workplace or meeting-service administrator to identify the current destinations and transport requirements. This is especially important for managed work accounts, enterprise networks, and environments that use organization-specific security controls. Do not copy random address lists into a configuration or route a large shared domain family through a different policy without checking what else uses it.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTThis is a syntax illustration only. example.com is not a Zoom or Teams endpoint, and the snippet is not a complete work configuration. In a real rule, replace the example only with a domain that your organization’s current requirements identify and that is appropriate to match. Preserve your own configuration’s intended fallback instead of mechanically adopting FINAL,DIRECT.
| Observation | What it may indicate | Next check |
|---|---|---|
| Sign-in fails before a meeting starts | Authentication, DNS, or service access may be affected | Check account access and the organization’s current endpoint requirements |
| Sign-in works, but audio is one-way | The media path or transport may differ from the sign-in path | Check the meeting diagnostics and whether UDP is available on the selected route |
| Meeting works in Proxy but not Config | A rule, policy, or fallback may be changing the route | Review the selected Config and matching rule order |
| Only one Wi-Fi network fails | Local network restrictions or filtering may be involved | Compare with another permitted network and contact the network administrator if needed |
5. Make one change at a time, then test a real meeting
Use a short, repeatable test rather than changing several settings before the next call. Keep the device, meeting account, selected server, and test location consistent where possible. If you must change networks, record that change because Wi-Fi and cellular can have different filtering, latency, and UDP behavior. The steps below assume your own connection details are already imported and that you are authorized to use the network and service involved.
-
Record the baseline
On Home, note the selected SERVER entry and the current Global Routing mode. Run Connectivity Test and record its result, then note the Wi-Fi or cellular network in use.
-
Check the configuration
Open Config and confirm which configuration is selected. Review its relevant rules and fallback without deleting or replacing unrelated sections.
-
Run a short call
Start a test meeting and check two-way audio, video, and screen sharing in that order. Note the first failure and any network or media diagnostics shown by the meeting app.
-
Change one variable
For diagnosis, change only one item—for example, the selected server entry or Global Routing mode—then repeat the same test. Restore your intended everyday setting after the comparison.
-
Repeat on mobile
If you work away from home, repeat the test on cellular. Confirm that the connection remains usable after the network changes; do not assume a Wi-Fi result predicts cellular behavior.
For an everyday setup, keep the tested server entry selected, use the configuration whose routing behavior you understand, and avoid leaving a temporary diagnostic mode enabled by accident. If you use Settings → On Demand, review its conditions separately from Config rules: automatic connection behavior and per-request routing answer different questions. Confirm that any automatic behavior matches your work routine, and turn it off temporarily if it makes troubleshooting harder.
A meeting that survives one short test is not guaranteed to remain stable through a long call or a network transition. If reliability matters for a scheduled meeting, join early enough to check the selected entry, route, and audio devices. Keep a permitted alternative network available where practical, and follow your organization’s guidance for confidential work traffic.
6. Interpret failures without overcorrecting
When a meeting fails, first identify whether the failure is app-wide, route-specific, or limited to one network. Then compare the same meeting flow under controlled conditions. A temporary test in another Global Routing mode can help isolate whether Config rules are involved, but it cannot by itself identify the exact domain, transport, or policy that needs adjustment. Restore the intended routing mode before returning to normal work.
Latency looks good, but the call still freezes. Why?
A latency test does not measure the complete media path or guarantee low packet loss and jitter. Check the meeting app’s diagnostics, confirm the selected server, and repeat a short call on the same network before changing a rule.
Can I assume port 443 is enough for a meeting?
No. Port 443 is commonly used for HTTPS services, but real-time media may use other transport paths. Consult your organization’s current requirements and the meeting app’s diagnostics; do not infer UDP availability from a successful sign-in.
Should every Zoom or Teams domain use the same policy?
Not automatically. The app may contact multiple service endpoints, and some infrastructure may be shared. Use current requirements from your workplace or administrator, make narrow changes, and test sign-in, media, and sharing separately.
If you see a connection error immediately after changing a rule, undo that single change and repeat the baseline test. If the issue occurs only on a workplace Wi-Fi network, ask its administrator whether meeting media traffic is restricted; a local network policy may be outside Shadowrocket’s control. If it occurs on every network and every tested route, check the meeting account, app permissions, and service status through your usual work support channels.
The practical goal is not to force all work traffic through one route. It is to make the required services reachable through a route that behaves consistently, while keeping the rest of your configuration intact. Verify the result with a real meeting on each network you rely on, document the working configuration, and revisit it when your organization changes its current network requirements.