How to Enable TUN Mode: How Virtual Network Adapters Capture All Traffic and Setup Steps

TUN mode solves traffic capture—not node connectivity

A standard system proxy usually registers an HTTP or SOCKS proxy address with the operating system. Browsers and apps that honor system proxy settings send requests to the local inbound port; apps that ignore those settings, use their own network stack, or open UDP connections directly may continue using the default physical adapter. The node can be working normally while the app sends none of its traffic to the client.

TUN mode changes where traffic enters the stack. The client creates a virtual layer-3 network adapter and writes capture rules to the system routing table. IP packets from apps first enter the virtual adapter, then v2rayN or v2rayNG passes them to the Xray core. The core matches routing rules by domain, destination IP, port, and protocol, then selects a direct, proxy, or blocked outbound.

“Capture all traffic” does not mean sending every packet to a remote node unconditionally. LAN addresses, the client’s own connections, reserved system ranges, and explicitly configured direct rules should still bypass the proxy. A correct TUN setup must prevent proxy loops: traffic generated by the core to connect to the server must not re-enter the same proxy chain, or connections may time out, CPU usage may rise, or the network may stop working entirely.

• System proxy: Low setup overhead; suitable for browsers and regular desktop apps that honor proxy settings.
• TUN mode: Broader coverage; handles TCP and most UDP apps that do not read system proxy settings.
• Split routing: Determines where traffic goes after entering the core; it is a separate layer from whether TUN is enabled.
• Node protocol: VMess, VLESS, and others handle transport between the client and server; they do not make local apps use the proxy.

Check permissions, the core, and existing network components first

Creating a virtual network adapter and changing the system routing table require elevated privileges. On Windows, v2rayN usually needs administrator rights to start TUN; macOS and Linux request system authorization the first time they create a network interface or write routes. On Android, v2rayNG uses the system VPN service to create the virtual interface, and the first launch prompts for connection permission.

The values below describe the reference environment for this guide, not minimum versions for protocol compatibility. Menu labels may change between releases, but the checking order stays the same: confirm that the core starts, verify that the virtual adapter exists, then check whether the default route and DNS have switched.

1. First connect to the same node in standard system-proxy mode and confirm that the server address, port, user ID, TLS, or REALITY settings work.
2. Quit other network tools that create virtual adapters, change the default route, or take over DNS so that two rule sets do not apply at once.
3. Record the LAN subnet currently in use. For example, home routers commonly use 192.168.1.0/24; this range should usually remain direct.
4. Check for local port conflicts. If 10808 is already used by another process, change the port in the client parameters and restart the core.
5. Keep one working node as a baseline. When a subscription contains multiple nodes, do not switch between them repeatedly while troubleshooting TUN.

Complete steps to enable TUN in v2rayN on desktop

Update the subscription and select a node already verified with a standard proxy. Both VMess and VLESS can be used as TUN proxy outbounds; TUN does not alter node fields or require a new subscription. If an imported node cannot connect in standard mode, fix its configuration before troubleshooting the virtual adapter.

1. Launch with permission: Fully quit v2rayN. On Windows, run it again as administrator; on macOS or Linux, approve network configuration changes when prompted.
2. Check inbound parameters: Open “Settings” → “Parameter Settings” and confirm that the local mixed port is available. This guide uses 10808.
3. Check TUN parameters: Go to “Settings” → “Parameter Settings” → “TUN Mode Settings”. Keep the default stack and MTU initially; do not change multiple advanced fields at once.
4. Choose a routing mode: Select the required routing rules on the main screen. For the first test, use rules with broad proxy coverage; once capture is confirmed, restore domain- and IP-based split routing.
5. Turn on TUN: Enable the “TUN Mode” switch on the main screen. The status bar should show the core running, and a new virtual interface should appear in the system network list.
6. Verify connectivity: Test a browser, a command-line app, and an application that previously bypassed the proxy. If only the browser works, continue by checking the routing table and DNS instead of looking only at the system proxy switch.

After enabling TUN, do not judge the result only from a web page. Run a domain lookup in a terminal, visit a target routed by IP rules, and watch v2rayN logs for inbound entries. New connections from TUN confirm that traffic has reached the core; no log entries point more strongly to permissions, the virtual interface, or system routes.

How v2rayNG captures traffic on Android

v2rayNG creates a virtual network interface through Android’s VPN service; the connection button starts more than a local HTTP proxy. With the Xray core, app traffic enters the virtual interface and is then passed to the routing module, allowing rules to handle apps that do not read system proxy settings.

1. Import a configuration: Update the server list with a subscription link or import a complete VMess or VLESS configuration. Select a node and run a real connection latency test once before proceeding.
2. Check the operating mode: Open “Settings” → “Mode” and confirm that VPN capture is enabled, rather than only exposing a local proxy port to the LAN.
3. Check VPN parameters: Go to “Settings” → “VPN Settings” and keep the default MTU initially. If some pages stall on the current network, lower it gradually.
4. Set per-app rules: To route all apps through the same policy, disable unnecessary app exclusions; to capture only selected programs, explicitly choose include mode or bypass mode.
5. Start the connection: Return to the main screen, tap Connect, and accept the system network connection permission. Test the target app after the status bar shows an active connection.
6. Check the logs: Open the logs from the main menu and watch DNS queries, route matches, and proxy outbounds. Repeated reconnects usually indicate a node failure or an underlying network switch, not that the app is missing from the list.

Android usually allows only one VPN service to remain active. If another network tool is still connected, v2rayNG may fail to create the virtual interface or be terminated immediately after connecting. Battery-saving policies may also restrict background processes after the screen turns off; if traffic stops after the device locks, check Android’s background and battery-use settings for v2rayNG.

• Only one app fails: Check the per-app proxy list and whether that app uses its own DNS or a special UDP channel.
• All apps fail: Check the node, system authorization, and whether the current Wi-Fi or mobile network is working.
• LAN devices become unreachable after connecting: Confirm that private addresses are not being sent incorrectly through the proxy outbound.
• Mobile data works but Wi-Fi does not: Focus on differences in Wi-Fi DNS, IPv6, and MTU.

Routing, DNS, and MTU determine real-world capture behavior

TUN only sends data into the processing chain; routing rules determine the final result. Common rules match domains, destination IPs, ports, or network types. Private and local addresses usually stay direct, domains that need a proxy use the proxy outbound, and advertising or risky domains can use a block outbound. Rule order matters: an overly broad rule placed first can mask later, more specific rules.

DNS is the most easily overlooked part of TUN troubleshooting. After an app requests a domain, the client needs domain or IP information for routing decisions. If another local service still intercepts queries, returns unreachable addresses, or produces an address family inconsistent with the routing rules, you may see “the client is connected, but some domains will not open.”

Do not lower MTU too far in one step. Test 1500, 1460, and 1400 in order, reconnecting after each change and comparing with the same node, network, and download target. An MTU that is too large can cause fragmentation or path loss; one that is too small increases packet count and processing overhead.

Recommended split-routing priority:
1. Local addresses and the client process → Direct
2. LAN and private addresses → Direct
3. Explicitly blocked domains or IPs → Block
4. Domains and address ranges requiring a proxy → Proxy
5. Remaining traffic → Follow the current policy

Locate common conflicts by symptom

TUN troubleshooting should not begin with “reinstall the client.” A more effective approach is to read logs through four layers: entry, resolution, routing, and outbound. Change one variable at a time, recording connection times, log keywords, and the scope of failures before and after each change.

When TUN is suitable for long-term use

TUN is useful when multiple programs need unified capture, UDP must be handled, or proxy addresses cannot be configured app by app. It eliminates the need to enter a SOCKS port in every app, but it also broadens the impact of mistakes: one incorrect default route can disconnect the entire device, and an overly broad proxy rule can send LAN traffic on an unnecessary detour.

• Enable it when: Apps do not read system proxy settings, UDP needs a proxy, multiple apps need unified split routing, or command-line tools switch frequently.
• It may not be needed when: Only a browser needs the proxy and it already follows system proxy settings reliably.
• Use split routing when: You access LAN devices, direct services in mainland China, and proxied destinations at the same time and want to control the egress scope.
• Temporarily disable it when: You are troubleshooting local networking, router settings, or DNS and need to restore the simplest physical network path first.

A maintainable setup keeps three boundaries clear: the client’s own connections stay direct, LAN and reserved addresses stay direct, and destinations requiring a proxy use VMess or VLESS outbounds. When a subscription update only replaces the server list, TUN and routing rules usually do not need to be rebuilt; if the new subscription changes protocol fields or core requirements, verify the node in standard proxy mode first.

After setup, keep a fixed test set: browse in a browser, resolve a domain in a terminal, access a LAN device, test one UDP app, and download one large file. These five checks cover system proxying, DNS, private ranges, UDP capture, and MTU. Repeat them in the same order after future upgrades or routing-rule changes.