v2rayN TUN mode creates a virtual network adapter on Windows and redirects supported system traffic into the selected proxy core. Unlike the ordinary system-proxy mode, it can also handle applications that do not provide a manual HTTP or SOCKS proxy field. This makes TUN useful for command-line tools, desktop applications, launchers, and software that ignores Windows proxy settings. It also changes the troubleshooting path: an active system proxy does not prove that TUN is working, and a connected node does not prove that every application is routed through the tunnel.
This guide explains how to enable TUN mode in v2rayN on Windows, choose the correct Xray core and routing options, verify the virtual adapter with practical tests, and isolate common problems such as missing administrator permission, occupied local ports, DNS leaks, broken LAN access, and applications that still bypass the tunnel.
What TUN mode changes in v2rayN
Normal v2rayN operation commonly uses a local SOCKS or HTTP listener. For example, a browser can be configured to use 127.0.0.1:10808 as a SOCKS5 proxy, while another application may use 127.0.0.1:10809 as an HTTP proxy. This arrangement is simple and easy to inspect, but it depends on each application supporting manual proxy settings. Programs that connect directly with their own networking stack may never use those listeners.
TUN mode adds a virtual network interface to Windows. Traffic sent through that interface is captured by the core, matched against routing rules, and then sent to a direct or proxy outbound. The application does not need to know the local SOCKS or HTTP port. In a typical flow, the application creates a connection, Windows sends the packet to the TUN adapter, v2rayN applies routing and DNS behavior, and the selected outbound connects to the destination.
TUN is not the same as a VPN subscription or a server-side tunnel. v2rayN still needs a working node and a compatible core. TUN only changes how local traffic enters the client. The selected VLESS, VMess, Trojan, or Shadowsocks configuration remains responsible for connecting to the remote server. If the node itself cannot connect in ordinary proxy mode, enabling TUN will not repair it.
Check the prerequisites before enabling TUN
Install a recent v2rayN Windows release from the site download page and extract it to a normal writable folder such as C:\Tools\v2rayN. Avoid placing the complete application under a protected system directory if the client needs to write logs, subscription data, or core files. The exact menu names can vary slightly between v2rayN releases, but the TUN controls are generally located under the settings or parameters area rather than inside an individual server profile.
Import and test a subscription before changing the network mode. In v2rayN, update the subscription group, select a node, and run a latency or connectivity test. Then enable the ordinary system proxy temporarily and open a known HTTPS website. This gives you a baseline. If the baseline already fails, record the core log message and fix the node, DNS, or server parameters first.
- Use an account that can approve the Windows administrator prompt. TUN drivers and virtual adapters may require elevated permission.
- Keep only one proxy client actively managing a virtual adapter. Another VPN, firewall tunnel, or traffic interception tool can compete for routes.
- Confirm that Windows has an available private network profile and that security software is not blocking the v2rayN process.
- Check whether your selected core supports the protocol and transport used by the node. Xray is normally the practical choice for current VLESS and REALITY configurations.
- Record your current DNS, proxy, and routing settings so you can return to a known state.
| Item | What to verify | Why it matters |
|---|---|---|
| v2rayN release | Use a current Windows build and read its included core information | TUN fields and bundled dependencies differ between releases |
| Core | Prefer a compatible Xray core for Xray-based nodes | The client UI cannot add support that the selected core does not have |
| Node | Test the selected profile in ordinary proxy mode first | Separates remote-node failures from local TUN failures |
| Permission | Allow administrator access when Windows requests it | The virtual adapter may not be created without elevation |
| Port availability | Check local ports such as 10808 and 10809 | Another process can prevent the core or helper from starting |
Recommended baseline
- Core
- Xray
- Mode
- Rule-based routing
- Proxy
- Start with one tested node
- DNS
- Use the client’s documented TUN option
Establish a working ordinary proxy before adding TUN complexity.
Safe rollback
- TUN
- Disabled
- System proxy
- Restore previous state
- Adapter
- Remove only if necessary
- Logs
- Keep the latest failure record
A rollback makes it easier to compare TUN and non-TUN behavior.
Enable TUN mode step by step
The following path is intended for a recent v2rayN Windows build. If a label is different in your release, look for the equivalent TUN, virtual network adapter, or routing setting. Do not enable every experimental option at once. Start with the minimum configuration, verify the adapter, and then adjust DNS or route scope only when there is a specific reason.
Update the node
Open v2rayN, go to the subscription group area, update the active group, and select a node that already passes the client’s latency or connectivity test. Confirm that the profile contains its complete server address, port, user identifier, transport, and security parameters.
Choose the core
Open the v2rayN core or parameter settings and select a core that supports the imported profile. For a current VLESS configuration using REALITY or Vision, select the available Xray core that matches the required feature set. Restart the core if v2rayN asks you to reload it.
Open TUN settings
Find the TUN or virtual network adapter section under v2rayN settings. Enable TUN mode, then review the interface, stack, MTU, and automatic route options. Leave advanced values at their defaults unless the release documentation or a measured problem gives you a reason to change them.
Approve elevation
Start the service or core and approve the Windows administrator prompt. If no prompt appears and no adapter is created, close v2rayN, right-click the main executable, choose “Run as administrator,” and enable TUN again. Do not repeatedly click the switch while the first start operation is still running.
Apply the route
Enable the TUN service or restart v2rayN as requested. Check that the status changes to running and that the selected node remains connected. If the client offers a system-proxy switch, keep it unchanged during the first test so you can identify whether traffic is being handled by TUN itself.
Test one application
Close and reopen one application that normally ignores manual proxy settings. Test a website, a DNS lookup, and a simple download. If those tests pass, expand the test to other applications instead of changing multiple route and DNS settings simultaneously.
Some versions expose TUN controls through a tray-menu item rather than the main settings window. The important sequence is the same: choose a tested profile, select a compatible core, enable the virtual adapter, approve elevation, and verify the route. If the menu shows separate switches for TUN and system proxy, remember that they are independent. TUN can work while the Windows system proxy is disabled.
Verify the adapter, routing, and DNS behavior
A green v2rayN status icon only confirms that the client believes the core is running. Use Windows tools and application-level tests to confirm that packets actually enter the virtual adapter. Open PowerShell and run Get-NetAdapter. Look for a newly created virtual interface whose status is up. You can also open “Network Connections” with ncpa.cpl and compare the adapter list before and after enabling TUN.
Get-NetAdapter
Get-NetIPConfiguration
route print
nslookup example.comThe output is useful only when compared with a baseline. Note the adapter name, interface index, IPv4 address, default route, and DNS servers before starting TUN. After enabling it, check whether a new interface appears and whether the route table contains a route associated with that interface. Do not remove routes manually while the client is active; v2rayN or its TUN component may recreate them, and manual changes can leave Windows in an inconsistent state.
| Test | Expected observation | If it fails |
|---|---|---|
| Virtual adapter | A TUN-related adapter is present and enabled | Check elevation, driver installation, and security software |
| Proxy-independent app | An application that ignores manual proxy settings can reach its test service | Inspect route scope and whether the app uses a special network path |
| DNS lookup | Resolution is consistent with the configured DNS and route policy | Check DNS mode, fallback servers, and cached results |
| Local network | Required printers, NAS devices, or local addresses remain reachable | Add or restore a direct private-network route if supported |
| Core log | Requests appear without repeated startup or handshake errors | Separate local adapter errors from remote-node errors |
Test an external IP address, a domain name, and a local address separately. A domain failure can be caused by DNS even when the tunnel is forwarding packets correctly. An IP test that works while domain access fails usually points toward DNS selection, DNS routing, or a stale Windows cache. Conversely, if both IP and domain tests fail but the node works through SOCKS, inspect TUN routes, firewall rules, and the adapter state.
To check whether an application is bypassing TUN, compare its behavior with the application fully closed and reopened after TUN starts. Some programs keep existing sockets or use a separately configured proxy. A browser extension, application-level VPN, or custom DNS service can also override the path you are testing. Disable only the competing feature, repeat the same test, and keep the node and route settings unchanged.
Why does v2rayN show TUN enabled but no adapter appears?
Close v2rayN, start it with “Run as administrator,” and enable TUN again. If the adapter is still missing, inspect Windows Device Manager, security software quarantine records, and the v2rayN core log. A connected remote node alone does not create the local adapter.
Should I enable the system proxy together with TUN?
Not for the first test. TUN is designed to capture traffic without requiring each application to read the Windows proxy setting. Keep the system-proxy state unchanged, verify TUN independently, and enable the system proxy only if a specific application still requires it.
Why does browsing work but a command-line tool still fail?
Check whether the tool is using a persistent proxy variable, a custom certificate store, IPv6, or a separate DNS resolver. Run the tool after TUN starts, inspect its own error output, and compare IPv4 and IPv6 behavior. If it has a proxy option, remove conflicting values before testing again.
Why can I reach websites but not a local device?
Full-tunnel rules may send private-network traffic to the proxy outbound. Check whether the TUN route configuration provides a direct route for local ranges such as 192.168.0.0/16, 172.16.0.0/12, and 10.0.0.0/8. Use the exact private range used by your router and avoid changing routes blindly.
Troubleshoot common TUN failures
Adapter and permission errors
If TUN stops immediately, the most common causes are missing elevation, a disabled virtual adapter, an existing tunnel from another program, or a blocked driver component. Exit other network interception tools, restart v2rayN with administrator permission, and check Windows Device Manager for warning icons. If the adapter was created but remains disabled, enable it from the adapter properties and restart the TUN service. Avoid deleting every network adapter as a first response.
Port conflicts and core startup
Although TUN captures traffic through an adapter, v2rayN may still start local SOCKS, HTTP, API, or DNS listeners. If the log reports that a port is already in use, identify the process before changing values. In PowerShell, you can inspect a typical listener with Get-NetTCPConnection -LocalPort 10808. Either stop the conflicting application or change the v2rayN local port, then restart the core and repeat the test.
DNS and routing mismatches
DNS behavior is especially important in TUN mode because the application may no longer send a normal Windows DNS request directly. If a domain resolves to an unreachable address, confirm the configured query strategy and whether DNS requests follow the intended direct or proxy outbound. Clear only the relevant cache after changing settings; use ipconfig /flushdns in an elevated Command Prompt, then reopen the test application.
Slow speed, stalls, and fragmentation
Start by comparing the same node in ordinary SOCKS mode and TUN mode. If SOCKS is fast but TUN is slow, inspect MTU, route scope, DNS latency, and whether extra applications are now being proxied. A TUN interface can expose background traffic from update services, synchronization tools, and launchers that were previously direct. Narrow the route policy or exclude unnecessary local traffic before changing the server configuration.
Once TUN works, save the working v2rayN settings and note the core version, node name, adapter status, local ports, and route mode. When updating v2rayN, test the same node with the same route and DNS choices before adding new features. This controlled comparison is faster than replacing the core, changing the subscription, and modifying Windows network settings at the same time.