If your browser connects but games or command-line tools still connect directly, check whether those apps follow the system proxy before enabling TUN. This guide covers the Windows desktop version of v2rayN, from permissions and virtual adapter setup to route verification and recovery. First distinguish traffic capture from proxying all traffic, then verify the configuration with logs and system commands—not just an enabled toggle.
System proxy, TUN, and global routing: what's the difference?
A system proxy registers a proxy address with the operating system, and apps that support the setting connect to a local proxy endpoint. It does not automatically change how every program handles network traffic: some command-line tools use environment variables, some games open sockets directly, and some apps have their own proxy settings. A working browser connection only confirms that the browser's route is working.
TUN provides a virtual network adapter at the network layer. Combined with routing, it sends matching IP traffic into a processing chain. Apps do not need to understand HTTP or SOCKS proxies, but whether traffic is captured still depends on routes, interface binding, address family, and exclusions. Once captured, rules determine whether it connects directly, uses a proxy, or is blocked.
| Setting | Where it works | What it does not guarantee |
|---|---|---|
| System proxy | Connects apps that support the setting to a local proxy port | Does not guarantee capture of games, UDP, or all command-line requests |
| TUN mode | Receives IP traffic through a virtual network adapter and system routes | Does not guarantee that all traffic exits through a remote server |
| Global proxy routing | Sends requests allowed by the rules to a proxy outbound | Does not replace TUN or fix an unavailable server |
| Rule-based routing | Selects different outbounds based on domains, IP addresses, and other conditions | Does not guarantee that all mainland China or local network addresses are covered by the rules |
In short: choose how to capture traffic, then choose the outbound rules
For browser-only proxying, start with the system proxy. To handle apps that ignore proxy settings, try TUN. If those apps also need to use a server's exit IP, check the active routing policy—enabling TUN alone does not mean all traffic is proxied.
Prepare permissions, a working server, and a fallback
First confirm that the selected server works in system proxy mode, then add TUN. VMess and VLESS are protocols used by servers; subscription URLs provide and update server configurations. Neither creates a virtual network adapter. If the server is unavailable, changing traffic capture methods only adds more variables to troubleshoot.
v2rayN is a graphical client that manages connections; the core it calls handles traffic processing. TUN implementations and core combinations can vary between versions, and common setups may involve sing-box. Do not assume that because a server uses Xray, TUN must be handled independently by the same core. When troubleshooting, rely on the process, configuration, and errors shown in the startup logs.
- Keep the full program folder intact: Choose a version for your Windows architecture on the client download page, then install or extract it according to the release notes. Do not copy only the main executable and leave out its dependencies.
- Record your current settings: Note the active server, routing preset, local listening ports, and DNS settings. Back up the client configuration before making changes.
- Close other traffic-capture tools: Exit other VPNs, virtual adapter capture tools, and transparent proxies to avoid competing for the default route. On a managed device, check your organization's network policies first.
- Have administrator access ready: Creating a virtual adapter or changing routes usually requires elevated permissions the first time. Check the documentation for your version to see whether service mode is available and how to authorize it.
Enable v2rayN TUN mode step by step
These steps use the commonly seen Chinese desktop interface. Labels may move between v2rayN releases; if you see names such as “Tun mode settings” or “TUN settings,” check your version's documentation. A missing label is not a reason to create a network adapter manually.
-
Verify the server
Select an existing server on the main screen and set it as the active server. With the system proxy enabled, try opening a known-working HTTPS site. If that fails, troubleshoot the server address, port, authentication, and device clock first.
-
Run with elevated permissions
Exit v2rayN completely from the system tray. Then right-click the program, select “Run as administrator,” and approve the system prompt. Closing only the window and reopening the app may leave the old, non-elevated process running.
-
Check the settings
Open “Settings” → “Parameter settings” and review the local listener configuration. If your version has the tab, open “Tun mode settings.” For your first test, keep the client's defaults; do not change the protocol stack, MTU, and DNS policy all at once.
-
Choose a route
Check the routing selector at the bottom of the main window. For everyday use, start with an existing split-routing preset. To compare exit routes, temporarily use a global proxy preset and note the original selection so you can restore it.
-
Enable traffic capture
Turn on “Enable Tun” at the bottom of the main window, then check the logs for adapter creation, interface startup, and route errors. To test TUN by itself, switch “System proxy” to “Clear system proxy” so the browser does not keep using its previous route and skew the results.
-
Check the apps
Test a browser first, then test a target program that did not previously use the system proxy. Check the destination and actual outbound in the logs. If the network goes down, turn off “Enable Tun” first, then restore the previous system proxy setting.
“Clear system proxy” helps reduce variables during testing; it does not mean the two features can never be used together. Once the setup is stable, decide whether to keep the system proxy based on your apps. Make sure the core's own outbound connection is not routed back through the proxy endpoint, or you may create a connection loop.
Verify traffic capture with ports, routes, and logs
These three numbers are common troubleshooting reference points, not settings to copy blindly. In particular, use the actual listening port shown under “Settings” → “Parameter settings.” If the example port 10808 differs from yours, replace it with your configured port.
Run these read-only commands in PowerShell to compare interfaces and routes before and after enabling TUN. TUN may capture traffic with more specific routes without replacing the existing default route, so checking only whether the default gateway changed is not enough. A listening port confirms that an endpoint started, but does not prove the server is working.
# View network interfaces and compare changes before and after enabling TUN
Get-NetAdapter -IncludeHidden
# View IPv4 and IPv6 routes
route print -4
route print -6
# Use only if the local listening port is 10808
Get-NetTCPConnection -State Listen -LocalPort 10808
# Ignore user curl settings and do not use an explicit HTTP/SOCKS proxy
curl.exe -q --noproxy "*" --connect-timeout 10 -I https://example.comThe last command can help test a request that does not explicitly use an application-layer proxy. Run it once with TUN off and once with TUN on, while checking the client logs. An HTTP response means the connection to that destination made progress, but does not prove it used a proxy: the site may be reachable directly. Also check the selected outbound in the logs.
- Check the interface: Look for a new virtual interface or one whose status changed; do not rely on a fixed adapter name.
- Check the rule: See whether the target request matched a direct or proxy rule. Temporarily change the route if needed to compare results.
- Check the exit IP: Use a trusted IP lookup service to compare the result with the expected server exit. In split-routing mode, different destinations may use different exits.
- Check coverage: Test IPv4, IPv6, and the target app separately. A successful browser tab does not mean every address family and transport is covered.
Troubleshoot DNS, UDP, and local network access
TUN receiving packets does not guarantee that domain names resolve correctly. Traditional DNS often uses UDP or TCP port 53, but browsers may also use encrypted DNS. If domains fail while existing connections keep working, check the DNS path before switching all your servers.
Under “Settings” → “Parameter settings,” check the DNS-related tabs available in your version and distinguish between direct resolution, proxy resolution, and TUN DNS handling. Domain policies need to work with routing rules. Sending all DNS queries to a resolver that is currently unreachable can cause both direct and proxied connections to time out.
| Symptom | Check first | What to do |
|---|---|---|
| Domain connection fails | DNS reachability, resolution path, and logs | Run Resolve-DnsName example.com and check the logs; change one DNS setting at a time before retrying |
| Web pages work, but voice calls fail | UDP support, the server, and firewall rules | Check the target app's UDP connection logs and confirm that the server and transport path support forwarding |
| Printer or shared resource is unreachable | Whether local network traffic is being routed through the proxy | Check that the route sends your actual local subnet directly, and review the local firewall |
| Some destinations still connect directly | IPv6 routes, app interface binding, and rule exclusions | Compare IPv4 and IPv6 route tables, then check which rule actually matched the destination |
Troubleshoot startup failures and restore your network
Troubleshoot in this order: permissions and interface → core startup → server connection → DNS and routing. The first clear error in the logs is usually more useful than the timeouts that follow. Before sharing logs, redact subscription URLs, server authentication details, and other sensitive information.
TUN reports insufficient permissions. What should I do?
Exit the client from the system tray, then start it with “Run as administrator.” If it still fails, check whether security software or your organization's policies are blocking virtual interface creation or route changes. Do not disable all security protection just to test.
The toggle is on, but the logs say core startup failed. Why?
Check that the program folder is complete and review the first core startup error. If an address or port is already in use, run Get-NetTCPConnection -State Listen to identify the process; do not terminate an unfamiliar system process.
All web pages time out after enabling TUN. What should I change first?
Turn off TUN, restore the original system proxy, and test the same server. If the original mode fails too, troubleshoot the server first. If only TUN fails, check for route conflicts and DNS issues. Keep the default protocol stack as your baseline and change one option at a time.
The network is still down after I exit the client. What should I do?
If the program exited unexpectedly, restart it with the same permissions, turn off TUN, then select “Clear system proxy” and exit normally. If the network still does not recover, restart the computer and check Windows proxy settings and network connectivity. Do not run commands that flush all routes.
After testing, restore the split-routing preset that suits your everyday use, then test local network access, your browser, and the target app again. If the system proxy meets your needs, leave TUN off and enable it only when needed. Keeping a verified configuration makes issues easier to pinpoint than repeatedly changing the MTU, DNS, protocol stack, and routes.