When your browser connects but command-line tools or other apps still use a direct connection, first understand how system proxies differ from TUN. This guide walks through the process on Windows with v2rayN: verify your node, get the required permissions, enable the virtual adapter, check routing and DNS, then test and roll back if needed. The goal is to route the right traffic through the right egress while keeping LAN access available—not to send every connection through the proxy.
System Proxy vs. TUN: Different Entry Points, Routing Still Determines the Egress
A system proxy registers a local proxy address with the operating system. Apps that honor this setting send requests to v2rayN's local listening port; apps that ignore it connect directly. A working browser connection doesn't prove that command-line tools, games, or background services are using the proxy too.
TUN operates at the network layer. The client creates a virtual network interface, and system routes direct matching IP traffic through it. The relevant core then handles TCP, UDP, DNS, and egress selection. Apps generally don't need to be configured with a proxy address, but an existing VPN, apps bound to a specific adapter, or higher-priority routes can still affect which traffic gets captured.
System Proxy: Verify the Basics First
RecommendedThis setup affects fewer components, making it a good first step for confirming that your subscription node, local listener, and browser access all work. It's a troubleshooting starting point, not necessarily the right choice for every situation.
Best for: Primarily browsing, or apps that support HTTP or SOCKS proxies
TUN: Capture Traffic from Apps That Ignore Proxy Settings
A virtual adapter and system routes capture traffic. You'll also need to check permissions, DNS, UDP support, and LAN exceptions—the enabled switch alone doesn't prove it's working.
Best for: Command-line tools, some desktop apps, and setups that need centralized traffic routing
Decision: Choose an Entry Point, Then a Routing Policy
Keep the system proxy if it meets your needs. Enable TUN only if an app is bypassing the proxy. TUN still supports split routing: traffic goes through the proxy only when the corresponding global proxy rule is selected.
Before You Start: Check Your Node, Permissions, and Port Roles
Update your subscription in v2rayN, select a node, and set it as the active server. Use the system proxy to access a site you actually need, confirming that the node can handle real requests—not just establish a connection. A latency test doesn't prove every destination is reachable, and it says nothing about whether UDP works.
The port numbers below illustrate their roles; they don't mean you should change every setting to the same values. Check v2rayN's actual local listener values under Settings → Parameter Settings. The remote port for a subscription node is set by your service provider; don't change it to match the examples.
- Administrator permissions: Creating a virtual adapter and adding routes on Windows usually requires elevated permissions. Exit v2rayN, restart it with Run as administrator, and approve any system permission prompts.
- Required components: Check that the package includes the components needed for TUN. Common v2rayN versions use sing-box for TUN; using Xray for your node doesn't mean Xray itself creates the TUN interface.
- Network conflicts: First disable other VPNs and similar virtual adapter capture features. Don't start by stacking multiple default routes and then guessing which program is receiving traffic.
- Rollback plan: Note your current system proxy status, routing mode, and DNS settings. Change one set of settings at a time during your first test so you can easily restore the previous configuration.
Enable TUN in v2rayN: Follow the Steps and Verify
Enable TUN only after confirming that the regular proxy works. For initial troubleshooting, clear the system proxy so your test app uses TUN as its only entry point. This avoids mistaking an active system proxy for successful virtual adapter capture. This is a troubleshooting technique, not a requirement to keep the two entry points separate permanently.
- Exit and run with elevated permissions: Exit v2rayN from the system tray, then right-click the app and select Run as administrator. Closing the main window alone may leave the background process running.
- Check the active node: Make sure the active server in the server list hasn't changed. To add a subscription again, go to Subscription Group → Subscription Group Settings, save the URL, and update the subscription.
- Check local settings: Go to Settings → Parameter Settings and note the local listening ports. If your version has a TUN settings page, start with the default stack and MTU; don't change multiple experimental settings at once.
- Clear the system proxy: From the main window or system tray, open the System Proxy menu and select Clear System Proxy. Also check that the test app has no separately configured proxy address or proxy environment variables.
- Enable TUN: Turn on Enable TUN in the main window. If your version places this option in Settings, use the TUN control shown there. Check the logs for errors creating the adapter, starting the core, or configuring routes.
- Test a real request: Use an app with no proxy configured to access your target. Check the routes, DNS, and access logs to confirm the egress. Then decide whether to keep the system proxy enabled.
In PowerShell, these two read-only commands show network adapters and IPv4 routes without changing system settings. The virtual interface name isn't necessarily fixed, so compare the output before and after enabling TUN. Some implementations use two more-specific routes instead of replacing the existing default route.
Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-NetRoute -AddressFamily IPv4 |
Sort-Object DestinationPrefix, RouteMetric |
Format-Table DestinationPrefix, InterfaceAlias, NextHop, RouteMetricSeeing a virtual interface is only the first step. If the logs show that the interface is running but app requests aren't entering the expected processing chain, check route priority, whether the app is bound to a physical adapter, and whether a rule is sending the request direct.
Split Routing: Keep LAN Access and Prevent Proxy Loops
“TUN captures all traffic” describes the scope of the entry point; “global proxy” describes the egress policy. With TUN enabled, home storage, printers, and intranet services can still connect directly, while other destinations are routed by domain, IP, or rule set. Forcing every destination through a remote server can make LAN devices unreachable.
Routing Setup: Separate Everyday Use from Quick Diagnostics
Everyday routing
- Route LAN and private addresses directly as needed.
- Match destinations that need a proxy to the proxy egress explicitly.
- Configure DNS separately for direct and proxied traffic.
- Keep the loop-prevention mechanism for connections to the node server.
Quick diagnostics
- Clear the system proxy to isolate the TUN entry point.
- Temporarily assign a proxy rule to the test destination.
- Check the logs for rule matches and egress.
- Restore your everyday routing configuration when testing is complete.
First confirm that a specific destination uses the proxy, then expand the rules. One egress lookup doesn't verify every app.
| Destination or address | Routing approach | Reason |
|---|---|---|
192.168.0.0/16 | Route directly if your LAN requires it | Common examples include home routers, printers, and storage devices. |
10.0.0.0/8 | Check your corporate network or VPN first | A private subnet may be provided by a corporate tunnel; don't blindly route it through the physical adapter. |
| Current node server | Keep the correct physical egress or exclusion rule | If the proxy's own connection is sent back through the same tunnel, it can create a connection loop. |
| Destination that needs a proxy | Match explicitly to the proxy egress | Prevent an earlier direct rule from matching first. |
VMess and VLESS are node protocols, not switches for whether traffic passes through a virtual adapter. After TUN captures UDP, the rest of the chain must also support forwarding it. If games or voice apps fail, check the node protocol, server policy, and firewall instead of repeatedly toggling the virtual adapter.
DNS and TUN: Check Resolution and Connection Paths Together
DNS determines which address a domain resolves to; routing determines where the connection goes next. Configuring a remote DNS server doesn't guarantee that queries use the proxy. Seeing a different web egress doesn't prove that your browser's encrypted DNS, system DNS, and other apps all use the same path.
- Direct destinations: Use a resolver suited to your network, and make sure the query path matches your direct-routing policy. Intranet domains may require your router or corporate DNS; a public resolver may not know them.
- Proxied destinations: Send related DNS queries through the proxy egress. If you use DoH, check not only the HTTPS URL but also which egress the connection to the resolver actually uses.
- Initial resolution: If the node or DoH server is identified by a domain name, make sure it can be resolved before the proxy is up. This avoids a dependency loop where the proxy needs DNS but DNS has to wait for the proxy.
- DNS hijacking: Pass conventional DNS queries entering TUN to the core for processing. This applies mainly to matching DNS traffic; it doesn't automatically capture every encrypted DNS connection created directly by an app.
- FakeDNS: Virtual address mappings preserve domain information and must be handled by a compatible entry point and rules. You don't need to enable it during your first TUN setup. If you do, clear any leftover cache after turning it off.
For example, an app might query a domain through your LAN router on port 53, while a private-address rule sends that connection direct—bypassing the proxy. Whether this is an unintended leak depends on your routing design: using internal DNS for intranet domains is normal, while resolving proxied destinations over the local network is worth investigating.
Troubleshooting: Separate DNS Failures from Connection Failures
Check the logs to see whether the destination address was resolved, then find which egress the connection used. If there's no resolution result, troubleshoot DNS. If an address is present but the connection times out, check the rules, node, and transport path. Don't blame both types of failure on TUN.
TUN Won't Start, Internet Is Down, or Some Apps Can't Connect: Troubleshoot by Symptom
Save the error details before changing settings. Log messages such as “permission denied,” “failed to create interface,” “port in use,” and “connection timed out” point to different stages. Changing the node, DNS, MTU, and network stack all at once makes it harder to identify the cause.
TUN reports that it failed to create the network adapter. What should I do?
First, fully exit v2rayN from the system tray, then restart it as administrator. Check whether security software is blocking a required component, and confirm the package is complete. If the problem persists, note the exact error in the logs. Don't delete physical adapters or clear routes in bulk.
The switch is on, but no websites load. What should I check?
Turn off TUN and check whether the original system proxy still works. If the regular proxy works, focus on the TUN logs, loop prevention for the node's egress, and initial DNS resolution. If the regular proxy also fails, troubleshoot the node or network first.
Web pages load, but games or voice apps still won't connect. What should I check?
Make sure the app isn't bound to another network adapter, then check whether UDP requests are reaching the core. Confirm that the node supports UDP, the server allows forwarding, and the destination isn't matching the wrong rule. A successful TCP web request doesn't test UDP.
Printers and LAN storage disappeared after enabling TUN. What should I check?
Check the direct-routing rules for the destination's private subnet first. Network discovery may also rely on broadcast or multicast, which a remote proxy can't restore. Try accessing the device at its actual LAN address to see whether only discovery is affected.
Still can't get online after turning off TUN. What should I check?
Clear the system proxy first, then check that the virtual interface and routes have been removed before clearing the DNS cache. If an abnormal exit left the network in a bad state, save your work and restart the system. Don't manually delete routes you don't recognize.
On Windows, run this command in a terminal to clear the DNS cache. It clears only the system cache; it won't fix incorrect routes or automatically clear every app's DNS cache. Restart your browser or other test apps if needed.
ipconfig /flushdnsVerify and Roll Back: Don't Rely on the Switch Alone
A configuration worth keeping should make proxied destinations reachable, preserve direct access, match your DNS routing plan, and restore normal connectivity when disabled. Test the apps you actually use, including at least one that ignores system proxy settings—not just the browser again.
- Confirm the entry point: After clearing the system proxy and any app-level proxy settings, the selected app can still use TUN to reach a destination that requires a proxy.
- Confirm the egress: Use an egress check alongside the logs to verify that the test destination matched the expected rule. Different split-routing destinations can use different egress paths; that's normal.
- Confirm LAN access: Open your router's admin page, storage device, or any intranet service you need for work to verify that your exception rules work.
- Confirm DNS: Check DNS settings for both the system and the app. Results should match your routing plan; the resolver's name alone isn't enough to judge.
- Confirm rollback: Turn off TUN and make sure normal network access returns, then re-enable the system proxy if needed. If connectivity doesn't recover, clear any leftover state before continuing troubleshooting.
TUN expands the range of traffic the client can handle; it doesn't remove every network restriction automatically. Checking the entry point, resolution, rules, and egress one by one is usually more effective than repeatedly switching cores or reimporting subscriptions. For subscription setup and system proxy basics, see the Getting Started guide. For routing and DNS concepts, see the full documentation.