TUN Mode Traffic Capture: How v2rayN and v2rayNG Work

What Happens When TUN Captures Traffic

TUN is a virtual interface that operates at the network layer. Once enabled, the system sends IP packets matching the routing criteria to the virtual adapter. The client reads them, reconstructs the destination address and protocol, then uses routing rules to choose a direct connection, proxy, or block action. To an app, the request still goes to its original domain and port; it does not need to know about a local SOCKS or HTTP proxy port.

System proxies operate closer to the application layer. Browsers and other software that respect system proxy settings actively send requests to a local proxy port, but some command-line tools, game components, updaters, and apps with their own network stacks may ignore those settings. TUN does not require cooperation from the app, so it can cover more traffic types and handle UDP requests that need a proxy.

“Global capture” means traffic enters the client’s decision process; it does not mean every connection must pass through a remote server. The client can still route traffic by domain, destination IP, private network range, and protocol. For example, a home router can connect directly, sites matching proxy rules can use a server, and DNS requests can follow a designated resolution policy.

Choosing Between TUN and System Proxy

If you mainly use browsers and software with explicit proxy support, a system proxy is usually lighter and easier to troubleshoot. As long as the client’s local port is listening and the app respects system settings, the connection should work. Enable TUN when programs that ignore the system proxy also need to enter the routing process.

When troubleshooting, avoid repeatedly switching among the system proxy, TUN, and routing modes. A more reliable approach is to confirm that the server works under the system proxy first, then close other temporary networking tools and enable TUN by itself. If the connection changes, the cause is more likely the virtual adapter, routing, or DNS rather than the server.

Enable TUN Mode in v2rayN

The steps below refer to the Windows interface in v2rayN 7.12.5. Button locations may change between minor releases, but the four stages remain the same: prepare a server, grant virtual-adapter permissions, enable TUN, and check the routing mode. Before you begin, test server latency and web access once in ordinary system proxy mode so an unavailable server is not mistaken for a TUN problem.

1. Choose a working configuration. In the v2rayN main window, select a VMess or VLESS configuration that has already passed a connectivity test and set it as the active server.
2. Check the system proxy status. For the first TUN test, turn off the system proxy to reduce interference from changing two capture methods at once.
3. Enable TUN. Find the “TUN Mode” switch in the main window or tray menu and turn it on. When Windows asks for permission, allow the operation; the client needs to create a virtual interface and add routes.
4. Check the routing method. Go to “Settings” → “Parameter Settings” and review the TUN options and current routing mode. If you need direct access in mainland China and to local networks, choose a configuration with rule-based routing. Do not infer the outbound route from the words “global capture” alone.
5. Verify DNS and access paths. Visit a familiar website first, then test an app that previously ignored the system proxy. Once both work, confirm that the router admin page and LAN devices remain accessible.

Once the setup is stable, restore any automatic-start options you need. If TUN cannot be created after every system restart, check the client’s startup permissions and related service status instead of repeatedly deleting the subscription. A subscription only supplies server and protocol parameters; whether a virtual adapter can be created depends on the local environment.

Enable System-Level Traffic Capture in v2rayNG

On Android, v2rayNG uses the system VPN interface to create a virtual network, serving a role similar to desktop TUN capture. The steps below refer to v2rayNG 1.10.4. On first launch, Android displays a connection authorization dialog. App traffic can enter v2rayNG’s routing and proxy flow only after authorization is granted.

1. Import and select a configuration. After updating the subscription, select a VMess or VLESS server that has passed a connection test.
2. Check VPN settings. Go to “Settings” → “VPN Settings” and make sure apps that need the proxy are not included in the bypass list. For the first test, disable per-app filtering and verify the complete path first.
3. Return to the main screen and start. Tap the start button on the main screen. When the system asks to allow a VPN connection, choose Allow. Begin testing after the VPN status appears in the status bar.
4. Check the routing mode. Choose rule-based routing or global proxy according to your needs. Rule-based routing keeps LAN traffic and specified destinations direct; global proxy sends more captured connections to the proxy outbound.
5. Test domains and IP addresses separately. Open a familiar website to verify domain resolution, then test the target app. If the website works but the app fails, check per-app proxy settings. If the IP is reachable but the domain fails, focus on DNS.

Android background restrictions may pause the client after the screen turns off. If foreground access works but the connection drops after the device is locked for a while, allow v2rayNG to run in the background in the system app settings and check whether the battery policy limits its network activity. This behavior is not directly related to the server protocol.

Why DNS, MTU, and Routing Loops Go Wrong

Once TUN brings more connections under unified handling, the dependencies between DNS and routing become more apparent. A domain must first resolve to an IP address, and the resolution request itself must choose a direct or proxied path. If a DNS request is mistakenly sent back through the same TUN interface before initialization is complete, pages may wait indefinitely while entering an IP address directly still works.

MTU is the maximum size of an individual network-layer packet on the current interface. When the value does not match the underlying link, small pages may work while larger uploads, images, or specific handshakes repeatedly time out. In this situation, record the current value and lower it gradually, changing only one parameter per test. Do not modify the server transport, security settings, and MTU at the same time.

Troubleshooting Checklist for No Internet After Enabling TUN

The key to troubleshooting is identifying which layer failed. First confirm that the virtual interface was created, then check for a default route, verify DNS, and only afterward inspect an individual app or protocol. Record the result after each step to avoid switching back and forth among multiple settings pages.

• Confirm the server works: Disable TUN and complete a web connectivity test using the system proxy.
• Confirm creation permissions: On Windows, check that v2rayN can create a virtual interface; on Android, check that system VPN authorization is still valid.
• Rule out interface conflicts: Temporarily exit software that creates other virtual adapters or modifies the default route, then restart TUN.
• Check private network ranges: When you need to reach a router or LAN service, make sure the current network range uses a direct route.
• Check DNS: When the domain fails but the destination IP is reachable, look for resolution timeouts in the client log.
• Check per-app rules: If only certain apps fail in v2rayNG, verify that they have not been excluded.
• Check the clock: A large device time difference can cause TLS handshakes to fail for VMess or VLESS configurations.

On Windows, use the built-in system commands to inspect interfaces, routes, and DNS. Use commands for observation only; do not batch-delete routes when you are unsure what they mean. Focus on whether a new virtual interface appears, whether the default route points somewhere sensible, and whether domain resolution returns a result.

ipconfig /all
route print
nslookup example.com

If the log reports a connection timeout, distinguish between a timeout connecting to the proxy server and a timeout connecting to the destination through the outbound route. The former is usually related to the server address, network reachability, or a routing loop; the latter may mean the destination service is unreachable. If the same DNS request repeats continuously in the log, fix the resolution path first.

Common Questions and Usage Limits

TUN is best for apps that ignore the system proxy, traffic that requires unified UDP handling, and rule-based routing by destination. It does not improve a server’s bandwidth, latency, or reachability, nor can it fix an incorrect server address, port, authentication detail, or transport parameter.

A stable configuration is not defined by whether the switch lights up. During continued use, DNS resolution, web access, target apps, and LAN connections should all behave as expected. After verification, save the current routing and DNS choices so future problems can be compared against this baseline.