This guide uses the Windows desktop version of v2rayN. First, verify your node and local proxy; then enable TUN with administrator privileges and check routing, DNS, and the target app. “System-wide routing” means more traffic can enter the processing path—not that every connection uses a proxy. Actual coverage still depends on routing rules, exclusions, and IPv6 settings.
1. TUN vs. system proxy: the traffic entry point changes, but routing rules still apply
A system proxy writes a proxy address to system settings, and apps decide whether to use it. Browsers usually honor this setting, but some command-line tools, games, and apps with their own network stacks do not. A website loading in your browser therefore does not prove that other apps use the same proxy route.
TUN is a Layer 3 virtual network interface that receives IP packets. When enabled, the client works with the operating system’s routing table to send matching packets into TUN. The TUN-enabled core then handles connections, applies rules, and selects an outbound. It does not broadcast an HTTP proxy port to every app.
| Comparison | System proxy | TUN mode |
|---|---|---|
| Traffic entry point | The app connects directly to a local proxy address | The OS routes matching packets to a virtual interface |
| App support | The app must honor system settings or have a proxy configured manually | The app usually does not need to provide proxy settings |
| Permissions | Changing proxy settings for the current user usually does not require elevation | Creating an interface and configuring routes usually requires elevated privileges |
| Outbound selection | Determined by the proxy core’s routing rules | Still determined by the routing rules of the core actually in use |
“Global” can mean at least two things: letting more apps enter the proxy processing path, or sending every connection in that path through a proxy outbound. TUN mainly addresses the first. LAN connections, excluded destinations, and routes assigned to other virtual adapters may still bypass TUN.
2. Before you enable TUN: check your node, core, and local ports
Get regular proxy mode working before enabling TUN. TUN will not fix a broken subscription, incorrect VLESS parameters, or mismatched TLS settings. If the current node cannot connect, adding a virtual adapter will only extend the problem to more apps.
- Verify the active server: In the server list, select a known-working entry and set it as active. A successful subscription update only confirms that the list was retrieved; it does not prove that any listed server can connect.
- Check local listeners: Open Settings → Parameter Settings and review the local listening ports and related options. Group names can vary between interface versions, so use the labels shown in your current version.
- Check which core runs TUN: v2rayN is a client, not a single core. Its TUN feature is usually handled by sing-box. Using Xray for regular proxy connections does not mean Xray also creates the TUN inbound. Make sure the required core files are present, then check the startup log for the actual process in use.
- Note your current network setup: Make a note of any active VPNs, corporate networking tools, and virtual machine adapters. For the initial test, avoid running multiple apps that modify the default route at the same time.
Takeaway: establish a repeatable proxy baseline first
First, test the node with a request that explicitly uses the local proxy. Then repeat the same request without specifying a proxy to test TUN. Using the same destination for both tests helps distinguish an unavailable node from traffic that never entered TUN.
3. Enable TUN on Windows: elevate, turn it on, and check the logs
For the initial setup, work directly on the machine rather than relying only on a Remote Desktop session to change routes. A network interruption could also drop the remote connection. The steps below apply to versions of v2rayN with a TUN switch on the main window. If your version places the setting elsewhere, check the TUN-related pages under Parameter Settings; menu names are not consistent across versions.
- Save your work and exit the client. Turn off TUN first, then exit v2rayN from the system tray menu to avoid leaving an old process holding a listening port or retaining its previous state.
- Restart as administrator. Right-click the v2rayN program, choose Windows’ “Run as administrator,” and approve the system prompt. If your installation uses a supported elevation mechanism, make sure it has been authorized.
- Select an active node and routing mode. Start with a node you have already verified. Keep to a set of split-routing rules you understand, and avoid importing unfamiliar rule sets during the first test.
- Clear the system proxy to isolate the test. In the main window or system tray menu, choose the option to clear the system proxy. This prevents a browser from succeeding via the system proxy and masking a TUN issue; clearing it is not a requirement in every setup.
- Turn on the TUN switch in the main window. Wait for the core to start and check the logs for interface creation, route setup, or startup errors. An enabled switch only shows that the client recorded the state; it does not prove the traffic path is working.
- Check the interface and make a new request. Look for the new virtual interface in Windows Network Connections, then launch an app you want TUN to handle. Existing long-lived connections are not suitable for the initial test; disconnect and reconnect instead.
Administrator privileges allow the client to create interfaces and configure routes. They do not make the server support UDP or automatically make incompatible protocol settings work. If the logs report an unsupported field, check that the generated configuration matches the bundled core instead of adding more privilege settings.
4. Check whether traffic is being captured: don’t rely on a browser alone
Run these commands in Windows PowerShell. The first assumes the local SOCKS listener is 127.0.0.1:10808; replace it if your port is different. curl.exe explicitly invokes the executable and avoids differences caused by command aliases.
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com/
Get-NetAdapter
route print
Resolve-DnsName example.com- Command 1 establishes a node baseline:
socks5hsends domain name resolution to the SOCKS proxy. If your local listener uses a different proxy protocol, adjust the command to match; a failed request here does not necessarily mean the node is unavailable. - Command 2 rules out an explicit app proxy:
--noproxy "*"tells curl not to use an application-level proxy setting, but it does not bypass OS routing through TUN. Run it with TUN enabled to see whether the request completes. - Commands 3 and 4 check system state: Check whether the virtual interface exists and whether routes have changed. TUN may capture traffic by splitting the default route or using another mechanism, so an unchanged default route alone does not indicate failure.
- Command 5 checks name resolution: It shows the system’s current resolution result or error. It does not tell you whether the browser’s built-in encrypted DNS uses the same path.
example.com is only a syntax example here. If the destination is reachable directly, a successful request does not prove that a proxy outbound was selected. Check the destination, timestamp, and core routing logs for that request to see which rule it matched. If necessary, compare the same controlled destination with TUN on and off.
Takeaway: verify traffic capture and proxy routing separately
First confirm that new connections enter TUN, then confirm that the logs show the expected outbound. If a direct-connection rule matched, an unchanged external IP does not mean the virtual adapter failed.
5. Routing, DNS, and UDP: three boundaries that are easy to confuse
Connections captured by TUN still have to match routing rules. Make sure LAN addresses, required local services, and connections to the proxy server itself have the correct direct or exclusion routes. Otherwise, access to a printer may fail, or the proxy’s outbound connection may loop back into TUN. Prefer the configuration generated for your client; do not copy an isolated field from another setup into the current configuration file.
| What to check | Potential issue | What to do |
|---|---|---|
| LAN addresses | Router admin pages, shared folders, or printers may be routed to the proxy by mistake | Check your actual LAN subnet, for example 192.168.1.0/24. This is only an example; use your own network details. |
| DNS requests | The resolution path and connection path may differ, causing timeouts or addresses unsuitable for the current outbound | Check the TUN DNS settings, resolver reachability, and whether the browser uses its own encrypted DNS |
| IPv6 | With IPv4-only routing, some connections may leave over IPv6 | Check IPv6 addresses, routes, and TUN support as well; testing a single IPv4 destination is not enough |
| UDP | Web pages load, but voice, games, or QUIC connections fail | Check that TUN, the selected outbound, and the server path support the required UDP traffic |
DNS hijacking often involves routing traditional DNS requests to the core’s resolver, but checking only destination port 53 will miss encrypted DNS such as DoH. When an app resolves names over HTTPS, that connection looks like ordinary HTTPS traffic. When troubleshooting, track both who performs the lookup and where the DNS request exits.
Configuration formats are not interchangeable. TUN is a way for the client to use a core’s capabilities, not a generic top-level V2Ray JSON field called tun. sing-box, Xray, and V2Fly have different configuration formats and feature support. Before editing a configuration manually, confirm which core is actually loaded in the logs and consult its documentation. See the JSON Configuration Manual for the basic structure, but do not copy configuration between cores unchanged.
- When testing split routing, change one rule at a time and note which outbound it matches.
- For DNS tests, make a fresh query; cached results and existing connections can hide configuration changes.
- For UDP tests, use an actual session in the target app; a successful HTTP request does not replace a voice or game test.
6. Common issues and recovery checks after disabling TUN
Troubleshoot in order: startup failures, traffic routing, then individual apps. Keep the logs from around the time the issue occurred, especially permission errors, interface creation failures, address conflicts, DNS timeouts, and outbound connection errors. Remove subscription URLs, credentials, and other sensitive information before sharing logs.
Does the TUN switch turn itself off right after you enable it?
Check the core startup logs first. If the issue is insufficient permissions, close the client and restart it as administrator. If the configuration contains an invalid field, check that the core and generated configuration match. If the logs report an address or interface conflict, disable the other active tunnel and try again; do not repeatedly create interfaces.
Nothing loads after enabling TUN. Should I change DNS first?
Turn off TUN and confirm that the original network works again. Then test the current node using an explicit local proxy. Once the node is confirmed working, check the TUN logs and routes, then investigate DNS. If the only error is a name-resolution timeout, check the resolver address and its outbound route. Do not change the node, routes, and DNS all at once.
Web pages work, but games or voice calls still fail to connect?
Fully quit and reopen the app to avoid reusing an old session. Then check whether it matches a direct-connection rule, whether the server path supports UDP, and whether the firewall blocks the app. TUN can receive packets, but that does not guarantee the remote server can forward the traffic the app needs.
How do I restore my network if it still has issues after closing v2rayN?
First restart the client, turn off TUN normally, then clear the system proxy and exit. Check whether Windows proxy settings still point to a local listening address, then inspect the virtual interface and routes. If the network still does not recover, save your work and restart the system. On a corporate device, contact your administrator first; do not delete adapters in bulk.
For stable operation, keep one verified node, a set of rules you understand, working DNS settings, and a reliable way to turn TUN off. After updating the client or core, repeat the same tests; this is more reliable than checking the switch alone. If only your browser needs a proxy, the system proxy is usually enough. Enable TUN only when an app does not honor proxy settings.