If your browser works but command-line tools, games, or other desktop apps bypass the proxy, first check whether they use the system proxy. This guide walks through TUN routing in v2rayN on Windows, including administrator privileges, DNS, and routing rules, with steps to enable, verify, and safely undo changes. You'll know when TUN is actually needed instead of changing every setting at once.
System Proxy vs. TUN: Two Different Traffic Paths
A system proxy mainly tells apps where to find a proxy server. Connections go through v2rayN's local proxy only if an app reads and honors that setting. Some command-line tools use proxy environment variables, while other apps have their own network stack. So a working browser doesn't mean those apps are connected too.
TUN is a virtual network interface that operates at the IP layer. The operating system routes matching packets to the virtual adapter, where the accompanying core processes connections and selects an outbound route. Apps generally don't need separate HTTP or SOCKS proxy settings, but administrator privileges, system routes, and DNS settings all affect what gets captured.
“Capturing all traffic” describes the scope of interception; it does not mean “sending all traffic through a proxy node.” With TUN enabled, connections to sites in mainland China, local network traffic, and anything matched by direct rules may still go out directly. Connections that never reach the virtual adapter cannot be captured. Check IPv6, other virtual adapters, and routes that are explicitly excluded separately.
- Browser only: The system proxy is usually enough; there's no need to enable TUN just for the sake of it.
- App supports manual proxy settings: Configure its HTTP or SOCKS proxy first for a more targeted change.
- App doesn't support proxies but needs traffic capture: Consider TUN for apps such as some games, launchers, or standalone network tools.
- For UDP traffic: TUN can receive the relevant IP packets, but whether they can be forwarded depends on the protocol, core, proxy node, and remote network. The toggle alone can't tell you.
Before You Enable TUN: Test the Node and Check Permissions
v2rayN manages configuration and starts the core; TUN provides a traffic entry point; VMess and VLESS are proxy protocols. These serve different purposes. Enabling TUN won't make an unavailable node work or add transport capabilities the server doesn't provide.
Menu locations and field names can vary between builds. The steps below refer to the “Enable Tun” toggle on the main screen and TUN options under “Settings” → “Parameter Settings.” If your interface differs, follow the labels in your installed build and check its runtime logs. Don't replace an entire core configuration with one generated by a different version.
- Save your current settings. Note the active server, system proxy mode, and routing preset. For the first test, don't also change subscription groups, outbound protocols, or DNS.
- Verify the regular proxy connection. Leave TUN off for now and use the system proxy to visit a known-reachable HTTPS site. If it fails, troubleshoot your subscription, node authentication, system clock, and network connection first.
- Close conflicting traffic-routing tools. Other VPNs, virtual network adapter software, or corporate security clients may also change routes. Close only software you're authorized to manage; on a managed device, check your organization's policies first.
- Prepare to run with elevated permissions. For initial troubleshooting on Windows, exit v2rayN, then right-click the app and choose “Run as administrator.” Creating a virtual adapter and changing routes usually require elevated privileges. If your build supports running as a service, check the permissions for that service instead.
Enable Tun: Change One Setting at a Time
For an initial setup, use the TUN defaults provided by the client. Don't start by switching network stacks, changing the MTU, or importing advanced snippets from unknown sources. The v2rayN TUN path may use an accompanying core such as sing-box and work alongside an outbound core such as Xray for the selected server. Check the runtime logs for details about your setup.
- Select a verified server. Set it as the active server on the main screen and confirm that a regular proxy connection can complete a real request—not just show a test result.
- Review the TUN settings. Open “Settings” → “Parameter Settings” and find the TUN options. Keep the default network stack and MTU, and check the status of any auto-route option. Creating a virtual adapter without configuring usable routes usually won't capture traffic as expected.
- Clear the system proxy to isolate the test. On the main screen, choose “Clear system proxy” from the “System Proxy” menu. This isn't required in every setup; it helps prevent your browser from continuing to use an old explicit proxy and confusing the test results.
- Turn on “Enable Tun.” Follow any prompts to elevate permissions or restart, then check the logs. Look for successful core startup, virtual interface creation, and route configuration—not just a change in the toggle's color.
- Run the target app. First test an app that didn't use the system proxy before, then check local network access. If anything breaks, turn off TUN and return to your baseline before testing further. Don't switch between multiple presets in quick succession.
Desktop builds for macOS and Linux also need authorization to create virtual interfaces and change routes, but their privilege mechanisms differ from Windows. Don't copy Windows right-click instructions to other operating systems, and don't give the entire install directory overly broad permissions just to bypass an error.
DNS Interception: Capturing Queries Doesn't Replace Every Resolver
In a TUN setup, DNS interception usually means sending matching traditional DNS queries to the core's built-in DNS processing chain. It has nothing to do with changing webpage content. With the right settings, DNS resolution and proxy routing work together; with the wrong ones, the node may connect successfully while domain names fail to load.
These are commonly used protocol ports—not v2rayN local listening ports or test results from this site. A rule that matches only destination port 53 won't automatically catch all encrypted DNS. A browser's Secure DNS, an app's built-in DoH, or a custom resolver may use a different path.
- Check the generated configuration, not just for a toggle. Some versions generate DNS interception rules from a default template and may not have a checkbox with that exact name. Review the TUN settings and logs. If you inspect the generated configuration, treat it as read-only; don't edit a temporary file as if it were a persistent setting.
- Avoid DNS resolution loops. If the proxy server address is a domain name, it needs a working resolution path first. Remote DNS that depends on a proxy connection that hasn't been established yet can create a startup dependency loop.
- Keep local network domains in mind. Corporate intranet and home-device names may resolve only through an internal DNS server; don't send every query to a public resolver.
- Check IPv6 separately. AAAA records and IPv6 routes need to work together. Handling IPv4 alone doesn't mean every connection follows the same path.
Troubleshooting: Align DNS Paths Before Changing Routing Rules
If the browser behaves differently from other apps, temporarily turn off the browser's custom Secure DNS and compare results to see whether DNS paths explain the difference. Don't immediately route everything through the proxy. Restore the browser's DNS setting to suit your needs after testing.
Verify TUN: Check Connections, Routes, and Local Network Access
To verify TUN, look for at least two kinds of evidence: the operating system shows the expected interface or route changes, and the target app's connections are actually using the intended outbound route. A changed public IP only tells you where that particular request exited; it doesn't prove that every app and protocol is being captured.
On Windows, use these read-only commands in PowerShell to inspect the current state. Run them both before and after enabling TUN and compare the output. Don't look for an interface by a fixed adapter name, since names can vary by configuration and version.
# List network adapters, including hidden ones
Get-NetAdapter -IncludeHidden
# Show IPv4 and IPv6 routes
Get-NetRoute -AddressFamily IPv4
Get-NetRoute -AddressFamily IPv6
# Show DNS server settings for each interface
Get-DnsClientServerAddressWhen DNS interception happens in the traffic processing chain, the DNS server address shown by the operating system may not change, so the last command alone can't confirm whether interception is working. Route capture may not appear as a replaced default route either; check the generated rules and logs together.
- Test the target app: Clear any proxy settings or proxy environment variables configured in the app, restart it, and initiate a specific connection. Check the v2rayN logs around that time for the destination and outbound route.
- Test DNS resolution: Compare queries and connection results for the same domain before and after enabling TUN. Caching can affect the results; if needed, run
ipconfig /flushdnson Windows to clear the system DNS cache, then restart the target app. - Test local network access: Visit a router admin page, printer, or shared service that you know is available. Private ranges include more than
192.168.0.0/16; they also include10.0.0.0/8and172.16.0.0/12. Corporate networks may use additional private routes. - Test UDP: Use a target app that actually opens a UDP session. Loading a webpage or getting a ping response does not prove that UDP proxying works.
Common TUN Issues: Troubleshoot by Symptom
Change one setting at a time and keep logs from before and after each change. Logs may contain subscription URLs, server addresses, and authentication details; hide sensitive information before sharing them. The four scenarios below cover common starting points for troubleshooting a new setup.
Why does “Enable Tun” turn itself off as soon as I switch it on?
Check the core logs from that moment first. If they report insufficient permissions, exit and restart as administrator. If virtual interface creation fails, check for other traffic-routing software and security policies. If a configuration field is incompatible, restore the default TUN settings and confirm the client and accompanying core came from the same build.
All network access stops after enabling TUN. Should I change DNS first?
Turn off TUN first and confirm that your regular network connection is back, then test the regular system proxy. If that also fails, troubleshoot the node or underlying network first. If only TUN fails, check for route conflicts, core startup issues, and DNS resolution loops. Don't change nodes and all DNS settings at the same time.
Why does the browser work but the game still won't connect?
Make sure the browser isn't using a separate explicit proxy, then check whether the game's connection appears in the logs. If it's logged but UDP fails, check the node's UDP support and network restrictions. If there's no log entry, check excluded routes, other virtual adapters, and the game's own network settings. TUN doesn't guarantee lower game latency.
Why can't I access the printer or company intranet after enabling TUN?
Turn off TUN to compare and confirm that the service itself is available. Then check direct or bypass rules for the relevant network range, and make sure intranet names still resolve through internal DNS. Dedicated routes from a corporate VPN can conflict with TUN auto-routing; blindly increasing the priority of a default route isn't a safe fix.
Turn TUN Off and Roll Back: Confirm Network Access Is Restored
Before exiting normally, turn off “Enable Tun” and wait for the core to stop and routes to be restored before deciding whether to restore the system proxy. If you still want your browser to use a regular proxy, set the system proxy again. If you're done using the proxy, leave it cleared so apps don't keep connecting to a local port that is no longer listening.
- With TUN off, revisit websites and local network devices that were accessible before and confirm that basic connectivity is back.
- If the client exits unexpectedly, restart it and turn off TUN normally so it can try to clean up the interface and routes it created.
- If the issue persists, save the logs and route output, then restart the device using the normal system procedure. Don't bulk-delete virtual adapters or reset all network settings; doing so could disrupt other connections.
- Record the working node, routing preset, and DNS setup. After an upgrade, retest the target app before restoring auto-start or persistent traffic capture.
TUN expands the range of traffic that can enter the client's processing chain; it doesn't replace subscription maintenance, node availability checks, or routing design. For more about connection options and configuration fields, see the Complete Configuration Guide. For basic network problems, work through the Troubleshooting Guide.