Stable work calls depend on more than a fast proxy node. Zoom, Slack, and Google Meet may use real-time UDP traffic that a browser-style system proxy does not capture, while local services are often better reached directly. This guide explains how to choose a routing plan in v2rayN, verify the local proxy and UDP path, and keep local sites on a direct route. It also covers the limits of system-proxy mode and practical checks for v2rayNG on Android.
Plan the Traffic Path Before Changing Settings
Start by deciding which traffic should use the proxy, rather than switching the entire computer to global mode. For many remote-work setups, a useful default is to let local work sites and ordinary domestic destinations connect directly, while sending selected international destinations through the proxy. Calls need a separate decision: if the network can reach the meeting service directly with a stable UDP path, direct routing may reduce detours; if the service is unreachable or unreliable on the local network, a proxy may help only when the app’s traffic can actually enter the proxy core.
v2rayN manages profiles, routing configuration, system-proxy settings, and the selected core. The V2Ray or Xray core handles connections that reach it. These are distinct layers. Turning on the system proxy usually affects applications that follow the operating system’s HTTP or SOCKS proxy settings; it does not automatically capture every connection made by every desktop app. Some call applications use their own network stack or establish UDP media connections outside the ordinary system proxy.
Before applying a rule, identify the entry point. With system-proxy mode, confirm that the application follows the configured proxy. With TUN mode, traffic is captured at the network-adapter layer, but the operating system may require elevated permission, and DNS and route behavior need to be checked. TUN is not a guarantee that every protocol will work: the core, outbound protocol, and node must all support the traffic being carried.
Port 10808 is a common example, not a universal default. In v2rayN, open “Settings” → “Parameter settings” and check the actual local listening ports. Then compare them with the core startup log. If the application has its own proxy field, use the protocol and port it explicitly supports; do not assume that an HTTP proxy port and a SOCKS port are interchangeable.
Choose a Routing Policy for Meetings and Local Sites
There is no single route that is best for every call. A meeting may use signaling over TCP or HTTPS while its audio and video use separate UDP flows. If those UDP packets are blocked, misrouted, or unsupported by the selected proxy path, a call can connect but have poor audio, delayed video, or repeated fallback behavior. Conversely, routing all traffic through a distant node can add latency even when the local connection already provides a good path.
| Traffic | Starting route | What to verify | Common mistake |
|---|---|---|---|
| Local company portal and intranet | Direct, if the service is intended for local access | Confirm the domain resolves to the expected network and the page opens without the proxy | Sending private or local addresses to a remote node unnecessarily |
| Zoom meeting signaling | Direct or proxy according to reachability and company policy | Check whether the client can sign in and join a test meeting on the chosen route | Assuming successful sign-in proves that media traffic uses the same route |
| Zoom audio and video | Prefer a working direct UDP path when available; test a proxy path only if UDP is supported end to end | Check call quality, packet-loss indicators, and whether the core logs show the expected outbound | Assuming system-proxy mode captures all UDP media |
| Slack messages and huddles | Route according to the actual app behavior and network policy | Test messages separately from a huddle; they may use different connections | Using a successful text-message test as proof that voice traffic works |
| Google Meet | Direct when reachable and stable; otherwise test a supported proxy or TUN route | Join a test call and check audio, video, and connection diagnostics | Expecting a browser proxy setting alone to handle every media flow |
Service endpoints and port requirements can change by product, region, client version, and organization policy. Use the current Zoom, Slack, or Google Meet network guidance when a firewall rule must be precise. For a first diagnosis, avoid building a large list of guessed domains or ports. Record the app version, the route mode, the selected node, and whether the issue affects sign-in, chat, or live media. That makes it easier to isolate whether the problem is DNS, a route match, UDP handling, or the local network.
Choose a route based on the network, not the app name alone
Local network is healthy
- Keep company intranet and local sites direct
- Test meeting audio and video on the direct route
- Use the proxy only for destinations that need it
Direct access is unreliable
- Check whether the app follows the system proxy
- Test TUN only when its permissions and routes are understood
- Confirm the core and node support the required UDP traffic
Change one route at a time and compare the same meeting under the same network conditions.
For direct access to local sites, use the routing rules provided by the client or the active core configuration. Depending on the version and rule set, this may mean choosing a direct or bypass routing preset, or adding a specific domain or IP rule. Check rule order: a broad proxy rule placed above a local direct rule can make the latter ineffective. Avoid relying only on an IP address when a service uses changing addresses or a shared content-delivery network; a maintained domain rule is usually easier to reason about.
Configure and Test the Route in v2rayN
Use a short, repeatable test rather than changing several settings at once. The menu labels below describe common v2rayN workflows; wording and placement can vary between releases and between WPF and Avalonia interfaces. If a menu differs, check the current client version and core log instead of applying an old screenshot literally.
-
Record the baseline
Note the v2rayN version, selected core, active node, routing mode, and whether TUN is enabled. In “Settings” → “Parameter settings,” record the local HTTP and SOCKS listening ports. Close or pause other proxy clients so they do not compete for the same ports or system-proxy setting.
-
Check the listener
Start the core and inspect the startup log for the local listener address and port. If the example listener is
127.0.0.1:10808, use that only if the log confirms it. A port conflict or a listener bound to a different address can make a valid node appear unusable. -
Set local access
Choose a routing preset that sends intended local destinations through the direct outbound, or add a narrow direct rule for a known company domain. Keep the rule above any broader rule that would otherwise proxy the same destination. Test the local portal in a fresh browser tab and confirm that it remains reachable.
-
Test one meeting
Start with one app and one route. Join a short test call, check both audio directions, then check video. If signaling succeeds but media fails, do not immediately change the node: verify UDP handling and whether the app’s media connection reached the core at all.
-
Compare and revert
Repeat the test using the alternative route while keeping the device, network, app, and meeting conditions as similar as possible. Record the result, then restore the better-known working configuration. Do not leave TUN, global routing, or a broad firewall exception enabled just because one test call improved.
For a basic TCP proxy check on Windows, use the actual local HTTP proxy address and port shown by v2rayN. For example, if the verified listener is 127.0.0.1:10809, a request can be tested with:
curl.exe -x http://127.0.0.1:10809 https://example.com/ -IThis confirms that a command-line request can use that HTTP proxy; it does not test Zoom, Slack, Google Meet, or UDP media. A browser may also have its own proxy configuration, and a desktop app may ignore the operating-system proxy. Use the app’s connection diagnostics and the core log to determine whether its traffic is entering the expected route.
If you test TUN, first make a note of the original system-proxy and routing settings. Enable the feature using the controls available in your v2rayN version, approve the required permission, and verify that the TUN interface appears active. Then test local DNS resolution, the company portal, and one meeting app. If local services stop working, inspect DNS and routing rules before adding broad bypasses. Disable TUN to return to the previous baseline when the test is complete.
Check UDP, DNS, and Common Failure Patterns
UDP is a frequent point of confusion because “the proxy is connected” says little about how a live call’s media flows. A system proxy is generally designed around proxy-aware application connections, commonly HTTP or SOCKS traffic. It is not a universal UDP tunnel. Whether UDP can pass through a proxy depends on the app’s behavior, the local entry method, the core configuration, the outbound protocol, and the remote server. TUN can capture more network traffic, but it still cannot make an unsupported outbound carry a flow it does not support.
Zoom joins, but audio keeps cutting out. What should I check first?
Compare a short test call on the direct route and the proxy route. Check Zoom’s call diagnostics for packet loss and verify whether the core reports the media connection. If only the proxy route fails, confirm UDP support across the full path before changing DNS or switching nodes.
Slack messages work, but a huddle does not. Are they using the same connection?
Not necessarily. Messaging and real-time audio can use different connections. Test a huddle separately, check the app’s network diagnostics, and confirm that the route captures its media traffic rather than inferring call support from successful text messages.
Google Meet works in a browser, but the desktop app behaves differently. Why?
The browser and desktop app may use different proxy settings or network paths. Check the browser’s proxy configuration, the desktop app’s documented proxy behavior, and whether either test uses TUN. Compare the same meeting with one entry method at a time.
Local company sites stopped opening after I changed routing. How do I undo it?
Restore the previous routing preset, then inspect rule order and DNS resolution for the affected domain. Add a specific direct rule only after confirming the intended destination. Avoid disabling all routing or sending every private address to a remote node as a permanent fix.
DNS can also make a correct-looking rule behave unexpectedly. A domain rule requires the core to know the domain associated with a connection; if the app resolves a name separately or the core sees only an IP address, the expected domain match may not occur. Use the core’s supported DNS and sniffing options only when you understand their effect, and change one option at a time. For internal company names, preserve the DNS behavior required by the organization rather than forcing all lookups through a public resolver.
Use this symptom-to-check mapping before rebuilding the profile:
| Symptom | Likely area | Next check |
|---|---|---|
| App cannot sign in, but browser access works | App-specific proxy behavior or DNS | Check whether the app follows system proxy settings; compare its documented proxy options |
| Meeting connects, but audio or video fails | UDP path, packet loss, or media route | Check app diagnostics and core logs; compare a direct path with a verified UDP-capable path |
| Local portal opens only when the proxy is off | Routing rule order or internal DNS | Inspect the matching rule and name resolution; add a narrow direct rule if appropriate |
| Every app loses connectivity after enabling TUN | Permission, adapter, DNS, or default route | Disable TUN, restore the baseline, then review the core log and operating-system routes |
| Call quality changes from one meeting to another | Network congestion, Wi-Fi quality, or service-side relay selection | Repeat tests on a stable connection and compare packet-loss diagnostics, not just node latency |
When logs show a connection attempt, note the destination, protocol, and selected outbound. Do not publish logs containing subscription links, UUIDs, passwords, or internal hostnames. If the logs show no corresponding app connection, the likely issue is before core routing: the app may be bypassing the system proxy, or the selected entry point may not capture its traffic.
Apply the Same Principles to v2rayNG
On Android, v2rayNG uses the platform VPN interface to capture traffic according to its available settings. That is different from relying on a desktop system proxy. Choose the intended per-app or global VPN behavior in the app, then test the work application itself. A profile that connects successfully does not prove that every app is included in the VPN route or that its UDP media is supported by the node.
- Confirm that v2rayNG is connected and that Android shows its VPN indicator.
- Review per-app routing or bypass settings if the build provides them; ensure the meeting app is not excluded by mistake.
- Test local company access separately from Zoom, Slack, or Meet. A local service may need direct access or organization-specific DNS.
- Keep the phone on a stable Wi-Fi or mobile-data connection during comparison, and avoid changing networks in the middle of a call test.
- If calls stop when the screen locks, review Android battery-optimization and background-activity settings for v2rayNG.
For both desktop and Android use, keep a known working configuration and change only one variable per test: route mode, TUN/VPN capture, node, or DNS behavior. A quick latency number cannot predict call quality; packet loss, jitter, UDP reachability, and the path to the meeting relay matter as well. When direct access works reliably, preserve it for local services. Use a proxy only where it solves a demonstrated reachability or policy problem, and verify that the application’s real-time traffic follows that route.