v2rayN TUN Mode Setup: Route All Traffic Through a Virtual Adapter

1. TUN Virtual Adapters vs. System Proxy

A system proxy gives apps a proxy endpoint. Browsers and other apps that respect system settings send requests to a local proxy port. Apps that make connections on their own or ignore those settings may connect directly. So if a browser works but a command-line tool doesn't, the node may be fine—the two apps may simply be using different network paths.

TUN creates a virtual interface at the system network layer and uses routing rules to pass matching IP packets to the proxy core. Apps usually don't need a proxy address configured individually. “Full traffic capture” describes which traffic enters TUN; it doesn't mean every connection must go through a remote node. Connections entering TUN can still be routed directly, proxied, or blocked according to your rules.

v2rayN handles the interface, configuration generation, and process management; the core handles traffic forwarding. Common desktop releases use sing-box for TUN, though the exact combination depends on the version and configuration. Enabling TUN does not automatically enable every Xray feature. VMess and VLESS are node protocols; REALITY is a secure transport. None of them is a virtual network adapter driver, and switching to TUN doesn't require you to generate a new subscription.

2. Before You Start: Check Your Node, Permissions, and Local Proxy

Turn off TUN and use the system proxy to verify that a node can open an HTTPS site. Adding a virtual adapter only adds more variables if the node itself isn't working. For help importing a subscription, see the subscription setup guide. If the connection fails, start with the log-reading tips in Troubleshooting.

1. Note your current settings: Record the active node, routing mode, local listening ports, and custom DNS settings. Keep subscription URLs and node credentials on your own device; don't post them publicly.
2. Disconnect other network-routing tools: Temporarily turn off other VPN connections and tools that modify the default route. If your organization requires remote access, check whether network changes are allowed first.
3. Check permissions: On Windows, exit v2rayN completely, right-click the app, select “Run as administrator,” and approve the prompt. Closing the window may only minimize the app to the tray; use the tray menu to exit.
4. Check the app files: If the log reports a missing TUN-related core or driver file, use a complete release package for your system architecture. Don't download individual DLLs from untrusted sources.

These three numbers distinguish the local proxy endpoint, DNS lookups, and website connections. They are not firewall ports that all need to be opened. In particular, don't change the local listening address from 127.0.0.1 to 0.0.0.0 just to troubleshoot. TUN captures apps on this device; it doesn't require exposing the proxy endpoint to your LAN.

3. How to Enable TUN in v2rayN

Menu locations vary between desktop versions. In many builds, look under “Settings” → “Parameter Settings” for “TUN Mode Settings”; the main window may also have an “Enable TUN” switch. Follow the feature names rather than a specific screenshot. If you can't find the option, check your version and platform instead of changing unfamiliar fields based on instructions for another release.

1. Select a verified node. Confirm the active node is correct and that a website loads through the system proxy.
2. Use one network path at a time. Set the system proxy to “Clear system proxy” while leaving the client core running. A brief loss of access to proxied destinations is expected; TUN will take over in the next step.
3. Keep the default TUN settings. When enabling TUN for the first time, don't change the stack, MTU, interface name, and DNS policy all at once. Start with the defaults for your version to establish a repeatable baseline.
4. Turn on “Enable TUN.” Check the logs for interface creation, core startup, or route initialization. An enabled switch only reflects the UI state; test an actual connection to verify TUN is working.
5. Check for the virtual interface. In Windows, open “Settings” → “Network & Internet” → “Advanced network settings” to view network adapters. You can also use the read-only commands below.
6. Test before making changes. Confirm websites and the target app can connect, then restore custom routing settings one at a time. Test after each change to avoid altering multiple variables at once.

Get-NetAdapter | Select-Object Name, InterfaceDescription, Status
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Select-Object -First 20 DestinationPrefix, InterfaceAlias, NextHop, RouteMetric

Run the commands above in PowerShell; they only read adapter and route information. Interface names vary by core, and traffic capture may use multiple, more-specific route prefixes. Don't judge success only by whether a 0.0.0.0/0 route appears. Check the interface status, startup logs, and actual connection logs together.

4. Configure Routing and DNS Together

Keep sensible traffic rules after enabling TUN. LAN devices, corporate network resources, and connections to the node server itself need the right route. Sending every address back through the proxy endpoint can create a routing loop. Common versions handle interface selection or bypassing for proxy outbound traffic, but custom configurations, multiple virtual adapters, and complex policy routing can still disrupt this behavior.

A common DNS pitfall is a dependency loop: the node hostname must be resolved before connecting, but the DNS request is configured to go through that same node. Give the node hostname a working initial resolution path instead of repeatedly switching public DNS servers. With encrypted DNS, also consider how the DNS server's own hostname gets resolved initially.

• LAN example: If your printer is at 192.168.1.50, make sure its subnet, 192.168.1.0/24, uses your local network. Adding only the printer's name won't help if its DNS result is routed incorrectly.
• App-specific DNS: A browser's secure DNS may use separate HTTPS requests, so don't assume that capturing DNS traffic on port 53 covers it. Note the browser's DNS settings while troubleshooting; if needed, temporarily let the system handle resolution.
• IPv6 example: If a hostname returns an AAAA record but your network has no usable IPv6 route, the connection may stall before falling back. Check IPv6 connectivity first, then adjust the client’s IPv6 policy. Changing only the system adapter settings may not fix it.

5. Verify TUN Is Working—Don't Just Check the Switch

Test both traffic capture and correct routing. First, clear the system proxy and make sure the target app has no proxy configured manually. Then visit a known-working site. Otherwise, a successful browser test may simply use the old proxy endpoint and won't prove that TUN is capturing traffic.

1. Test HTTPS: Open an accessible HTTPS site and check whether the corresponding connection appears in the client logs. Browser cache can hide a connection failure; if needed, load a page you haven't visited before.
2. Test the target app: Open an app that doesn't normally use the system proxy, then check its connection and the client logs. Don't assume the host's TUN will capture traffic from a virtual machine or container with its own network.
3. Test routing rules: Visit a LAN address that should go direct and a domain that should use the proxy, then compare the matched rules and outbound routes in the logs. A public IP lookup shows only the route used for that request, not the route used by every app.
4. Test UDP: Check UDP only if the target app needs it. A working TCP connection to a website doesn't prove UDP works; server policies or node transport capabilities may limit it.

curl.exe --noproxy "*" -I --connect-timeout 10 https://example.com/

Don't treat one latency test as a speed verdict. Latency shown in a node list usually reflects a specific probe, not video throughput or game round-trip time. For a useful comparison, keep the node, network, and destination the same, and switch only between system proxy and TUN to isolate the difference.

6. Common Questions: No Internet After Enabling TUN

7. When to Use TUN and How to Exit Safely

If only your browser needs a proxy, the system proxy is usually enough and requires less setup. Consider TUN when several desktop apps ignore system settings, you need consistent traffic routing, or an app requires UDP. TUN expands which traffic is captured; it won't increase node bandwidth or fix an unreachable server, expired subscription, or incorrect protocol settings.

• Normal exit: Turn off TUN first and wait for the core to remove its routes, then exit v2rayN from the tray. If you still need a system proxy, enable the relevant mode again.
• After an unexpected exit: Restart the client and toggle TUN on and off once so it can clean up. Also check “Settings” → “Network & Internet” → “Proxy” in Windows for any leftover manual proxy settings.
• If your network still hasn't recovered: Keep the logs and restart Windows, then check your physical network connection. Don't copy bulk route-deletion commands from the web; they could remove routes needed for your company network or other connections.
• After setup: Record the working node, routing mode, DNS policy, and test results. If an update or network change causes problems later, compare against this baseline one setting at a time.

The success criteria are simple: with the system proxy cleared, the target app still connects as expected, destinations meant to go direct stay direct, and your system network works normally after exit. Once all three are true, add custom rules gradually; they're easier to maintain than a complex setup from the start.