If your browser connects but desktop apps do not, first check whether those apps use the system proxy before trying TUN. This guide focuses on v2rayN for Windows, covering permissions, virtual adapter routing, DNS, verification, and rollback. macOS uses different authorization and network extension mechanisms, so use the options supported by its platform build rather than following Windows administrator steps.
System Proxy vs. TUN: Where Traffic Is Captured
A system proxy gives apps a local proxy endpoint. Browsers and desktop apps that read the system proxy settings send requests through it, while apps that create their own connections or use separate network settings may connect directly. So having a system proxy configured does not mean every app on your computer is using it.
TUN creates a layer 3 virtual network interface in the operating system and uses routing rules to pass eligible IP packets to a traffic-processing engine. Apps do not need built-in HTTP or SOCKS proxy support for their traffic to be captured. Here, “all traffic” describes the capture scope; it does not mean every connection must go to a remote node. Routing rules still decide whether traffic goes direct, through a proxy, or is blocked.
v2rayN is the management interface; proxy connections and TUN traffic processing depend on the core that is actually running and its configuration. Different builds may use different supporting components, so the node type shown in the interface alone does not identify the TUN backend. VLESS and VMess are proxy protocols; TUN is a traffic entry point. They are not alternatives, and enabling TUN does not require changing every node in your subscription to another protocol.
Before You Start: Check Your Node, Ports, and Permissions
First, verify that your node works with TUN off. If a regular proxy connection already fails, TUN will only widen the scope of the problem; it cannot fix a broken subscription, an incorrect server address, or mismatched security settings. Save screenshots of your current routing and DNS settings, and note the local listening address so you can restore them and continue testing if needed.
- Check the node: Select an imported node as the active server and verify it by visiting a website in your browser. A successful latency check alone does not prove that web access, DNS, and UDP all work.
- Check the listening port: Look for the local listening port under Settings → Parameters. The exact section may vary by version. Do not confuse the local proxy port with the server port, and do not change the listening address to all network interfaces just to use TUN.
- Prepare permissions: On Windows, elevated permissions are usually required to create a virtual network adapter and change routes. Exit v2rayN normally, then right-click the program, select “Run as administrator,” and approve the system prompt.
- Avoid conflicts: For your first test, pause other tunnels or acceleration tools that change the default route. If your work device is managed by network policies, get authorization first; do not try to bypass endpoint protection.
There is no single local port that everyone must use. The 10808 above is only an example; if your configuration uses another port, use that value in commands, app proxy settings, and log checks. You generally do not need to open an inbound router port for local TUN capture.
Enable TUN in v2rayN: Follow These Steps in Order
Depending on the version, the toggle may be labeled “Enable TUN” or “TUN mode,” and settings may be grouped differently. The steps below describe the relevant features: look for the TUN toggle in the main window and TUN options under Settings rather than relying on a particular version’s button location.
- Keep a working proxy baseline. Turn TUN off and visit a site using the active node. If it fails, fix the node or subscription before proceeding.
- Restart with the required permissions. On Windows, run the program as administrator and make sure an older instance is not still using the local port in the background. Elevate only one instance; do not run two copies at once.
- Review the TUN settings. Open Settings and go to the TUN options available in your version. For your first setup, keep the default network stack, MTU, and interface parameters. Check that automatic routing options match your capture goals, and avoid changing several advanced settings at once.
- Choose a routing policy. Select a rules mode that fits your needs and keep the necessary LAN bypass rules. If you need access to printers, network storage, or a corporate intranet, check the relevant subnets and domains carefully.
- Turn on TUN in the main window. Check the core logs for permission errors, configuration parsing failures, or port conflicts. Then check whether the corresponding virtual interface and routes appear in the system.
- Test TUN on its own. Once TUN is running, set v2rayN’s system proxy to clear or off, then test an app that does not normally follow system proxy settings. This helps distinguish a working regular proxy from a working TUN connection.
If the network drops as soon as TUN is enabled, turn TUN off first. Do not keep switching nodes, network stacks, and DNS modes. Restore your baseline and check the first error before making another change. A visible virtual adapter only proves that the interface was created; it does not prove the processing engine is still running.
DNS and Routing: Check Both Capture and Resolution Paths
When an app connects to a domain, it usually resolves the name through DNS before connecting to the target IP. Capturing connections with TUN does not automatically ensure that all DNS lookups take the same path. Traditional DNS commonly uses UDP or TCP port 53, while an app’s encrypted DNS may use HTTPS. Handling port 53 traffic alone does not prove that a browser’s DNS path has changed.
DNS Checks
- System resolution
- Check the current network adapter’s DNS source and the client’s DNS capture settings
- Upstream reachability
- Check whether the DNS server depends on a proxy connection that is not yet available
- App-level resolution
- Check the browser’s Secure DNS separately; do not assume it follows system settings
- Cache effects
- Retry with a new connection after changes and clear the system cache if needed
Do not change system DNS, browser DNS, and client DNS all at once. Change one setting at a time and verify the result.
Routing Checks
- LAN
- Keep direct routes for the actual subnet, such as 192.168.1.0/24
- Remote connections
- Prevent outbound connections to the node server from looping back into TUN
- IPv6
- Check the capture and routing scope; do not test IPv4 alone
- Rule priority
- Check whether an earlier rule matches the target connection first
The subnet shown is only an example, not a universal setting. If your LAN uses different addresses, follow your actual routes and network plan.
When a remote node uses a domain name, avoid DNS resolution loops. If the DNS server is reachable only through a proxy, but the proxy needs the node domain resolved before it can connect, startup may stall. Use a sensible default supported by the client so it can resolve the domains needed to start, rather than forcing every DNS request through the same outbound route.
Some configurations use FakeDNS or fake-ip mechanisms to temporarily map domain names to synthetic addresses, which the processing engine later resolves back to their targets. Other tools may not be able to access these addresses directly, and old DNS cache entries can cause temporary issues after a mode change. Do not enable this option just because a guide mentions it; first confirm that your core supports it and that it fits your configuration.
- Domain won’t resolve: Check DNS requests, upstream reachability, and cache before changing nodes.
- Domain resolves but the connection times out: Check route matches, node outbound traffic, and support for the target protocol.
- Only LAN names fail: Check internal DNS, search domains, and LAN bypass rules.
- Only some apps have issues: Check each app’s proxy, encrypted DNS, and network adapter binding settings.
After Enabling TUN: Verify More Than the Toggle
Verification comes down to three questions: Does the regular proxy work? Is TUN capturing connections from the target app? Are those connections using the expected outbound route? Test the target app with the system proxy off, then check the logs. If a rule specifies a direct connection, an unchanged public IP may be perfectly normal.
| Check | How to test | What to look for |
|---|---|---|
| Regular proxy baseline | Turn TUN off and access the same destination through an explicitly configured local proxy | Rule out node, listening port, and remote connection issues first |
| TUN capture on its own | Turn TUN on, turn the system proxy off, and access the same destination | Check the logs for the destination connection and expected outbound route |
| LAN access | Visit a known working router management address or internal service | Make sure a broad rule does not override LAN direct-connect rules |
| DNS and dual stack | Check DNS results and test IPv4 and IPv6 connections separately | Do not assume everything works after testing only one address family |
| UDP apps | Test a feature that actually uses UDP | A successful TCP website test does not prove that UDP traffic works |
On Windows, use the commands below to check routes and DNS results. The proxy test requires a SOCKS service listening on local port 10808; if your port or protocol differs, adjust the command to match your current settings. The example destination only illustrates command syntax—a single test cannot provide a complete network diagnosis.
route print
ipconfig /all
nslookup example.com
curl.exe --proxy socks5h://127.0.0.1:10808 https://example.com/
curl.exe --noproxy "*" https://example.com/The second curl request bypasses application-level proxy settings, not system routing, so it may still pass through TUN. To test the physical network directly, turn TUN off first. Before sharing logs, remove subscription URLs, account identifiers, and node credentials. Troubleshooting usually requires the error type, destination connection, and matched rule—not your full configuration.
Common Issues and How to Restore Your Connection
TUN turns off as soon as I enable it. What should I check first?
Start with the first error in the startup log. On Windows, exit any old instance and run the program as administrator. If it still fails, determine whether the cause is a permission denial, virtual interface creation failure, or configuration parsing error. Do not leave system protection disabled as a substitute for troubleshooting.
My browser works, but games or voice chat still won’t connect. Why?
First confirm that the target connection enters TUN and matches the expected rule. Then check whether the node and server support the required UDP forwarding. Websites mainly test TCP; they do not prove that the UDP path used by voice chat or games is working. The app launcher and the actual process may also connect to different destinations.
My printer and internal services disappeared after enabling TUN. What should I check?
Turn TUN off first to confirm the services were reachable before. Then check your actual local subnet, internal DNS, and direct-connect rules. Some services rely on broadcast or multicast, which cannot be fixed by adding a broad public proxy rule. If needed, exclude the relevant interface or subnet using a method supported by the client.
I still can’t connect to the internet after turning TUN off. What should I do?
First clear any system proxy pointing to a stopped local port, then exit the client normally. Check whether system DNS and routes have been restored. On Windows, after changing DNS, run ipconfig /flushdns to clear the cache. If the problem persists, try reconnecting to the network or restarting the system; do not delete all virtual network adapters.
For reliable everyday use, keep a record of settings you have verified rather than frequently switching network stacks. Note the active node, routing mode, DNS setup, system proxy status, and any other tunnel software. If something goes wrong, restore settings one at a time using that record; this is usually easier to troubleshoot than resetting everything at once.
- Pause temporarily: Turn off TUN and confirm its virtual routes have been removed before deciding whether to enable the regular system proxy.
- Exit completely: Clear the system proxy if you no longer need it, then exit v2rayN so apps do not keep connecting to a stopped local port.
- Continue troubleshooting: Save a redacted error log, change one setting at a time, and retest against the same destination.