Zoom, Slack, and Google Meet can use different network paths, and a working web proxy does not prove that a meeting’s UDP media is being proxied. This guide shows how to build a selective routing policy in v2rayN, keep local services and private networks direct, check whether your core and node can relay UDP, and test calls without routing every app through a proxy. Menu names vary between v2rayN builds, so verify the corresponding routing and core settings in your installed version.
Plan the traffic path before changing rules
Reliable calls depend on more than selecting a server. The conferencing app must first send traffic to a path that v2rayN can handle. The core then applies routing rules, chooses a direct or proxy outbound, and forwards the traffic using the capabilities of the selected node. If any one of those stages is missing, a browser test may succeed while call audio, screen sharing, or reconnects fail.
Start by deciding what you actually need to proxy. If the goal is to reach a meeting service that is unreliable on the direct connection, route only the service traffic that needs another path. Keep private address ranges, office VPN destinations, printers, and local DNS services direct. Avoid a global route as the first troubleshooting step: it can send unrelated work tools and local services through the remote node, making it harder to identify the source of a call problem.
Selective service routing
- Policy
- Match the meeting-service domains
- Outbound
- Proxy for matching traffic
- Local range
- Direct for private destinations
- Best first test
- One service and one call
Use this when only selected services need a different route and the app’s traffic reaches the core.
Broader IP capture
- Entry point
- TUN, where supported
- Traffic type
- More IP traffic, including UDP
- Outbound
- Must support UDP relay
- Extra checks
- DNS and route exclusions
Use only when the app bypasses the system proxy or its media traffic is not otherwise captured.
In common v2rayN configurations, local SOCKS and HTTP listeners are often on ports 10808 and 10809, respectively. Treat those as values to check, not guaranteed defaults: a profile or user setting may change them. A system proxy usually helps applications that honor system proxy settings, but support for UDP varies. A TUN interface can capture a broader range of IP traffic, but it does not make an unsupported outbound or server relay UDP automatically.
For a first pass, collect four facts before editing anything: the v2rayN build and selected core, the local listener ports, whether TUN is enabled and permitted if you need it, and whether the selected node supports UDP forwarding. Record the current routing mode and export or back up the existing configuration if the client offers that option. This gives you a known baseline and a way to undo a change that affects unrelated work traffic.
- Applications: Note whether Zoom, Slack, or Meet is a desktop app or running in a browser. Each may use different proxy and network behavior.
- Network: Check whether a company VPN, firewall, or managed DNS service is active. Those can take precedence over local routing changes.
- Symptoms: Distinguish sign-in failure, call setup failure, missing audio, and choppy video. They do not point to the same layer.
Configure selective routing in v2rayN
First confirm that a normal connection through the selected node works. Then open the routing settings in v2rayN and inspect the active routing profile. The exact menu wording and layout vary by build; look for the area labeled Routing, Routing settings, or rule management rather than changing the subscription itself. A subscription update typically refreshes server information and does not necessarily replace a locally selected routing profile.
Routing rules are generally evaluated in order, with the first matching rule deciding the outbound. Put explicit local or private-network exclusions before broader rules, then put the meeting-service rules before a final catch-all rule. A rule that sends all traffic direct or all traffic through the proxy can override the selective behavior you intended, depending on its position. After editing, check the rule order and the chosen outbound for each rule, not just the visible domain text.
-
Check the core
Open v2rayN’s core or settings area and confirm which core is selected and running. Record the build shown in the client and check the core log for startup errors before testing a call.
-
Open routing
In the main window or settings menu, open the routing rules or routing settings page. Select the profile you intend to use and note whether it is a preset or a custom rule set.
-
Keep local direct
Add or retain direct rules for private IPv4 and IPv6 destinations, such as the private ranges represented by
geoip:privatewhen supported. Preserve any company network, intranet, printer, or local DNS exclusions required by your environment. -
Match services
Add narrow domain rules for the service you are testing and direct those matches to the proxy outbound. Use the domain-matching options supported by your selected core, such as an exact domain or a suffix match, rather than assuming every rule editor accepts the same syntax.
-
Check UDP
If media traffic must use the proxy, verify that the active inbound path captures UDP and that both the core and selected node can relay it. Enable TUN only if needed, then approve its network permission and review its DNS and route exclusions.
-
Apply and test
Save or apply the profile, restart the core if the build requires it, and test one meeting service. Check the logs and call statistics before adding another application or broadening the rules.
For domain targets, start with the service’s primary domains and add related domains only when logs or the provider’s current network guidance show that they are required. Possible starting points include zoom.us and zoom.com for Zoom, slack.com for Slack, and meet.google.com for Google Meet. A service may also use separate domains for authentication, static assets, file transfers, signaling, or media. Domain lists change, and a single listed domain does not guarantee that every call flow is covered.
Be cautious about adding broad domains such as google.com, googleapis.com, or googleusercontent.com to a proxy rule just to make Meet work. Those domains can serve many unrelated products. A broad rule may unintentionally proxy other work services, increase latency, or make the cause of a routing problem less clear. Add a wider match only when a test demonstrates that it is needed and your policy allows it.
Domain routing also has limits when the client sees only an IP address. Depending on the capture method, DNS handling, and core settings, the destination domain may not be available when the rule is evaluated. If a domain rule appears correct but never matches, inspect the core log and verify the DNS path before adding more patterns. Do not treat a successful DNS lookup as proof that the subsequent media connection used the intended outbound.
Verify UDP and call quality with controlled tests
Web pages, sign-in screens, and chat messages often use TCP-based HTTPS and can work through a conventional local proxy. Real-time audio and video commonly use UDP when the network permits it, often through WebRTC-related transport. If UDP is blocked, the app may fall back to TCP or another supported path, but the fallback can have different latency and quality. Therefore, opening a meeting page is not a sufficient test of proxy support for a call.
UDP forwarding is a chain, not a single checkbox. The application must send traffic through a capture path that can carry UDP; the local inbound and core must accept it; the routing rule must select the intended outbound; and the remote node or server must relay it. A SOCKS listener configured only for TCP, an HTTP proxy setting, or a server that does not forward UDP can break that chain even when ordinary browsing works. A test tool that reports the local port as open cannot establish that an end-to-end UDP media path is available.
| What you test | What a pass tells you | What it does not prove |
|---|---|---|
| Open the service website | At least one web request can reach the service | That call media or UDP uses the same route |
| Start a voice call | Signaling and at least one audio path are working | That video, screen sharing, or reconnects are stable |
| Check core logs | The core may show a matched rule, outbound, or connection error | That the remote network has acceptable loss and latency |
| Compare direct and proxy calls | Whether the changed route appears to affect the symptom | That one short test represents every network or meeting |
Test one variable at a time. Close the meeting app completely, apply the routing change, reopen it, and make a short voice call. Note the time, selected node, routing mode, whether TUN is active, and whether the call is using the desktop app or a browser. If voice works but video or screen sharing fails, check whether those features use additional destinations and whether the call is falling back to a different transport. Avoid changing the node, DNS settings, route rules, and system proxy all at once; that makes the result difficult to interpret.
Check the call’s own network diagnostics if the app provides them. Look for transport type, packet loss, round-trip time, and whether the connection is relayed or direct. These diagnostics are more useful than a speed test that measures a separate TCP download. As a practical comparison, repeat the same short test once with the selective proxy rule and once with the original route, on the same network and as close together in time as possible. Meeting load and Wi-Fi conditions can change, so a single result is not a controlled benchmark.
Use the call itself as the test
If sign-in and chat work but audio drops when the call begins, stop expanding domain rules. First confirm that UDP reaches the core and that the selected outbound and remote node support UDP relay; then compare the app’s call diagnostics with the core log for the same test time.
For UDP port checks, treat port numbers as clues rather than a universal allowlist. Zoom and other real-time services can use UDP for media, and common deployment guidance may mention ranges such as 3478–3481, but actual requirements depend on the service, client, network, and current provider documentation. Do not assume that opening or proxying one remembered port covers every conferencing feature. If you administer a firewall, consult the current service requirements for your account and network, then test the specific traffic that the call diagnostics identify.
Keep work and local services reliable
Split tunneling is useful only when its boundaries are deliberate. Keep office intranet hostnames, private address ranges, local discovery, printers, and any company VPN destinations on the required direct or corporate path. If a corporate VPN is active, do not change its routes or DNS settings to solve a consumer proxy issue without approval. Managed devices may enforce routing policies that take precedence over v2rayN.
Avoid using a global proxy route as a permanent fix for one meeting service. It may route software updates, cloud storage, identity providers, and internal tools through the node, even when they were working directly. It can also increase round-trip time for a nearby service or create a route conflict with another VPN. If you temporarily use a broader route to diagnose a failure, record the original setting and restore it after the test.
Use the core log as evidence, but protect it. Logs can contain destination domains, IP addresses, or other network details. Review the lines around the time of a failed test for the matched rule, chosen outbound, DNS result, and errors such as a failed connection or unsupported UDP operation. Redact private details before sharing a log with an administrator or support team. A message indicating a rule match confirms a routing decision; it does not prove that the remote service accepted the connection.
“The meeting page opens, but calls keep dropping. What should I check?”
Check the call diagnostics and core log at the same time. Confirm that the app’s media traffic reaches a UDP-capable inbound and that the selected node relays UDP; then test one call with the original route for comparison.
“Should I add every Zoom or Google domain to the proxy rule?”
No. Start with narrow service domains, inspect which destinations are missing during a test, and add only the required matches. Broad shared domains can route unrelated work traffic.
“Do I need TUN for every call?”
No. First test the application’s existing system-proxy behavior. Consider TUN when the app bypasses that proxy or the required traffic is not captured, and verify permissions, DNS, exclusions, and UDP relay before relying on it.
When the route is stable, keep a short record of the working setup: v2rayN build, selected core, node, local ports, routing profile, TUN state, and any service-specific rules. Recheck after changing a core, subscription, VPN, or network because those changes can affect DNS, UDP relay, or rule matching. If a future update causes a regression, temporarily restore the recorded baseline and test again before replacing the full configuration.