How To Set Up TUN Mode In v2rayN On Windows 11

Quick overview

This guide explains how to enable TUN mode in v2rayN on Windows 11 and how to verify that traffic is actually entering the virtual network interface. It covers the required Wintun driver, administrator permissions, TUN and routing options, DNS behavior, coexistence with the Windows system proxy, and the most common startup and connection errors. The examples use v2rayN 7.x terminology; menu names can differ slightly between releases and selected core types.

What TUN mode does in v2rayN

v2rayN normally works as a local HTTP or SOCKS proxy. Applications must follow the Windows proxy setting or be configured manually before their traffic reaches the local listening port. TUN mode uses a virtual network adapter instead. Windows sends IP packets to that adapter, and the selected core reads those packets, applies routing rules, and forwards them directly or through a remote node.

This difference matters for programs that do not understand HTTP or SOCKS proxies. Command-line tools, launchers, games, development environments, and background services may ignore the system proxy, while TUN mode can capture their IP traffic at the network layer. It does not automatically make every application compatible, however. Some software uses its own encrypted tunnel, installs another filter driver, or relies on special DNS and UDP behavior that still requires separate configuration.

Application creates packetWindows routes to TUNCore reads packetRules select outboundRemote or direct exit

On Windows 11, the virtual adapter is commonly supplied by Wintun. The adapter is not the same thing as the v2rayN process, the system proxy, or the remote server. v2rayN controls the configuration and starts the selected core; Wintun provides the kernel-level interface through which packets are captured. If the adapter is missing, disabled, or blocked by permissions, TUN mode may appear enabled in the interface while no application traffic is actually being processed.

Captures IP traffic through a virtual adapter and can cover applications that ignore Windows proxy settings. It requires a working Wintun driver, administrator approval, and suitable DNS and routing rules.

Best for: whole-system traffic, UDP applications, and software without proxy options

Writes a local HTTP proxy address into Windows settings. It is easy to inspect and usually sufficient for browsers, but applications that bypass system proxy settings will not be captured.

Best for: browser traffic, simple testing, and low-risk daily browsing

Uses a port such as SOCKS 10808 or HTTP 10809 configured inside one application. This gives precise per-application control but requires every supported application to be configured separately.

Best for: development tools, isolated tests, and applications with proxy fields

Bottom line: use TUN for capture, not as a substitute for routing design

TUN mode determines how packets enter v2rayN; the routing profile still determines whether those packets go direct, use the selected node, or are blocked. Start with a simple rule set and confirm the packet path before adding complex domain, IP, and DNS rules.

Prepare Windows 11 before enabling TUN

First update v2rayN from a trusted package source and confirm the program architecture matches the operating system. Most Windows 11 installations on modern desktop and laptop computers use x64. Close duplicate v2rayN processes before testing, because two instances may compete for the same local ports, virtual adapter, or core configuration. In the taskbar notification area, exit older instances rather than merely closing the main window.

Back up the current configuration before changing the network mode. Export or copy the working node and subscription information, and record the current local ports. Typical v2rayN 7.x defaults are SOCKS 127.0.0.1:10808 and HTTP 127.0.0.1:10809, but the actual values may have been changed. TUN mode does not require these ports for packet capture, yet they remain useful for testing, subscription updates, and applications that continue to use a proxy explicitly.

10808

Common local SOCKS port

10809

Common local HTTP port

Virtual adapter needed

Admin

Permission level for setup

Install or allow the Wintun driver when v2rayN requests it. Windows may display a User Account Control prompt, and security software may ask whether the driver installation should be permitted. A driver warning should not be dismissed blindly: verify that the v2rayN package is genuine, then approve only the requested installation. If the prompt never appears, start v2rayN with Run as administrator for the first setup.

Check the driver and virtual adapter

Open Windows 11 Settings → Network & internet → Advanced network settings. Under network adapters, look for a Wintun or v2rayN-related virtual adapter after TUN has been started. The exact display name depends on the client build and core integration. The adapter should not remain disabled. You can also open Device Manager → Network adapters and inspect whether Windows reports an error icon or a driver problem.

Do not manually assign a normal home-LAN gateway to the TUN adapter. v2rayN and the selected core normally manage the virtual interface and routes. Adding a static address or gateway from a forum example can create route loops, send all traffic into an inactive interface, or interfere with the physical Ethernet or Wi-Fi adapter.

Enable TUN mode step by step

Use a simple node first. A VLESS or VMess node that already works through the ordinary system proxy is a better test case than a new node and a new TUN configuration at the same time. Select the node in v2rayN, start it, and confirm that a normal browser request succeeds before changing the capture method.

Start as administrator
Exit duplicate v2rayN instances, right-click v2rayN, choose Run as administrator, and approve the Windows User Account Control prompt. Administrator access is commonly required to create or modify the virtual adapter and system routes.
Open TUN settings
In v2rayN, open Settings → TUN mode settings. On builds that place the option elsewhere, look under Settings → Parameters or the main mode menu for the TUN configuration entry.
Select a TUN core
Choose the core supported by the installed v2rayN build. TUN implementations may expose different options for Xray and sing-box, so do not copy a sing-box-only field into an Xray configuration. Apply the configuration and allow the driver prompt if shown.
Set the virtual interface
Enable the TUN switch, keep the default virtual interface name unless it conflicts with another adapter, and leave automatic address management enabled. Avoid changing MTU during the first test; a value around 1500 is commonly suitable on ordinary networks, while VPN or PPPoE paths may require later adjustment.
Choose routing behavior
Start with the client’s basic rule profile, then select the intended mode such as Global or a bypass profile. Confirm whether private addresses, local domains, and LAN ranges should remain direct. Save the settings and restart the core when v2rayN asks for a reload.
Start and inspect logs
Return to the main window, start the selected node, enable TUN mode, and open the core log. Look for a successful TUN inbound or virtual interface message, a listening state, and the absence of route or permission errors before testing applications.

The order is important. Starting TUN before selecting a working outbound can make every application appear offline, while testing only the system proxy cannot confirm TUN capture. After enabling the mode, temporarily disable the Windows system proxy or use the client’s own clear-proxy command if the goal is to test TUN alone. Leaving both paths active is not always harmful, but it can make browser behavior difficult to interpret because the browser may use the HTTP proxy while another application enters through TUN.

Choose routing and DNS carefully

For a first test, Global Mode can make the packet path easier to understand because most captured traffic uses the selected remote outbound. A bypass profile is more efficient for daily use, but it depends on correct domain and IP rules. Private ranges such as 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 usually need direct access when connecting to printers, NAS devices, routers, or other local services.

DNS is a separate part of the design. If Windows resolves a domain directly while the core routes the connection through a remote node, the result may be inconsistent or reveal a different location than expected. If the TUN profile provides DNS handling, use its documented DNS mode and confirm that the selected core supports it. Do not add several DNS applications, encrypted resolvers, and manual Windows overrides at the same time. Change one resolver path, restart the core, and compare the result.

Setting	First-test choice	Why it helps	Change later when
System proxy	Off for an isolated TUN test	Prevents browser traffic from hiding whether TUN works	Some applications still need the local HTTP proxy
Routing mode	Global temporarily	Reduces the number of rule matches during diagnosis	Basic connectivity is confirmed
Private LAN ranges	Direct	Preserves access to routers and local services	A deliberate LAN proxy policy is required
MTU	Automatic or default	Avoids introducing fragmentation during setup	Specific networks show packet loss or unstable UDP
DNS	One documented resolver path	Makes resolution failures easier to isolate	Regional rules or split DNS are needed

Test TUN capture on Windows 11

Test in layers instead of opening a large application immediately. First confirm that the core is running and the selected node works through the existing local proxy. Next inspect the adapter and routes. Finally test a browser, a command-line request, a UDP-dependent application, and a local LAN address. This sequence distinguishes an outbound failure from a capture failure.

In v2rayN, open the log panel and confirm that the core started without a bind, permission, or configuration validation error.
In Windows Terminal, run ipconfig and inspect the adapter list for the virtual interface. The name and address are implementation-dependent, so focus on whether it exists and is active.
Run route print and check that TUN-related routes were added without replacing the physical adapter’s local-network route.
Use curl.exe -I https://example.com for a basic HTTPS test. If the command uses an explicit proxy, remove that option when testing TUN capture itself.
Open a browser only after the command-line test succeeds, then compare the result with the system proxy disabled and enabled.

A successful browser page does not prove that every connection uses TUN. The browser may still be following the HTTP proxy at 127.0.0.1:10809. To make the test meaningful, record whether the system proxy is enabled, whether the application has a manually configured proxy, and which routing mode is active. For applications that expose connection diagnostics, compare TCP and UDP behavior separately.

Basic TUN test

Capture: TUN enabled
Mode: Global temporarily
Proxy: System proxy off
Test: curl.exe HTTPS request

Use this profile to confirm that packets enter the virtual adapter rather than the browser’s manual proxy.

Daily split routing

Capture: TUN enabled
Mode: Bypass profile
LAN: Private ranges direct
DNS: One selected resolver

Use this profile after the basic test succeeds and local services have been verified.

Fix the errors beginners see most often

Most TUN failures are caused by permissions, a missing driver, a conflicting adapter, or a routing choice rather than by the remote node itself. Read the first error that appears after startup. A later “connection failed” message may only be a consequence of the virtual interface never being created.

Error: Access is denied

Cause and fix: v2rayN cannot create the adapter or change routes with the current token. Exit the client, start it with Run as administrator, approve UAC, and retry. If the error remains, check whether endpoint security software blocks virtual network drivers.

Error: Wintun.dll or Wintun driver not found

Cause and fix: The required driver files are missing, quarantined, or incompatible with the package. Re-extract v2rayN to a writable folder, restore the approved driver file if security software quarantined it, and reinstall through the client’s TUN settings instead of downloading a random DLL.

Error: Failed to create TUN interface

Cause and fix: Another VPN, tunnel client, stale adapter, or duplicate v2rayN process may already own the interface name. Disable the unused tunnel, close duplicate processes, remove only the clearly stale virtual adapter from Windows network settings, and restart v2rayN as administrator.

Error: Address already in use

Cause and fix: A local HTTP, SOCKS, DNS, or API port is occupied. Check the configured ports in v2rayN, use netstat -ano | findstr :10808 or the relevant port, identify the process in Task Manager, and choose a free port rather than starting multiple cores.

Error: TUN starts but no websites open

Cause and fix: The virtual adapter exists, but the selected outbound, DNS path, or routing rules are invalid. Switch temporarily to a known-working node and Global Mode, test an IP and a domain separately, then restore bypass rules one group at a time.

If the network becomes unusable after a failed attempt, disable TUN from v2rayN first. If the client cannot open, go to Settings → Network & internet → Advanced network settings, disable the v2rayN or Wintun adapter, and restore the physical adapter. Do not delete Ethernet or Wi-Fi drivers. A restart is useful only after the client and adapter state have been corrected; it should not replace identifying the failed setting.

Build a stable daily configuration

Once TUN works in a simple test, reintroduce the features needed for daily use. Change from Global Mode to a bypass profile, enable direct access for private LAN ranges, and test local services such as the router management page or a network printer. Then check ordinary web traffic, software updates, command-line tools, and an application that uses UDP. Keep a short record of each change and its result.

Use one capture method as the primary path. If TUN is enabled, leaving the Windows system proxy enabled may still be useful for applications that explicitly require HTTP, but it should be intentional. When diagnosing a failure, temporarily turn off the system proxy so that the request path is unambiguous. When TUN is disabled, use v2rayN’s system-proxy switch consistently rather than leaving a stale 127.0.0.1:10809 entry in Windows.

Updates to v2rayN, Xray, sing-box, Windows, or Wintun can change driver behavior and configuration validation. After an update, verify the core version in the log, confirm that the TUN adapter is recreated, and test DNS and LAN access again. Keep the old working configuration until the new build has passed these checks. A subscription update can also introduce a node or transport field that the selected core does not support, so test with the previously working node before blaming TUN.

For a clean final check, disable the system proxy, keep TUN enabled, use the intended bypass profile, confirm ordinary HTTPS access, verify that a private LAN address remains reachable, and inspect the v2rayN log for repeated connection errors. If all four checks pass, the configuration is ready for normal use. If only one application fails, investigate that application’s own network stack or firewall rules instead of rebuilding the entire TUN profile.