How to Enable TUN Mode: How a Virtual Network Adapter Takes Over All Traffic

System proxy and TUN mode operate at different points in the traffic path

After a proxy client is enabled, a browser may reach the target website while a game launcher, command-line tool, or desktop app still connects directly. This is the most common reason to use TUN. The issue is usually not the node, but whether the traffic reaches the client. Both system proxy and TUN mode can hand requests to V2Ray or Xray, but they enter the traffic path at different points.

A system proxy writes an HTTP or SOCKS proxy address into the operating system. Apps that respect this setting send requests to v2rayN’s local listening port, after which the core uses routing rules to choose proxying, direct access, or blocking. Browsers and most desktop software that follows system network settings are usually covered, but apps with their own network stack, UDP-only traffic, ignored system proxy settings, or hard-coded direct connections may bypass this entry point.

TUN mode creates a virtual network adapter and adds the corresponding routes to the system. Packets within the route scope first enter the virtual adapter, then the client converts them into connections the proxy core can process. Apps do not need to know the local proxy port or be configured with a SOCKS address. TUN is therefore better suited to command-line tools, game traffic, UDP requests, and mixed traffic from multiple apps.

Comparison	System proxy	TUN mode
Capture layer	Apps actively read proxy settings	System routes send packets into a virtual adapter
App compatibility	Apps must support HTTP or SOCKS proxies	Most apps need no separate proxy configuration
UDP coverage	Depends on the app and proxy entry point	The virtual adapter can capture it centrally and pass it to the core
Permissions	Usually works with standard user permissions	Creating an adapter and changing routes may require elevated privileges
Troubleshooting complexity	Short traffic path; suitable for everyday web browsing	Requires checking the adapter, routes, DNS, and core logs

Capturing all traffic does not mean every connection uses the proxy

“TUN capturing all traffic” and “forcing every connection through the proxy” are two different things. The former describes the traffic entry point: packets first enter the virtual adapter. The latter describes the routing result: after entering the core, are they sent to a proxy outbound? As long as the routing rules remain valid, traffic received by the same TUN adapter can be sent through a proxy, connected directly, or blocked.

For example, LAN addresses, router admin pages, and some local services can stay direct; domains and IPs that require a proxy can go through the current node; ad domains or explicitly unwanted destinations can be blocked. The routing mode selected in v2rayN, custom user rules, and the core configuration together determine the final outbound. After enabling TUN, do not remove the existing split-routing logic wholesale. First verify that the rules still behave as expected through the new entry point.

A connection generally follows this path:

The app opens a domain or IP connection
→ Operating system routing table
→ TUN virtual adapter
→ DNS resolution and traffic identification
→ Routing rules in V2Ray, Xray, or a compatible core
→ Proxy outbound / direct outbound / block

The routing loop is the part most often overlooked. Traffic used by the proxy client to connect to its server must not be sent back into TUN, or it can create a loop: the client connects to the node, and that connection returns to the client. Mature clients avoid this through excluded routes, interface binding, or process handling, but firewalls, other virtual adapters, and manual routes can change the result. If every connection times out immediately after enabling TUN, first check the logs for repeated connections, routing loops, or a server address captured by mistake.

Enable TUN mode in v2rayN

Button locations may change between v2rayN versions, but the workflow is largely the same: stabilize a regular proxy connection first, then start TUN with the privileges needed to configure a network adapter. Do not change subscriptions, routes, DNS, and TUN settings at the same time before the node is verified; otherwise, it becomes difficult to identify the cause of a failure.

Import the subscription and update the nodes.
Add the complete subscription URL in v2rayN, update the subscription, and select an available node. First use the system proxy to open familiar websites and review the connection logs. Confirm that the node address, port, UUID, transport, and TLS parameters work correctly.
Confirm the routing mode.
Check whether the current mode is global, bypasses the LAN and common direct addresses, or uses custom rules. When enabling TUN for the first time, keep a rule set whose results are easy to interpret, and make sure LAN subnets are not mistakenly sent to a remote destination.
Grant permission to create a virtual network adapter.
Exit v2rayN completely, restart it with administrator privileges, and then use the TUN switch in the interface. Some versions offer service mode; follow the client’s prompts to install and start it. Once the service is running normally, you will not need to handle the same authorization repeatedly during everyday switching.
Enable TUN and watch its status.
Open TUN mode from the main window, tray menu, or status bar. The client starts the relevant core, creates a virtual network adapter, and writes the routes. After the status shows that it has started, check the system network adapters for the corresponding virtual interface.
Test traffic by category.
Test a browser first, then an app that previously ignored the system proxy, and finally a UDP-dependent scenario. Check the live logs at the same time to confirm that requests match the expected proxy or direct rules, rather than judging only by whether a webpage opens.

v2rayN can manage different cores. Which compatible core handles TUN depends on the client version, current configuration, and selected feature. If the logs say that the core does not support a TUN parameter, do not repeatedly toggle the switch. First confirm that the client and its companion core are compatible, then check whether the configuration still contains fields from an older version.

After TUN is working, the system proxy switch does not necessarily need to remain enabled. TUN can capture target traffic at the routing layer, while leaving the system proxy on may send some apps through the local proxy port and others through the virtual adapter. Both entry points can coexist, but during troubleshooting it is best to keep only one as the primary entry point so the logs make the connection path easier to verify.

Capture Android device traffic with v2rayNG

On Android, v2rayNG captures traffic through the system-provided VPN interface, serving a role similar to a desktop virtual network adapter. Some versions do not show a separate switch labeled “TUN”; instead, tapping Connect requests VPN permission. Once the system status area shows an established connection and traffic is entering v2rayNG, apps are using this virtual network entry point.

Import a working configuration.
Update nodes through a subscription URL, or import a complete VMess or VLESS configuration. After selecting a node, check its address, port, and transport parameters first so configuration errors are not mistaken for virtual network problems.
Tap Connect and confirm system permission.
When the VPN interface is created for the first time, the system displays a connection confirmation. After granting permission, v2rayNG can create the virtual interface and receive packets from other apps. If permission was previously denied, stop the connection, start it again, and check the VPN management status in the system settings.
Set the app scope and routes.
If the version offers per-app proxy or bypass options, first decide whether to cover every app or send only selected apps through the virtual interface. Routing rules still determine proxy versus direct handling after traffic enters the core; the app scope determines which programs can enter this path.
Handle background activity limits.
Allow v2rayNG to maintain the background network activity it needs so the system does not terminate the connection after the screen locks. If it works while the screen is on but disconnects after being locked for a while, check battery policies and background restrictions before changing nodes repeatedly.

v2rayNG uses the Xray core and suits configurations that require Xray protocol and transport capabilities. v2flyNG uses the v2fly core; its workflow is likewise to import a configuration, establish the system virtual network, and process traffic according to routing rules. Do not assume their configuration features are interchangeable just because the interfaces look similar. If a subscription includes core-specific fields, use a client that recognizes them.

DNS settings determine whether domain-based routing is accurate

After TUN is enabled, establishing a connection depends not only on the node but also on who handles DNS requests. When an app accesses a domain, routing rules may need domain information to match geosite, full domains, or domain suffixes. If the system resolves the domain to an IP before it reaches the core, the core may see only the destination IP. Whether domain rules still work then depends on sniffing, DNS mapping, and the specific configuration.

A common problem is that DNS requests do not enter the client. Web requests go through TUN, but domain lookups still use the original network interface, causing a mismatch between resolution results and the proxy exit, timeouts for some domains, or inconsistent rule matching. Another problem is enabling multiple DNS capture features at once, such as client DNS, encrypted system DNS, and other network tools rewriting the query path. This can result in duplicate forwarding or a DNS loop.

Organize DNS in this order:

First disable other network tools that modify the virtual adapter, routes, or DNS, leaving only v2rayN or v2rayNG active.
Use DNS settings supported by the client’s current version instead of copying fields from an old configuration into a newer core.
When using domain-based routing, confirm that the core can obtain domain information, then check the logs for the domain or IP that actually matched the rule.
Choose suitable resolution paths for direct and proxied domains, and prevent proxied domains from being resolved and mistakenly sent through a direct outbound.
After changing DNS, establish the TUN connection again so the virtual adapter address, routes, and resolution settings refresh together.

“Enable sniffing” is not always better. Sniffing can recover domain names from some connections and help domain rules match, but it cannot replace a complete DNS design and does not work for every type of protocol traffic. When an app behaves abnormally, use the logs to determine whether DNS returned no result, the destination IP is unreachable, or the rule sent the connection to the wrong outbound.

Troubleshooting order when TUN cannot connect to the internet

Check a TUN failure layer by layer, starting at the local entry point and moving outward. Switching through a dozen nodes only adds variables. Confirm the virtual adapter first, then routes and DNS, and only afterward assess the node and server status.

1. The virtual network adapter does not appear

If the switch immediately turns itself off or the logs report an interface creation failure, exit the client completely and restart it with sufficient privileges. Then check whether a broken virtual adapter with the same name remains in the system and whether security policies are blocking network-device creation. Do not manually delete an interface that the client is still using.

2. Every connection times out after enabling TUN

Turn off TUN first and use the system proxy to verify the current node. If the regular proxy also times out, the issue is with the node, subscription parameters, or underlying network, and further TUN changes will not help. If the regular proxy works, enable TUN again, check whether the node server address is being sent back into the virtual adapter, and confirm that another network tool has not overridden the default route.

3. Websites open, but games or voice connections fail

This usually requires checking UDP. Confirm that the protocol, transport path, and outbound support UDP traffic, then check whether the app’s packets enter TUN. A working webpage proves only that part of the TCP and DNS path works; it does not prove that UDP is being forwarded along the same path.

4. Domains fail, but direct IP access responds

Focus on DNS. Check the logs for resolution timeouts, query loops, or an unreachable DNS outbound. Stop other programs that capture DNS, reconnect TUN, and test a direct domain and a proxied domain separately. If only a particular rule group fails, check whether it uses domain, geosite, or resolved-IP conditions.

5. LAN devices cannot be reached

Check that private addresses are set to direct access, and make sure the local firewall has not identified the virtual adapter as a new network requiring stricter restrictions. Common LAN ranges should be handled explicitly by the routing rules. If you need to access a printer, router, or shared device, test its LAN IP first, then troubleshoot device-name resolution.

6. The network does not recover after turning off TUN

Exit the client normally so it can clean up the routes, then re-enable the current physical network interface. Check whether the system proxy still points to a closed local port, and confirm that the default gateway and DNS have returned to the usual network settings. Force-ending the process may prevent temporary settings from being cleaned up, so use the client’s Stop and Exit actions whenever possible.

Choosing between system proxy, TUN, and routing modes

For everyday web browsing, subscription updates, and software that clearly supports system proxies, start with the system proxy. Its traffic path is shorter, it requires fewer privileges, and its logs are easier to read. Switch to TUN for desktop apps that ignore system proxies, command-line downloads, games, or UDP traffic.

When the entire device needs coverage, use TUN to capture traffic centrally, then split it with routing rules instead of treating “capture all traffic” as “proxy everything.” A sensible setup usually keeps LAN traffic direct, routes domains or rule sets that need a proxy through the node, and leaves a clear, log-traceable path for unreachable destinations.

Change one variable at a time: verify the node before enabling TUN; confirm the adapter before adjusting DNS; observe rule matches before adding complex split routing. v2rayN, v2rayNG, and v2flyNG show the connection entry point, destination, outbound choice, or error cause in their logs. Matching the logs to real tests is more effective than switching nodes repeatedly.