v2rayN TUN Mode: How It Works and How to Enable It for Full-Traffic Routing

How TUN Mode Differs from System Proxy Coverage

A system proxy essentially registers an HTTP or SOCKS proxy address with the operating system, such as v2rayN’s commonly used local mixed port 127.0.0.1:10808. Browsers and desktop applications that follow system proxy settings send requests to this port, but applications that create connections themselves, force direct connections, or ignore system proxy settings may bypass it. Enabling a system proxy therefore does not mean every process sends its network traffic through the Xray core.

TUN mode creates a virtual layer-3 network adapter and uses system routes to send target traffic to it. The client reads IP packets, reconstructs the connection details, and then lets routing rules determine whether the traffic should use a proxy, go direct, or be blocked. Applications usually do not need a separate proxy address, so games, command-line tools, and software using custom network stacks are more likely to be captured consistently.

The Two Modes Are Not Simply a Matter of Strength

• System proxy: Limited system-wide changes, easy to enable and disable, and well suited to browsers, office software, and applications with explicit proxy support.
• TUN mode: Broader coverage, but it requires a virtual network adapter, route changes, and elevated permissions. It suits applications that cannot configure a proxy separately or need centralized routing.
• Full traffic: Traffic first enters the TUN capture path; this does not mean every destination must use a remote proxy. The final outbound is still determined by routing rules.
• Local loopback: 127.0.0.0/8, LAN addresses, and the client’s own connections must be excluded correctly to prevent proxy loops.

To decide whether TUN is necessary, disable the system proxy first and test the target application. If the application is completely unaffected by the system proxy switch but its traffic must follow centralized rules, TUN is the better choice. If you only use a browser day to day, there is no need to add a virtual adapter and routing layer just because the setting says “full traffic.”

Check the Version, Node, and Ports Before Enabling TUN

Start troubleshooting with node availability rather than repeatedly toggling TUN. In ordinary system-proxy mode, select a node, open a reachable test page, and confirm that the v2rayN core log shows no authentication failures, TLS handshake failures, or connection timeouts. If the node itself is unavailable, TUN will only broaden the scope of the failure.

The values below provide a baseline for checking a v2rayN 7.15.x desktop environment. Menu names and automatically generated subnets may vary between minor releases, but the methods for checking port usage, default routes, and DNS capture remain the same.

1. Double-click a verified working VMess or VLESS node in the server list to make it the active server.
2. Go to “Settings” → “Parameter Settings” and confirm that the local listening port is not already used by another proxy application. If the log reports address already in use, close the process occupying the port or change the local port to an unused value.
3. Synchronize the system date, time, and time zone. TLS and Reality connections rely on a reasonable system clock, and a significant discrepancy can cause the handshake to fail.
4. Record the current network state, including the active adapter, default gateway, and DNS addresses. If the client exits unexpectedly, this helps identify whether leftover routes, DNS settings, or a virtual adapter are responsible.
5. Temporarily close other networking tools that create virtual adapters or modify the default route, so competing capture rules do not fight over priority.

Key Parameters in v2rayN TUN Settings

In v2rayN 7.x, open the TUN settings through “Settings” → “Parameter Settings,” save the changes, then enable “TUN mode” from the main window. Some versions place the switch at the top of the main window or in the tray menu, but the result is the same: start a core with TUN inbound support, create a virtual adapter, and write the required routes.

Avoid changing too many parameters at once. For the first test, keep automatic routing and automatic interface detection enabled, and adjust only settings that clearly conflict with your network. Once the basic path works, tune MTU, strict routing, and DNS policies to identify the cause of any connection problems more quickly.

Post-Enablement Checks

1. Save the settings and return to the main window, keeping a working node selected.
2. Enable TUN mode, approve the system permission request, and wait for the status bar to show that the core is running normally.
3. Check the core log. It should show that the TUN interface was created and routes were added; repeated permission denied or route add failed messages indicate a problem.
4. Turn off manual proxy settings in the browser, then visit a test destination to confirm that requests still connect according to the rules.
5. Test one domain explicitly set to direct and another explicitly set to proxy, confirming that TUN capture and routing are both working.

Permission Differences on Windows, macOS, and Linux

TUN needs to manage network interfaces and system routes, so ordinary user permissions are often insufficient. The goal is the same on all three desktop platforms, but the authorization process differs. Typical signs of insufficient permissions include the switch turning itself off, no virtual adapter appearing, or an error during interface creation in the log.

Recommended Windows Sequence

1. Fully exit any older v2rayN process before starting the current version, preventing two cores from listening on 10808 at the same time.
2. Connect to a node and test the system proxy first, then enable TUN and complete the authorization when prompted.
3. If the virtual interface exists but carries no traffic, open the system routing information and check whether a higher-priority default route still points to the physical gateway.
4. After disabling TUN, confirm that the virtual interface and temporary routes have been removed before deciding whether to reinstall or reset the related driver.

Additional Checks for macOS and Linux

• When macOS has multiple network services, confirm whether wireless or wired networking is actually providing the Internet connection. Automatic interface detection must match the real exit path.
• On Linux desktops, DNS may be managed by NetworkManager or systemd-resolved. If TUN has captured the routes but domains fail, check the resolution path separately.
• After sleep, a network change, or switching from wired to wireless, the previous default interface may no longer work. Disable and re-enable TUN so the client can detect the exit interface again.
• Containers and virtual machines often use separate private subnets. If one overlaps with the TUN address range, change the TUN subnet first instead of adding more default routes.

What Happens to the Routing Table After TUN Is Enabled

Replacing the original gateway with a single new default route can send the proxy core itself back into TUN and create a loop. In practice, implementations usually keep the physical exit and split the IPv4 default space into two more-specific routes, such as 0.0.0.0/1 and 128.0.0.0/1. Because their prefixes are longer, these routes take priority over the original 0.0.0.0/0; ordinary application traffic enters TUN, while the core’s connection to the remote server uses the real gateway through exclusion rules.

The simplified output below illustrates the structure; individual devices may use different interface names and gateways. The key signs are that the original default gateway remains present and that more-specific capture routes point to TUN.

Destination network          Gateway or interface
0.0.0.0/0         192.168.1.1
0.0.0.0/1         tun0
128.0.0.0/1       tun0
192.168.1.0/24    Local physical adapter
127.0.0.0/8       Local loopback

DNS must also follow the routing direction. If a domain is resolved by the local network first but the connection later exits through a proxy, the result may not suit that exit. Conversely, sending all DNS through the proxy can prevent local hostnames from resolving. A safer approach is to use remote resolution for proxied domains and local resolution for LAN and explicitly direct domains, while ensuring that DNS queries themselves do not bypass the chosen outbound path.

How TUN Works with Xray Routing Rules

TUN answers “how traffic enters the client,” while Xray routing answers “which outbound it uses to leave.” Treating TUN as a full-proxy switch overlooks the role of routing rules. At minimum, a daily configuration should distinguish proxy, direct, and block outcomes, with high-priority special rules placed before general rules.

For example, LAN addresses and device administration pages should be sent direct first. Domains that require a proxy should then be directed to the proxy outbound. Advertising or explicitly unwanted domains can use a block outbound. All remaining traffic is handled by the default policy. Rules are matched in order, and a connection that matches an earlier rule does not continue to later rules.

Recommended Rule Priority

1. The client itself and node addresses: These must connect through the real physical exit so the core’s connection does not re-enter TUN.
2. Loopback and LAN: 127.0.0.0/8, common private address ranges, and local device domains are normally set to direct.
3. Block rules: Use the block outbound for domains or protocols that should explicitly be denied, reducing pointless connections.
4. Proxy rules: Match by domain set, destination address, port, or protocol, and send traffic to the active proxy outbound.
5. Default rule: Decide whether unmatched traffic uses direct or proxy as the final fallback, preventing connections with no outbound result.

After changing rules, test both domain-based requests and direct IP requests. If only domains fail, check DNS and domain rules first. If both domains and IPs fail, check the node, routing table, and permissions. If only one LAN device is unreachable, check whether its private address range was mistakenly sent to the proxy outbound.

Common Failures and Step-by-Step Recovery

Handle TUN failures in this order: permissions and interfaces, routes, DNS, MTU, then routing rules. Change one thing at a time and reconnect after each adjustment. If you change the node, DNS, MTU, and rule order simultaneously, even a successful recovery will not reveal the real cause.

Minimal Troubleshooting Checklist

• Has the node been verified as working in system-proxy mode?
• Was the TUN virtual interface created successfully, and does the log show any permission errors?
• Is the original physical default gateway still present, and does the capture route point to the correct interface?
• Do direct IP access and domain-based access produce different results?
• Are LAN addresses, loopback addresses, and the node server address correctly excluded?
• After setting the MTU to 1500, do large file transfers and sign-in requests work again?
• After disabling TUN and exiting the client, were the temporary routes and DNS settings removed?

Once the basic path is stable, gradually enable strict routing, refine DNS rules, or add routing conditions. For environments that only need browser proxying, a system proxy is usually easier to maintain. For multiple desktop applications that ignore proxy settings, TUN combined with clear direct, proxy, and block rules provides controlled full-traffic capture.