How to Enable TUN Mode: Virtual Network Adapter Traffic Capture and Configuration

How TUN Mode Differs from System Proxy Settings

System proxy settings and TUN mode operate at different layers. A system proxy usually writes an HTTP or SOCKS address into the operating system, such as v2rayN’s commonly used local HTTP port 10809. Browsers, download tools, and chat apps must read this setting voluntarily before their traffic enters the client. Apps that ignore system proxies, launchers that force direct connections, and some command-line tools may still access the network directly.

TUN mode creates a virtual network adapter and changes system routes so traffic destined for target IPs first enters the virtual interface. The client reads the packets and passes them to the Xray or v2fly core for domain sniffing, DNS resolution, and rule-based routing. Apps do not need to understand HTTP proxies or be configured with 127.0.0.1 and a port, making TUN better suited to centrally capturing traffic from multiple processes.

“Capture all traffic” does not mean “send every connection through a proxy node.” TUN passes packets to the client; routing rules still decide whether traffic is proxied, sent directly, or blocked. Private network addresses, printer addresses, and sites in mainland China can remain direct, while only requests matching proxy rules use VMess or VLESS outbounds. Traffic capture scope and outbound policy are separate concepts.

• System proxy: Simple to configure and suitable for desktop apps that explicitly support HTTP or SOCKS proxies.
• TUN mode: Covers processes that ignore system proxies and can centrally handle TCP, UDP, and DNS requests.
• Global proxy: A routing decision that gives proxy outbounds priority for captured external traffic.
• Rule-based routing: Selects different outbounds based on domains, IPs, ports, processes, and other conditions.

Enable v2rayN TUN Mode on Windows

The steps below use v2rayN 7.x as the baseline. Button locations may vary between minor releases, appearing in the main window or tray menu, but the core settings remain TUN, routing, and DNS. Creating a virtual adapter for the first time requires administrator privileges. Without elevation, the interface may appear to switch successfully while logs report interface-creation or route-writing failures.

1. Open v2rayN, update the subscription, and select a node that has already been tested and confirmed working.
2. Go to “Settings” → “Parameter Settings” → “TUN Mode,” then confirm the core and stack options used by TUN.
3. Save the settings, exit the client completely, and restart it using the system’s “Run as administrator” option.
4. Open “TUN Mode” from the main window or tray menu. Wait for the status bar to show that it is running, and check the logs for successful virtual-interface and route initialization.
5. Set the routing mode to rule-based routing, keep the local network on direct access initially, then test your browser and apps that previously ignored system proxy settings.

After startup, check the logs rather than relying only on the button color. A normal sequence includes TUN interface creation, route-rule application, and successful core startup. If the log stops while ports are being bound, check whether another v2rayN instance is using 10808 or 10809. If it stops during interface creation, focus on administrator privileges and leftover virtual adapters.

You can temporarily disable the system proxy while testing TUN to confirm that requests are being captured by the virtual interface. If the browser still follows routing rules after the system proxy is disabled and local devices remain directly reachable, TUN and the routing rules are probably working. After testing, avoid repeatedly switching between both capture methods; otherwise it becomes difficult to tell which entry point handled the traffic.

Configure VPN Traffic Capture with v2rayNG on Android

On Android, v2rayNG creates a virtual network interface through the system VPN service, placing it close to desktop TUN mode in the traffic path. When you tap Connect, Android displays a VPN authorization prompt. After approval, traffic from apps within the capture scope enters v2rayNG and is handled by the Xray core according to the node and routing configuration.

Using v2rayNG 1.10.x as the baseline, import the subscription and complete a node latency test first. Go to “Settings” → “VPN Settings” and review VPN mode, app proxy scope, bypass-LAN, and local DNS options. Return to the main screen, choose a node, tap Connect, and approve the system VPN request on first use.

1. In “Subscription Settings,” save the complete subscription URL, update it, and select a working node.
2. Go to “Settings” → “VPN Settings” and keep VPN capture enabled.
3. For full-device capture, do not enable proxying for selected apps only. To narrow the scope, create an app list afterward.
4. Enable bypass LAN to avoid taking a longer route to router admin pages or local network services.
5. Return to the main screen and connect. Confirm that the system VPN indicator appears in the status bar, then test DNS and web access.

If you use v2flyNG, traffic capture likewise depends on the system VPN service, but the running core is v2fly. VMess, VLESS, and transport parameters in the subscription must be supported jointly by the client and core. TUN or VPN capture changes only the traffic entry point; it does not automatically rewrite the server address, UUID, transport layer, or TLS parameters.

DNS, Routing, and UDP Configuration Essentials

If TUN is created successfully but domains will not open, the usual cause is not a disconnected node but DNS requests taking another path. The app may receive an incorrect address, causing the connection to fail even after entering the proxy. Make domain resolution and traffic follow the same routing logic, and avoid having system DNS, client DNS, and browser-specific DNS compete simultaneously.

In v2rayN, go to “Settings” → “Parameter Settings” and review the DNS and routing configuration. If you use domain rules, preserve domain information for the core to match. If the request is reduced to an IP too early, some domain-based routing rules may not match. Sniffing can recover the target domain from some TCP or HTTP traffic, but it is not a replacement for fixing every DNS issue.

When routing rules are matched in order, place specific conditions before the default rule. A common starting order is: direct private IPs, direct local-network domains, proxy domains that explicitly require it, and the default rule for everything else. The more rules you add, the more important it is to confirm the actual match in the logs instead of inferring it from whether a page opens.

Whether UDP works depends on the app, client, running core, protocol configuration, and server capabilities. TUN can capture UDP packets, but that does not mean the selected VMess or VLESS node can fully forward them. If web browsing works but real-time voice or game connections fail, check the UDP logs separately and cross-test with another node known to support UDP.

Common Failures and Recovery Steps

Troubleshoot TUN from the question “Was the virtual adapter created?” Then check routes, DNS, the core, and the node. Replacing the subscription immediately often skips the real problem. In particular, leftover routes after an abnormal client exit can make the entire network appear unavailable; first disable TUN and exit the client completely.

Port conflicts mainly affect local HTTP, SOCKS, or control interfaces. On Windows, first inspect which process is listening on 10808 and 10809 in the terminal, then decide whether to close the old instance or change the ports. After changing ports, update the system proxy settings as well; otherwise the system will continue sending requests to the old port, making TUN or the node appear broken.

netstat -ano | findstr :10808
netstat -ano | findstr :10809
tasklist | findstr <PID>

When disabling the setup, turn off TUN inside the client before exiting the program; do not terminate the core process directly. A normal shutdown removes temporary routes and releases the virtual interface. When switching between TUN and the system proxy, complete one shutdown and network check before enabling the other mode.

1. Disable TUN or the Android system VPN connection.
2. Exit v2rayN, v2rayNG, or v2flyNG completely.
3. Confirm that the system proxy no longer contains 127.0.0.1:10809.
4. Test direct internet access, the local gateway, and DNS resolution.
5. Restart the client and retest with only one traffic-capture method enabled.

Verify That TUN Is Really Capturing Traffic

Do not rely only on an “Connected” status. A complete test should cover one app that supports system proxies, one app that ignores them, one local-network address, and one UDP function. These four results show whether virtual-interface capture, rule routing, LAN bypass, and UDP forwarding are working.

• Disable the system proxy, keep only TUN enabled, and confirm that ordinary web pages still load.
• Run an app that previously bypassed the system proxy and check whether its destination appears in the core logs.
• Open the router gateway or a local-network device and confirm that the request matches a direct rule.
• Run a DNS test and confirm that resolution requests and proxy traffic follow the expected paths.
• Test real-time voice or another UDP scenario and confirm that it does not continually time out.

Logs are the final source of truth. In v2rayN, the main-window runtime log shows inbound connections, destinations, and outbound labels; in v2rayNG, the log page shows connection establishment and routing results. If the destination request never appears, the issue is the capture scope or system routing. If it appears but the outbound is wrong, the issue is the rules. If the outbound is correct but the connection still fails, check the node and destination network.

TUN is designed for entry-point problems where an app does not follow proxy settings. Once the configuration is stable, keep a clear baseline: client version, subscription update time, current node, routing mode, DNS settings, and local ports. Change one variable at a time and record the before-and-after logs; this is easier to diagnose than repeatedly reinstalling the client.