This guide helps remote workers route Zoom, Slack, and Google Meet through a selected proxy while leaving ordinary local browsing direct. It covers v2rayN routing rules, the difference between system proxy and TUN capture, UDP checks for calls, and a repeatable way to test each change. Domain examples are starting points, not a permanent service inventory: confirm the traffic your own apps use before broadening any rule.
Plan the traffic split before changing v2rayN
v2rayN manages server profiles and starts a proxy core such as Xray or V2Fly; the core handles connections according to its active configuration. A routing rule does not create a connection by itself. It matches traffic that has already reached the core, then selects an outbound such as a proxy or direct connection. This distinction matters for remote-work apps: a domain rule cannot help an application that sends traffic outside the capture path.
Decide what “local browsing stays direct” means for this computer. In this guide, ordinary traffic uses the direct outbound, while traffic matching the work-service rules uses the selected proxy outbound. Local network destinations should also remain direct where appropriate. If your organization requires a specific corporate VPN, DNS resolver, or egress location, follow its policy; a personal routing rule is not a replacement for workplace network instructions.
Do not assume that “the browser works” proves a meeting app is routed correctly. A browser may honor the operating system’s HTTP proxy settings, while a desktop app may use its own networking stack or establish media connections over UDP. You need to verify both the route and the type of traffic used during an actual call.
Check whether the app traffic reaches the core
Start with the least invasive capture method that covers the applications you use. With system proxy enabled, applications that honor the operating system’s proxy settings can use v2rayN’s local proxy. A common local mixed port is 10808, but the client may use a different value or separate HTTP and SOCKS ports. Read the active port in v2rayN instead of copying an example into another program.
System proxy is not a universal packet tunnel. Some applications use their own proxy configuration, connect directly, or need UDP for real-time audio and video. If a test shows that the app bypasses the intended route, TUN mode may capture more network traffic at the IP layer. TUN generally requires the necessary permissions and a compatible virtual network interface or driver. It can also affect DNS handling, local network access, and other applications, so enable it only when needed and test the resulting routes.
Use it when the browser and work apps honor the operating system proxy, and confirm that the client’s local listener is active. It is simpler to audit and usually avoids capturing unrelated applications.
Suitable for: initial checks and proxy-aware apps
Use it when an app bypasses system proxy settings or its UDP traffic is not entering the core. Confirm permissions, DNS behavior, local routes, and UDP support before relying on it for calls.
Suitable for: apps needing broader traffic capture
Change one capture method at a time. If you enable TUN, verify that ordinary local destinations still use the direct route and that local services such as printers or company resources remain reachable. If the connection breaks, turn TUN off and return to the last known working configuration before investigating a different setting.
Add narrow service rules and preserve direct browsing
Routing rules are evaluated by the core according to its configuration and rule order. A specific work-service rule must be able to match before a broad rule that sends the same traffic direct. Conversely, a default proxy rule placed ahead of a work-service direct rule would defeat the intended split. In v2rayN, open the routing settings or rule-management screen for the active configuration; menu labels and available rule editors vary by version and selected core.
For Xray-style domain matching, entries such as domain:zoom.us or domain:slack.com commonly represent a domain and its subdomains. The exact rule syntax depends on the core and the editor. Add the relevant domains to the proxy outbound, keep the ordinary default route direct, and ensure that the matched rule points to the outbound tag the active configuration actually defines. A misspelled or nonexistent outbound tag can prevent the configuration from starting or make the rule ineffective.
| Service | Possible starting domains | Routing note |
|---|---|---|
| Zoom | zoom.us, zoom.com, zoomcdn.com |
Test sign-in, meeting control traffic, and media separately; the app may use additional hosts. |
| Slack | slack.com, slack-edge.com, slack-files.com |
Check messages, file access, and calls; do not assume one domain covers every feature. |
| Google Meet | meet.google.com, google.com |
Authentication and media may involve other Google domains or changing infrastructure. |
These domains are examples to validate, not a guarantee that every feature will match them. Providers can change hostnames, use content-delivery networks, or share infrastructure between products. Avoid adding a broad rule for all of google.com merely to make Meet work: it may route unrelated Google services through the proxy and make the split harder to reason about. Prefer the narrowest domains that your logs and tests show are necessary.
Rule order and default behavior deserve a deliberate check. If the active configuration has a final catch-all rule, confirm that it selects the direct outbound. If the client offers named routing presets, inspect the generated or active rules rather than assuming a preset has the same behavior in every version. Keep a copy of the original routing setup before editing, especially if a subscription update or profile change can replace client-managed rules.
Configure and test in a controlled order
Use this sequence to separate subscription problems, rule mistakes, and capture limitations. The steps refer to common desktop v2rayN controls; translations and menu placement can vary. Keep the existing working node and configuration available so you can roll back without guessing which change caused a failure.
-
Confirm the node
Select a known-working server and confirm the core starts without configuration errors. Open a browser with the current system proxy setting and check one ordinary test page before changing routes.
-
Check listeners
Open the client’s settings or local-port display and record the active HTTP, SOCKS, or mixed listener. If a work app offers its own proxy field, use the actual address and port shown there; do not assume
10808applies to your setup. -
Add work rules
In the active profile’s routing settings, add only the service domains needed for your first test and assign them to the configured proxy outbound. Check that the rule appears before any broad matching rule that would send the same traffic direct.
-
Keep a direct default
Confirm that unmatched ordinary traffic uses the direct outbound. Preserve any required local-network or private-address direct rules, and avoid changing DNS, TUN, and outbound selection all at once.
-
Test one app
Start with one service, perform a real sign-in or test call, and review the core log or connection view for the matched domain and chosen outbound. Record what worked before adding rules for the next app.
Repeat the test on the same network, node, and device after each change. Try one ordinary local website as a control, then test a work-service action such as loading a Slack file or joining a Meet call. If the control site unexpectedly uses the proxy, revisit the catch-all rule and rule order rather than adding more work-service domains.
Verify UDP support for voice and video
Web pages and sign-in flows often establish TCP connections, but real-time media may use UDP when the network and application permit it. A successful sign-in therefore does not prove that the audio and video path is healthy. The client core, selected proxy protocol, remote server, and network path must all handle the relevant traffic. A route rule matching a domain cannot make an unsupported UDP path work.
Separate the control path from the media path
Control and sign-in
- Check that the app can sign in and load its meeting or chat interface.
- Look for the service domains in the core’s active connection view or logs.
- Confirm that the matching traffic uses the intended proxy outbound.
Audio and video
- Join a test call and check for stable two-way audio and video.
- Confirm whether TUN is needed to capture UDP from that application.
- Check core and protocol support before attributing call problems to routing.
A working web interface confirms only part of the path; validate a real call before treating the setup as complete.
For a controlled test, join a short meeting, speak in both directions, and observe whether audio drops, video freezes, or the app reports a network-quality warning. Compare the same test with the proxy disabled only if workplace policy permits and the connection is safe to use. Do not expose account credentials or meeting details when sharing logs; connection records can reveal hostnames and other sensitive information.
If the call connects but media fails, first confirm whether the app’s UDP packets enter the core. Review the client’s connection display or diagnostic logs during the call, then verify that the chosen core and outbound can handle the observed traffic. If the app uses a direct UDP path outside system proxy capture, test TUN with the required permissions and recheck local routing. Do not respond by proxying every destination: that can hide the real capture issue and send unrelated traffic through the remote server.
Troubleshoot from observable symptoms
Use the symptom to choose the next check, and change one setting at a time. Logs are most useful when collected during a reproduction: start the app, perform the failing action, note the time, then inspect the corresponding connections. An empty list is not proof that no traffic exists; it may mean the app bypasses the current capture method or that the view is filtered.
“The browser works, but Zoom still connects directly.”
Check whether Zoom honors the operating-system proxy. Inspect active connections during a meeting; if its traffic does not reach the core, test the client’s supported TUN mode and then verify the domain and outbound rules.
“Slack messages load, but files do not.”
Check the core log while opening one file and note the destination domain and route. Add a narrowly scoped rule for a confirmed Slack file host only if it is missing, then retest without widening the rule to unrelated services.
“Meet joins, but the audio keeps cutting out.”
Test a real call while checking UDP capture, TUN status if required, and the selected core’s support for the traffic. Compare one variable at a time; a successful TCP page load does not establish that the media path works.
“Local websites are using the proxy too.”
Review the final catch-all route and rule order. Confirm that unmatched traffic points to the direct outbound and that local or private destinations have not been placed behind a broad proxy rule.
When a rule seems ineffective, verify four items in order: the app’s traffic reaches the core; the observed hostname matches the rule syntax; the rule is evaluated before conflicting rules; and its outbound tag exists in the active configuration. If all four are correct but the result differs, check whether the app reused a connection opened before the rule change. Fully quit and restart the app, then repeat the same test.
Keep a short change record with the active core, capture method, rule added, test action, and result. This is more useful than changing several settings and later trying to reconstruct what happened. If a subscription or profile update changes the generated configuration, repeat the basic direct-versus-proxy checks before relying on the setup for a scheduled meeting.