If your browser works but other apps bypass the proxy, first check whether they use the system proxy; consider TUN if they don’t. This guide walks through TUN setup in v2rayN on Windows, including elevation, routing and DNS checks, and virtual adapter conflicts. You’ll learn to distinguish traffic entering the client from traffic exiting through the proxy—and how to switch back to the system proxy at any time.
1. TUN vs. the System Proxy
The system proxy gives compatible apps a proxy endpoint. Browsers typically use it, but some games, command-line tools, and background services use their own network settings. These apps may connect directly even when v2rayN has set the system proxy. If an app supports manual proxy settings, configure those first; you may not need TUN.
TUN creates a virtual interface at the network layer. Together with system routes, it can direct IP packets that would otherwise go out directly into the client’s processing pipeline, where rules determine whether to send them direct, through a proxy, or block them. Apps don’t need to read the system proxy, but TUN doesn’t cover every network environment, process, or protocol.
Keep “traffic capture” separate from “proxy all traffic”: the first describes which traffic enters the processing pipeline; the second describes how that traffic exits. With TUN enabled, LAN addresses and sites matched by direct-connection rules may still connect directly. To route all eligible external traffic through the proxy, adjust the routing policy and make sure your node supports the required transport.
| Comparison | System proxy | TUN mode |
|---|---|---|
| How it connects | Apps connect to a local proxy endpoint | Routes send IP packets through a virtual interface |
| App requirements | Must use the system proxy or have a proxy configured manually | Apps usually don’t need separate proxy settings |
| System permissions | Setting the current user’s proxy usually doesn’t require elevation | Creating an interface and changing routes usually require elevation |
| Outbound route | Determined by the client’s routing rules | Still determined by the client’s routing rules |
2. Check Your Node, Permissions, and Network First
First, use system proxy mode to confirm that an imported configuration can reach the sites you need. TUN won’t fix a broken subscription, expired credentials, an incorrect server address, or a TLS configuration problem. VMess and VLESS describe proxy protocols; TUN describes how traffic is captured on your device. They are not interchangeable configuration types.
- Note your current settings. Record the active server, routing mode, DNS settings, and system proxy status. For local listening ports, use the values shown under Settings → Parameter Settings; don’t copy them from another computer.
- Keep the full application directory intact. Install or extract the download according to its package format; don’t move only the main executable. The client must be able to find the core and any supporting files required by TUN.
- Pause other traffic-capture tools. Disconnect other VPNs and virtual adapter services first. Don’t let multiple programs compete for the default route while you’re trying to identify the source of a problem.
- Check device permissions. On a managed work computer, follow your administrator’s policies. Don’t disable security software or change organization-managed security settings just to enable TUN.
3. Enable TUN in v2rayN on Windows
These steps cover a typical desktop interface. The toggle location, capitalization, and elevation method may vary across releases. Look for “Enable Tun” on the main screen, then check Settings → Parameter Settings → Tun Mode Settings. If your interface uses different labels, use the available options that mention Tun; don’t change unrelated settings based on screenshots from an older version.
- Close any running instance. Exit v2rayN from the system tray so a newly elevated launch doesn’t just bring an existing, non-elevated window to the foreground.
- Run as administrator. In Windows, right-click the application, select “Run as administrator,” and approve the system prompt. If your client offers its own elevation or service option, follow the instructions for that release. Don’t install drivers from untrusted sources.
- Select an available server. Confirm that the active configuration is correct. Keep your verified routing setup, and don’t change the node, DNS, and routing all at once while troubleshooting.
- Review Tun settings. Open Settings → Parameter Settings and review the Tun options. For your first setup, leave parameters such as the network stack and MTU at their defaults. Save, then return to the main screen.
- Turn on “Enable Tun.” Wait for the core to start, then check the logs for interface, permission, routing, or configuration errors. An enabled toggle only confirms that the start command was issued; it doesn’t prove connectivity.
- Rule out the system proxy. Once TUN is running, set the system proxy to “Clear system proxy,” then test an app that didn’t previously use the proxy. This prevents a browser from succeeding through the system proxy and masking a TUN capture failure.
v2rayN on macOS and Linux also needs permission to create virtual interfaces and modify routes, but the Windows right-click elevation steps don’t apply. Use the package for your platform and follow that release’s permission prompts. This guide doesn’t provide one-size-fits-all elevation commands, which could leave a desktop app running with unnecessary privileges.
4. Check Routing, DNS, and UDP
After TUN starts, keep reasonable direct routes for your LAN, then check how external domains are routed. Addresses for a company intranet, printer, or router admin page may be on private networks. If those requests go through a remote proxy, your intranet could stop working even while external sites remain reachable.
These are standard protocol ports, not values to enter as v2rayN’s local listening port. Whether TUN captures DNS depends on DNS routing in the generated configuration, hijacking rules, and how each app resolves names. If a browser uses encrypted DNS, its queries may go over HTTPS; not seeing traffic on port 53 alone doesn’t prove there’s a problem.
- Make sure the resolver is reachable. If remote DNS requires the proxy, its own connection needs a working outbound route. Otherwise, resolution may stall or create a dependency loop during startup.
- Distinguish name resolution from connectivity. A successful lookup only means an address was returned; it doesn’t mean the destination port is reachable. A connection timeout doesn’t necessarily indicate DNS interference.
- Keep a resolution path for the node address. If the node server uses a domain name, it must be resolved when needed before the proxy is established. Avoid making all DNS requests depend on a proxy that hasn’t started yet.
- Test UDP separately. Games, voice apps, and some other software use UDP. TUN can handle this traffic, but the proxy protocol, node server, and network path must also support it. A working website doesn’t prove UDP works.
In short: Confirm outbound connectivity first, then adjust DNS
Keep one verified node and a clear set of routing rules, and change one DNS setting at a time. After each change, test both external sites and LAN resources to make sure restored internet access hasn’t come at the cost of your intranet.
5. Verify Traffic Capture—Don’t Just Trust the Toggle
For a meaningful test, use the same app and destination, and record what happens with TUN on and off. If the app has its own HTTP or SOCKS proxy configured, note and temporarily disable it; otherwise, you can’t tell whether the connection used the app’s proxy or the virtual adapter.
- Start with a regular website. With the system proxy cleared, visit the destination and confirm the connection works. Don’t rely on a cached browser page; send a fresh request.
- Next, test the target app. Launch an app that didn’t previously use the system proxy, and watch the client’s connection details or logs. If the logs show the rule, destination, and outbound route, check which outbound was actually selected.
- Check local resources. Try the router’s actual admin address, a LAN service, or a shared resource you use. Don’t assume every home network uses the same subnet.
- Compare with TUN off. Turn TUN off and test again, then turn it back on. If there’s no difference, first check whether the destination was already reachable directly instead of assuming traffic capture failed.
On Windows, these read-only commands can help you inspect interfaces and routes. They don’t change settings and can’t prove by themselves that traffic went through the proxy; compare their output with app requests and client logs. Interface names depend on the system and core, so don’t look for one fixed name.
ipconfig /all
route print
powershell -NoProfile -Command "Get-NetAdapter | Format-Table Name,InterfaceDescription,Status"6. Fix Startup Failures, Lost Connectivity, and LAN Conflicts
Why does TUN switch off as soon as I enable it?
Start with the first error immediately following the startup attempt. If permissions are insufficient, exit the tray instance and relaunch with elevation. If core files are missing, restore the complete release package. If a configuration field is invalid, undo your most recent Tun parameter change. Don’t keep toggling the switch and overwrite the useful log entries.
All websites stopped working after I enabled TUN. What should I check first?
Turn TUN off first, restore the system proxy that worked before, and confirm the node is still available. Once the node works, check the TUN logs for DNS and routing errors, and pause other VPNs. Re-enable one traffic-capture tool at a time to avoid conflicts between default routes.
Web pages work, but games or voice apps still won’t connect. Why?
Make sure the app isn’t bound to a different network adapter, then check whether the node supports the required UDP forwarding. Don’t treat successful HTTPS browsing as proof that UDP works. Note the exact app error and when it occurred, then use the client logs to determine whether the connection was refused, timed out, or routed incorrectly.
External sites work, but your printer or company intranet is unreachable. What now?
Check the actual LAN destination address and the rule it matches, then preserve a direct route for it. A company VPN may use private routes and internal DNS. Turn TUN off first to check for a conflict. On managed devices, ask your administrator for help; don’t delete system routes to bypass policy.
My internet is still down after I exit the client. How do I restore it?
First restart v2rayN, turn off TUN, and exit normally; then check that the system proxy has been cleared. Once you’ve confirmed no other traffic-capture service is running, restart the computer if needed to clear temporary interfaces and routes. Don’t delete unfamiliar adapters or clear the entire routing table.
7. Keep a Way Back Before Deciding to Leave TUN On
If you only need a browser proxy, the system proxy is usually easier to monitor and maintain. Use TUN when you need to capture traffic from apps that don’t use the proxy. Whether it’s safe to leave on depends on how routing, DNS, sleep and wake, and network switching behave—not on whether the toggle stays enabled.
- Retest after switching networks. Recheck external sites and LAN resources when moving from Ethernet to Wi-Fi or from a home network to an office network.
- Review settings after an update. Client and core updates may change which parameters are supported. Keep a recoverable configuration, check the startup logs, and don’t paste old configuration snippets into a new version.
- Roll back in order. Turn off TUN first, restore the system proxy if needed, then confirm that your target app and LAN resources work again.
If you need to reimport a subscription or verify the basic proxy setup, start with the setup guide and confirm the connection before enabling TUN. Check node availability, the system proxy, the virtual adapter, and routing rules separately; this is usually easier than changing several settings at once.