This guide is for users whose games, command-line tools, or standalone apps do not use the system proxy. It follows the virtual network adapter data path, covers v2rayN on Windows and v2rayNG on Android, and explains how to diagnose DNS, routing, permissions, and virtual adapter conflicts.
The Core Difference Between TUN Mode and System Proxies
A system proxy is a set of proxy parameters exposed by the operating system for apps to read. Browsers and some desktop software read these settings and send HTTP or SOCKS requests to v2rayN's local listening port. The catch is that each app decides whether to honor the system proxy. Command-line programs, game launchers, apps with custom network stacks, and some UDP programs may ignore it completely.
TUN mode creates a virtual layer-3 network adapter and changes the system routes so destination IP packets enter that adapter first. The client passes captured TCP and UDP traffic to the Xray core, which then selects direct, proxy, or blocked outbound connections based on domain, IP, port, and protocol rules. Apps do not need to understand proxy protocols, so coverage is usually more complete than with a system proxy.
“Full-traffic capture” does not mean “every connection uses a proxy node.” TUN sends traffic into a unified entry point; routing rules still determine the final outbound path. For example, LAN addresses can go direct, sites in mainland China can go direct under GeoSite and GeoIP rules, and other traffic can use the proxy node. Traffic capture and routing decisions are separate layers.
| Comparison | System proxy | TUN mode |
|---|---|---|
| Traffic captured | Apps that actively read proxy settings | IP traffic routed by the system into the virtual adapter |
| UDP handling | Depends on the app and proxy interface | Can be handled centrally by the core, subject to node capabilities |
| Permissions | Usually standard user permissions | Usually requires administrator privileges on Windows |
| Common uses | Browsers, office software, and everyday web access | Games, terminal tools, apps with standalone network stacks, and unified traffic routing |
Bottom line: identify the coverage gap before enabling TUN
If only one app that ignores the system proxy cannot connect, TUN can fill that coverage gap directly. If the browser also cannot reach sites through the node, troubleshoot the node, subscription, and core logs first instead of using TUN to hide a basic connectivity problem.
Check permissions, ports, and routing before enabling TUN
Before switching modes, verify the node through the regular system proxy. Choose a working node, confirm that the browser can reach the target site, and check the client logs for a successful connection. This separates “the node is unavailable” from “the TUN configuration is wrong,” avoiding repeated trial and error across the virtual adapter, DNS, and node status.
The baseline versions used here are v2rayN 7.15.4, v2rayNG 1.10.13, and the Xray core. Menu labels may vary slightly between patch versions, but the order remains the same: confirm the core starts, check virtual adapter permissions, then verify routing and DNS. If an older version lacks the relevant switch, upgrade through the client's built-in update entry first.
There is no need to force a fixed local port, but every listener must be unique. This guide uses 10808 for SOCKS and 10809 for HTTP. If the log shows “address already in use” or “port already in use,” close the program holding the port, or choose an unused port under “Settings” → “Parameters” and restart the core.
Windows test baseline
- Client
- v2rayN 7.15.4
- Local SOCKS
- 127.0.0.1:10808
- Local HTTP
- 127.0.0.1:10809
- Routing policy
- Bypass LAN and local addresses
Ports can be changed, but every listening endpoint must remain unique.
Android test baseline
- Client
- v2rayNG 1.10.13
- Running mode
- VPN
- Per-app proxy
- Disabled for initial testing
- Traffic-splitting policy
- Use the default rules first
Verify full-device capture first, then narrow it to selected apps for more direct troubleshooting.
Enable TUN in v2rayN on Windows
TUN on Windows creates a virtual network adapter and writes routes, so fully exit any running v2rayN instance first, then use the system menu to choose “Run as administrator.” Repeatedly toggling the switch without elevated permissions can leave the core running while route installation fails, the virtual adapter is not created, or TUN stops immediately after a restart.
- Verify the regular proxy. Start v2rayN, update the subscription, and select a confirmed working node. Use system proxy mode for one web access test, while checking the log for connection timeouts, certificate time errors, or failed node-address resolution.
- Check local listeners. Open “Settings” → “Parameters” and make sure the SOCKS and HTTP ports do not conflict with other programs. This guide uses 10808 and 10809; restart the core after changing them so the new listeners take effect.
- Open the TUN settings. Go to “Settings” → “TUN Mode Settings,” enable TUN, and keep defaults such as “Auto Route” and “Strict Route” for the initial test baseline. If your version places the entry in the main-window toolbar, use the TUN switch shown in the current interface.
- Start TUN. Make sure v2rayN has administrator privileges, then enable TUN mode. The first launch may trigger a system network-permission prompt. Allow it and wait for the virtual adapter to initialize; do not toggle the switch repeatedly during this process.
- Check the logs. Open the live log and confirm there are no device-creation failures, port conflicts, or route-addition errors. Then test a web page, a command-line download tool, and the app that previously ignored the system proxy.
Test sequence
1. Confirm the target site works through the regular system proxy
2. Start v2rayN with administrator privileges
3. Enable TUN and automatic routing
4. Check the core log for errors
5. Test TCP, DNS, and the target app
6. Enable custom traffic-splitting rules lastAfter enabling TUN, avoid letting other networking tools modify the default route or create another global virtual adapter at the same time. The two programs may compete for the lowest-metric route, causing intermittent connectivity, some sites to bypass the proxy, or domain resolution to fail after sleep and wake. If an enterprise network-access tool must run alongside TUN, first identify the subnets it must handle, then preserve direct routing for those private subnets in the V2Ray routing rules.
To verify that traffic capture works, do not rely only on the taskbar icon. A more reliable test is to disable the system proxy while keeping TUN enabled, then test an app that previously ignored the proxy. If it connects and the v2rayN log shows the corresponding destination address, the traffic has entered TUN. After testing, decide whether to keep the system proxy enabled as well.
Capture app traffic with v2rayNG on Android
v2rayNG uses the VPN interface provided by the system to establish a virtual network tunnel, producing an effect close to desktop TUN mode: app traffic enters the client first, then the Xray core handles routing and outbound connections. On first launch, the system displays a connection-authorization prompt. Traffic capture takes effect only after authorization is granted and the network-tunnel indicator appears in the status bar.
- Import and test a node. Update the subscription in v2rayNG, select a configuration, and run a latency test first. A latency value only shows that the probe received a response; start the connection and open a web page to confirm that the node can actually transfer data.
- Choose the running mode. Go to “Settings” → “Mode” and select VPN mode. If your version establishes the system tunnel directly through the main-screen start button, keep that default behavior instead of switching to a mode that only exposes local proxy ports.
- Disable per-app proxy for the initial test. Go to “Settings” → “Per-app proxy” and leave it disabled so all ordinary apps follow one unified test path. Once the overall connection is stable, enable the feature and select the apps that should use or bypass the proxy.
- Start the connection. Return to the main screen, tap Start, and accept the system network-connection authorization. Wait for the connection status to stabilize, then test a browser, an app that requires UDP, and a background update task.
- Check battery restrictions. If the connection drops frequently after the screen locks, allow v2rayNG to run in the background in system app management and check whether battery optimization stops its network service. The exact location varies by device, but it is usually under “Settings” → “Apps” → “v2rayNG” → “Battery.”
| Per-app proxy settings | Traffic result | Best for |
|---|---|---|
| Off | All ordinary apps use the virtual network | Initial verification and finding missed traffic |
| Proxy selected apps only | Only checked apps use the proxy path | A specific target and a smaller capture scope |
| Bypass selected apps | Checked apps connect directly; all others follow the rules | Local services or specific apps that must connect directly |
v2rayNG VPN mode and node protocols are different concepts. VMess and VLESS describe how the client establishes a proxy connection with a remote node; VPN mode describes how local app traffic enters the client. Switching between VMess and VLESS nodes does not automatically change the per-app proxy scope, and changing the per-app list does not rewrite the server address, port, or transport parameters in the subscription.
DNS, traffic routing, and LAN access
When TUN captures a connection successfully but web pages still report that the domain cannot be resolved, the problem is usually in the DNS path. DNS lookups may be initiated by the system or sent directly by an app. If DNS requests bypass the virtual adapter, are handled by another encrypted-DNS setting, or are routed to an unreachable server, an IP address may work while the domain does not.
During troubleshooting, visit a known IP-based service first to distinguish resolution failure from connection failure, then check the core log for requests to port 53. Do not change system DNS, client DNS, browser secure DNS, and routing rules at the same time. Change one thing at a time, restart the core, and test again so you can tell which layer took effect.
- LAN addresses: Keep 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 on direct routes so printers, router admin pages, and LAN storage are not sent to a remote node.
- Loopback addresses: Keep 127.0.0.0/8 local so the client's local listener is not sent back into TUN, creating a recursive connection.
- Domain rules: GeoSite matches domain sets and is useful for choosing an outbound path before resolution. Put custom full-domain rules before broad category rules.
- IP rules: GeoIP participates in routing after the destination IP is known and can match regional addresses and private subnets, but it cannot replace rules applied at the domain stage.
- Rule order: Most routing configurations use the first match from top to bottom. Place precise rules first and broad fallback rules last.
For example, if 192.168.1.1 becomes unreachable after enabling TUN, first confirm that a direct rule exists for the subnet, then check whether strict routing is blocking traffic not covered by the rules. If the device is connected to both a company network and a home network, also check whether they use the same private subnet. When subnets overlap, domain rules alone cannot determine which adapter should handle the traffic.
Bottom line: TUN provides the entry point; routing chooses the exit
When some apps work but some sites fail, start with the matched rule and DNS destination instead of forcing all traffic through the proxy. Keeping LAN and loopback traffic direct, then using precise domain rules for exceptions, is usually more stable than relying on one global outbound path.
Common conflicts and targeted fixes
Handle TUN failures in four layers: permissions and devices, routing, DNS, and the node. Check explicit errors in the log first instead of repeatedly reinstalling the client. Device-creation failures usually involve permissions or virtual-adapter conflicts; if requests appear in the log but time out, the node, protocol parameters, or remote network is more likely at fault.
Did the entire computer lose network access after enabling TUN?
Disable TUN first and confirm that regular networking recovers, then restart v2rayN as administrator. Go to “Settings” → “TUN Mode Settings,” keep automatic routing enabled, temporarily stop other programs that create virtual adapters, and test again.
Does the log say that a port is already in use?
Exit duplicate v2rayN processes and check whether another program is listening on local ports such as 10808 and 10809. Then change the ports under “Settings” → “Parameters,” save, and restart the core.
Do web pages open while games or voice calls still fail?
Confirm that the node supports the required UDP traffic and check whether the routing rules are sending the relevant ports to a blocked outbound. Retest with the default route first, then restore custom rules one by one to identify the rule causing the problem.
Does v2rayNG disconnect automatically a few minutes after the screen locks?
Go to system “Settings” → “Apps” → “v2rayNG” → “Battery,” allow background activity, and remove restrictions that stop network services. Also check whether the client is configured to reconnect automatically when the network changes.
Is TUN enabled but LAN devices unreachable?
Add the target device's private subnet to the direct route and confirm that the rule appears before the proxy fallback rule. If multiple networks are connected, check the metrics and outbound adapters for duplicate subnets in the system routing table.
If the issue starts after sleep or a network change, stop TUN first, wait for the virtual adapter state to be released, and start it again. When Wi-Fi switches to Ethernet or a home network switches to a mobile hotspot, the default gateway and interface number change. If automatic routing is not rebuilt promptly, an old route may still point to an interface that no longer exists.
If the issue persists, run a minimal test: keep one node, the default route, and default DNS; disable per-app proxy and extra rules; and enable only TUN. Once the minimal setup works, restore one setting at a time. This identifies whether the fault comes from the node configuration, DNS, custom routing, or another network program.
When to use TUN and when to keep the system proxy
TUN is suitable for unified traffic capture, UDP handling, or apps that ignore the system proxy, but it adds three components to maintain: a virtual adapter, routes, and DNS. If you only proxy browsers and standard desktop software, a system proxy is simpler and easier to troubleshoot through local ports and app settings.
- Browsers and office software follow the system proxy: prefer the system proxy.
- Command-line tools, games, or standalone apps bypass the system proxy: use TUN.
- Need unified routing by domain, IP, and port: use TUN and keep LAN traffic direct.
- An enterprise virtual adapter must stay active: plan subnets and route priorities first, then decide whether to run TUN alongside it.
- Temporary troubleshooting: switch back to the system proxy to verify the node, then restore TUN, DNS, and custom rules step by step.
The correct order is to verify the node, create the virtual adapter, confirm the logs and DNS, and only then add traffic-splitting rules. By checking the capture entry point, rule matching, and proxy outbound separately, most TUN failures can be traced to one specific layer instead of remaining a vague “connected but unreachable” problem.