This guide shows remote workers how to use v2rayN on Windows for a focused work profile: route Zoom, Slack, and Google Meet through a selected proxy path while keeping ordinary local websites on a direct connection. The workflow separates the GUI client, Xray core, local listener, application scope, and routing rules. You will first confirm the local proxy entry point, then create a work-oriented routing plan, import or verify the required rules, and test calls, messages, and browser traffic without assuming that one successful website proves every application is using the same path.
Separate the client, core, and routing scope
v2rayN is the Windows graphical client that manages subscriptions, server profiles, core selection, local proxy ports, system proxy status, and logs. It does not itself carry every application connection. The selected proxy core, commonly Xray-core in current v2rayN setups, reads the generated configuration and handles DNS resolution, routing rules, inbound listeners, and outbound connections. Zoom, Slack, Google Meet, browsers, and other applications reach that core only when their traffic is directed to a local listener or captured through a supported system-wide method.
This distinction matters during remote work because video meetings and collaboration tools do not always use the same network behavior as a normal browser tab. A browser may respect the Windows system proxy while a desktop meeting application uses its own connection logic. Slack may contact several service domains for login, messages, files, presence, and calls. Google Meet usually runs in a browser, but media traffic can involve separate hostnames and UDP behavior. Zoom can also use multiple domains and connection types for sign-in, meeting control, audio, video, and content delivery.
There are therefore three separate questions. First, is the Xray core running and listening on the expected local address and port? Second, does the target application actually send traffic into that listener? Third, after traffic enters the core, do the domain, IP, DNS, and outbound rules send it through the intended proxy rather than directly? A successful subscription update answers none of these questions by itself.
Match selected work domains or rule sets to the proxy outbound while ordinary local destinations remain direct. This gives a clear balance between meeting reliability and local browsing performance.
Suitable for: remote work with local websites kept direct
Send nearly all traffic that reaches the core through the selected proxy. It is useful as a short diagnostic baseline, but it can add latency to local services and make it harder to identify which application is failing.
Suitable for: temporary troubleshooting and controlled testing
Publish the local HTTP or mixed proxy to Windows applications that honor the system setting. This is simple, but it does not guarantee that Zoom, Slack, or every browser component will use the proxy.
Suitable for: browsers and applications known to read Windows proxy settings
Conclusion: Define traffic scope before choosing a node
For remote work, the most useful first decision is not whether VMess or VLESS sounds newer. Decide whether the application can reach the local listener and whether only work destinations should use the proxy. Once scope is correct, protocol and node troubleshooting becomes much more meaningful.
Choose a work routing model
A practical work profile normally has at least two outbounds: a proxy outbound for selected destinations and a direct outbound for local websites, local services, and destinations that do not need the proxy. The routing engine then evaluates traffic according to the configured order. Depending on the generated configuration, rules may match domains, domain suffixes, full domain names, IP ranges, network types, or application processes. The exact menu labels can differ between v2rayN releases and core versions, so verify the generated profile and logs rather than copying a field that does not exist in the current interface.
For Zoom, begin with the domains visible during sign-in and meeting startup. For Slack, include the service domains required for workspace login, messaging, file delivery, and calls. For Google Meet, include the Google and Meet-related destinations observed in the browser and, where relevant, media traffic that may not behave like an ordinary web request. Do not add a random list of every large technology provider. Broad rules can route unrelated local browsing, software updates, and content delivery through the proxy, which increases latency and makes later diagnosis difficult.
Domain rules are usually easier to maintain than manually collecting changing IP addresses. A domain suffix rule can cover related subdomains, while an exact domain rule limits the match more narrowly. IP-only rules may still be necessary for destinations resolved outside the expected domain pattern, but they are less convenient when service infrastructure changes. If DNS processing is configured differently for direct and proxied traffic, the same hostname can resolve to different addresses; therefore, a domain rule should be tested with the DNS mode used by the active core.
| Traffic group | Preferred outbound | Rule basis | Verification method |
|---|---|---|---|
| Zoom sign-in and meeting control | Proxy | Observed service domains and application logs | Sign in, join a test meeting, check audio and video |
| Slack workspace and file access | Proxy | Workspace, API, file, and call destinations | Send a message, open a file, start a test call |
| Google Meet browser traffic | Proxy | Browser-request domains and media behavior | Join a meeting and verify camera, microphone, and screen sharing |
| Local news, intranet, and ordinary websites | Direct | Local domain, private address, or final direct rule | Compare loading and inspect the core route log |
Rule order is as important as the rule contents. A broad direct rule placed above the work-domain rules can bypass the proxy before the intended match is evaluated. Conversely, a global proxy rule placed first can make the later direct exceptions ineffective. Keep the structure readable: private and local destinations first when required, selected work destinations next, and a deliberate final rule afterward. If the final rule is “direct,” unmatched traffic remains local; if it is “proxy,” unmatched traffic may also leave through the proxy. Choose this behavior intentionally instead of inheriting it accidentally from a copied profile.
Configure and test the v2rayN work profile
Before editing routing rules, update the subscription and select a known working server. Check the selected core under the current v2rayN settings and confirm that the core log does not show configuration parsing errors. A profile can appear in the server list while still containing unsupported fields for the selected core. Also record the local HTTP, SOCKS, or mixed port displayed by the client. Applications configured manually must use the actual port, not a remembered value from another computer.
Update the profile
Open v2rayN, use the subscription group update action, and wait for the server list to refresh. Select one server and start the core. Confirm that the status changes to running and that the log contains no immediate bind, parse, DNS, or outbound initialization error.
Record local ports
Open “Settings” → “Parameter Settings” and note the current HTTP, SOCKS, or mixed inbound address. A typical local address is
127.0.0.1, but use the address shown in this installation. If another application has a fixed proxy entry, update that entry only after confirming the core is listening.Select routing mode
Choose the routing or proxy mode that supports targeted rules rather than starting with an unrestricted global mode. Keep a direct outbound available for local destinations. If the interface exposes rule-set or routing-profile controls, create a clearly named work profile instead of overwriting the only general profile.
Add work destinations
Add the verified Zoom, Slack, and Google Meet-related domain rules to the proxy outbound. Prefer domain or suffix matches over large IP blocks. Place these rules above a broad final direct rule, then save or regenerate the configuration so the running Xray core actually receives the changes.
Test one app at a time
First open a normal local website, then sign in to Slack, join a Google Meet session, and start a Zoom test meeting separately. Record which action fails, whether the core log records a matching request, and whether the failure affects control traffic, audio, video, files, or screen sharing.
Use a staged test instead of opening all three applications simultaneously. Start with a normal browser request that should remain direct. Then test Slack text messages and file access before testing a call. For Google Meet, verify the meeting page, microphone, camera, and screen sharing as separate functions. For Zoom, test login, joining, audio, video, and screen sharing independently where possible. This sequence helps distinguish routing failure from a device permission issue, a browser restriction, or a service-specific media path.
If the browser works but the desktop application does not, do not immediately replace the subscription. First determine whether that application supports the Windows system proxy, has its own proxy controls, or needs a more complete capture method. TUN can cover applications that do not use a normal HTTP or SOCKS setting, but it changes the traffic path for the whole device or for a defined application set. Enable it only after understanding the routing and DNS consequences, and avoid running another VPN-like network adapter at the same time.
When TUN is used, confirm that the operating system grants the required network permission and that no other virtual adapter is competing for the default route. Check whether DNS requests are captured and whether private network addresses still resolve correctly. A TUN profile can make an application enter the core even when the Windows system proxy is disabled, but it does not automatically create correct service rules. The same domain, outbound, and final-rule checks still apply.
Error: dial tcp 127.0.0.1:10808: connectex: No connection could be made because the target machine actively refused it.
Cause and fix: The application is trying to use a local SOCKS listener that is not running, uses a different port, or is bound to another address. Start the core, verify the current inbound under “Settings” → “Parameter Settings,” and update the application's proxy entry.
Error: connection works in the browser, but Slack or Zoom remains offline.
Cause and fix: The desktop application may not honor the Windows system proxy or may use destinations outside the current domain rules. Check whether the core log sees the application traffic; if not, review the application's own proxy behavior or test an appropriate TUN profile.
Error: meeting page opens, but audio or video cannot connect.
Cause and fix: Web control traffic and real-time media traffic may use different hosts, transports, or network paths. Test microphone and camera permissions, inspect the core log during the failure, and add only the missing verified destinations rather than switching immediately to global proxy mode.
Verify reliability without proxying every local website
A work profile is successful only when both sides of the requirement hold: the collaboration tools remain usable, and ordinary local browsing still follows the intended direct path. Test from a clean state after every meaningful rule change. Stop and restart the core when the client requires regeneration, clear only the relevant application cache if a service has retained an old connection, and record the exact time and symptom. Repeatedly changing nodes, DNS, routing mode, and application settings at once removes the evidence needed to find the real cause.
Inspect logs during an active test rather than after the meeting has ended. Look for the destination, selected outbound, DNS result, and connection error. A request that appears as direct has matched a direct rule or bypassed the core; a request that does not appear at all has probably not entered the local listener. A request that reaches the proxy outbound but fails remotely points to the selected node, server name, transport, TLS settings, or remote network. This separation is more useful than judging the entire setup by a single “connected” indicator in v2rayN.
Keep a small test matrix for future updates. Record whether Slack text, Slack files, Slack calls, Zoom sign-in, Zoom audio, Zoom video, Google Meet camera, and Google Meet screen sharing work. Add a local website, an internal work resource if applicable, and a direct DNS lookup to the same list. After a subscription update or core change, repeat the matrix. A rule that worked last month may no longer cover a service's current hostname, while a newly broad rule may silently proxy traffic that was previously direct.
For stability, prefer one clearly documented work profile over multiple profiles with overlapping global settings. Give the profile a descriptive name, write down the intended local ports, note whether TUN is enabled, and keep the final routing rule explicit. Do not expose a local inbound on all network interfaces merely to make another device connect; binding to 127.0.0.1 is safer for a workstation-only setup. If another device must use the proxy, evaluate the security and firewall implications separately.
Operational rule: test the application path, not only the webpage
A green browser page proves that one browser request completed. It does not prove that Slack calls, Zoom media, Google Meet screen sharing, local websites, and DNS requests follow the same route. Keep targeted rules, verify the actual local entry point, and test each critical work function after changes.
When a call is time-sensitive, a temporary global mode can be useful as a diagnostic comparison. If Zoom or Google Meet works globally but fails under targeted rules, the node is probably reachable and the targeted domain or media coverage needs review. If it still fails globally, investigate the local listener, core log, node transport, DNS, device permissions, and network restrictions instead of adding more domains. Return to targeted routing after the comparison so unrelated local traffic is not left on the proxy.