v2rayN TUN Mode: How It Routes All Traffic and How to Enable It

At a glance

If your browser works through the proxy but your terminal or games do not, first check whether the app uses the system proxy before enabling TUN. This guide follows the typical v2rayN 7.x interface on Windows, walking through node checks, running as administrator, enabling the virtual adapter, and checking DNS and routes. Menus may differ by version. You’ll learn the difference between capturing traffic and proxying it, and how to restore connectivity if things go wrong.

TUN captures traffic at the network entry point

A system proxy registers a local proxy address with the operating system. Apps that honor this setting send requests to v2rayN’s local listening port; apps that ignore it may still connect directly to their destinations. So enabling the system proxy does not mean every app on the computer uses the proxy.

TUN is a virtual interface that operates at the network layer. When enabled, its associated routing rules send matching IP packets through the virtual adapter for processing by the relevant core. Apps do not need their own HTTP or SOCKS proxy settings, making TUN useful for network-enabled programs that cannot be configured to use a proxy individually.

App sends data System selects a route TUN adapter receives it Rules select an outbound route Direct or proxied

One important distinction: TUN does not mean “all traffic goes through an overseas node.” TUN determines how traffic enters the core; routing rules determine where it goes. With a split-tunneling preset such as “Bypass mainland China,” traffic to destinations in mainland China can still connect directly. Only destinations matched by proxy rules use the selected node, while connections matched by block rules are rejected.

Which apps need TUN?

First check whether an app has its own proxy settings, then whether it honors the system proxy. Browsers usually work well with the system proxy, but command-line tools, games, and some desktop apps behave differently. Even within one app, the sign-in window and background downloader may use different networking methods.

Try the system proxy first

Best for: Browsers and apps that honor the system proxy
Traffic path: Local HTTP or SOCKS listener
Permissions: Usually no elevated permissions needed
Start troubleshooting here: Check the app’s proxy settings and the listening port

For web browsing alone, stick with the simpler option.

Consider TUN when

Best for: Apps ignore the system proxy and have no individual proxy settings
Traffic path: Virtual adapter and system routes
Permissions: Usually requires administrator privileges on Windows
Start troubleshooting here: Check the core, adapter, routes, and DNS

For UDP traffic, also confirm that both the node and server support forwarding.

Command-line tools don’t always need TUN. Some support HTTP_PROXY, HTTPS_PROXY, or their own proxy options, which can connect them to the local proxy. TUN is more convenient when an app has no proxy support, you can’t change its launch environment, or you need to route traffic from several apps at once.

Bottom line: test the proxy path before capturing more traffic

If websites work but one app does not, check that app’s proxy settings first. Enable TUN only after confirming it cannot use the local proxy. That keeps a problem with one app from turning into a routing issue for the whole computer.

Check the node and permissions first

Don’t update subscriptions, switch nodes or routing modes, and enable TUN all at once. First establish a reliable baseline with the system proxy. If something breaks later, you’ll know which change altered the network path.

Check the client version. Find the version information under the relevant “Help” menu in v2rayN. The steps here use common v2rayN 7.x menus. If yours look different, check “Settings,” “Parameter Settings,” and the TUN toggle on the main screen rather than copying screenshots from an older version.
Test a subscription node. Update the subscription, select a node as the active server, enable the system proxy, and open a website that requires the proxy. A successful latency test shows only that some connections are reachable; it does not replace testing a website or the target app.
Note your current settings. Record the active node, routing mode, local listening port, and DNS settings. You can save screenshots of the settings, but first hide subscription links, node credentials, and other sensitive information.
Disconnect other tunnels. Temporarily turn off other VPNs, transparent proxies, and network accelerators. On a managed device, follow your organization’s network policies and do not disable managed security services without authorization.
Run with elevated privileges. Fully exit v2rayN from the system tray, then right-click the app and select “Run as administrator.” Approve the system permission prompt. Being able to open the main window without elevated privileges does not mean the app can create an adapter or modify routes.

Enable TUN step by step

After launching as administrator, keep the node and routing preset you just tested. Change only one thing at a time. If a step fails, stop and check the logs instead of repeatedly toggling settings.

Check the TUN settings. Open “Settings” → “Parameter Settings” and look for the TUN section; some versions have a separate TUN settings page. For the first test, keep the defaults for the stack, MTU, and automatic routing options. Don’t copy values from another device.
Clear the system proxy for a clean test. From the main screen or system tray, open the “System Proxy” menu and select “Clear System Proxy.” This lets you test TUN on its own and avoids mistaking browser traffic through the system proxy for TUN traffic.
Turn on TUN. Enable “Enable TUN” or the equivalent toggle on the main screen, then wait for the core to start. Labels and locations vary by version. Check the logs for a virtual interface and successful route initialization.
Check the network interfaces. In Windows’ network adapter list, look for a new or enabled virtual interface. Its name depends on the version and configuration, so don’t expect a particular name. Seeing the interface does not prove that DNS or outbound connections are working.
Test two types of apps. First open a website, then test an app that previously ignored the system proxy. Keep the system proxy cleared so you can tell whether TUN is actually capturing their traffic.

If you can’t find a TUN toggle, first check that your client version and platform support it and that the required core components are installed. Don’t install driver files from unknown sources just because an older guide mentions them. If you need a different build, choose one for your operating system and processor on the client download page.

Verify the result with ports, logs, and routes

These three port numbers help explain how connections fit together; they are not settings you need to change. 10808 is a common example of a local proxy listening port. Check “Settings” → “Parameter Settings” for the actual port. 53 and 443 are commonly used for DNS and HTTPS traffic, respectively.

10808

Example local proxy port; check your actual setting

Common UDP/TCP port for traditional DNS

443

Common TCP port for HTTPS; HTTP/3 commonly uses UDP

Run these read-only commands in PowerShell to inspect interfaces, IPv4 routes, and local listeners. The last command applies only if the listening port is actually 10808; replace it with the port shown in your settings if different. A listening port confirms that the local service is running, but does not by itself prove that TUN is capturing traffic.

Get-NetAdapter | Select-Object Name, InterfaceDescription, Status
Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric
Get-NetTCPConnection -State Listen -LocalPort 10808

Verify traffic capture. Clear the system proxy, make sure the test app has no built-in proxy settings, and start a new connection. Check the core logs to see whether the connection entered the processing chain.
Verify split tunneling. Visit one site that should connect directly and another that should use the proxy. Check the destination and outbound route in the logs. If the logs don’t show rule details, temporarily increase the log level and restore it after testing.
Check the IP address family. If an app still connects directly, check whether it prefers IPv6. Seeing changes to IPv4 routes alone does not prove that IPv6 traffic is being captured too.
Test UDP. Use the target app’s own connection test. A website loading over TCP does not mean games, voice calls, or other UDP traffic will work.

Check DNS and routing together

If a page keeps loading after you enable TUN, the node may not be the problem. Apps usually resolve a domain before connecting. If DNS queries go to an unreachable server, the connection can fail before proxying even begins. Conversely, successful DNS resolution does not prove that the selected proxy outbound is working.

Keep the DNS settings recommended for your client version to start with. If you need to change them, find the DNS settings in “Settings” and consider how domains routed directly and through the proxy are resolved. Don’t just enter a remote DNS address and stop there: check which outbound route reaches it and whether the proxy server’s domain can be resolved during startup.

Distinguish DNS query types. Traditional DNS commonly uses port 53, but encrypted DNS built into an app may use HTTPS. Checking port 53 alone won’t show every domain lookup.
Watch for app caches. After changing settings, close and reopen the target app. If needed, run ipconfig /flushdns. This clears the Windows DNS cache, but may not clear a browser’s own cache or built-in DNS state.
Keep local network traffic on a direct route. Printers, network storage, and router admin pages usually need a direct connection. Test with your router’s actual management address and check private IP ranges and local-domain rules; don’t assume every home network uses the same address.
Watch for virtual networks. Virtual machines, containers, and remote-work tunnels may add their own routes and DNS settings. Check each interface and destination subnet rather than deleting every virtual adapter.

Bottom line: identify where the connection fails before changing settings

If the logs show a DNS timeout, check the DNS path first. If the logs show a connection to the destination but a failed handshake, check the node, protocol, and outbound route. Don’t change DNS, MTU, the TUN stack, and the node all at once, or you won’t know which change helped.

Common conflicts and recovery steps

TUN reports insufficient permissions. What should I do?

Fully exit the app from the system tray, run it as administrator, then enable TUN again. If it still fails, check whether the logs report an interface creation error or a route write error. On managed devices, contact your administrator instead of disabling system security features to bypass the restriction.

The toggle is on. Why is my app still connecting directly?

First make sure the core started successfully, then restart the target app so it doesn’t reuse an existing connection. Check the logs for direct-route rules, IPv6 traffic, and any built-in tunnel in the app. A lit TUN toggle means only that TUN was requested; it does not confirm that a connection is being captured.

Websites load, but games or voice calls still time out?

Confirm that both the subscription node and server support UDP, then check whether the app’s destination matches the right outbound route. TUN can capture traffic, but it cannot add UDP support that the server does not offer, nor does it guarantee lower game latency.

Company networks, virtual machines, or local devices stop working after enabling TUN?

Turn off TUN first and confirm that the original network works again. Then check for destination subnets that overlap with other tunnels, route priorities, and DNS settings. If both must run at once, add explicit direct-route or exclusion rules one by one. Don’t let two traffic-capture components compete for the default route.

The network is still down after closing the client. How can I restore it?

Open v2rayN again, turn off TUN, clear the system proxy, and exit normally. Check whether manual proxy is still enabled in Windows’ proxy settings. If the interface or routes haven’t recovered, reconnect to the network and restart Windows if needed; then use the logs to find any leftover configuration.

Once the network is back, reduce your troubleshooting setup to the essentials: one tested node, one routing preset, and the client’s default TUN settings. Confirm that websites, the target app, and local network access all work before restoring custom DNS or other tunnels one at a time. For a refresher on importing subscriptions and routing basics, see the setup tutorial. For how to enable the system proxy, see the user guide.