This guide uses v2rayN on Windows and is for users whose system proxy works but whose terminal or other apps still cannot connect as expected. Test your node first, enable TUN with administrator privileges, then check the traffic coverage, routing results, and DNS separately. TUN sends traffic into the processing chain; it does not mean every connection must use a proxy. Permissions and network management differ on macOS and Linux.
TUN Virtual Adapters vs. System Proxies
A system proxy provides a local proxy address to apps that support the setting. Browsers usually do, but some terminal tools, games, and apps that create their own connections do not. TUN creates a layer 3 virtual network interface and uses system routes to send IP packets to a local network processing component. This can cover more apps that do not support HTTP or SOCKS proxy settings.
“Capturing all traffic” describes the scope of the entry point; “global proxy” describes the outbound policy. They are not the same setting. Connections received by TUN can still be routed direct, through a proxy, or blocked based on domain, destination IP, or other supported criteria. LAN traffic, loopback addresses, and explicitly excluded routes may also bypass TUN. An enabled switch alone does not prove that all traffic is being captured.
| Comparison | System proxy | TUN mode |
|---|---|---|
| How traffic enters | Apps connect to a local proxy port | System routes send IP packets to a virtual interface |
| App requirements | Apps must support the system proxy or have a proxy configured individually | Proxy addresses usually do not need to be configured app by app |
| Permissions | Changing the current user's proxy usually does not require elevated privileges | Creating an interface and changing routes usually require elevated privileges |
| UDP support | HTTP system proxies do not cover ordinary UDP traffic | Still depends on the TUN component, protocol, and server support |
| What to check | Listening port and app proxy settings | Interface, routes, DNS, and outbound connection |
Before enabling TUN: Check the node and local port
Turn off TUN and test the node through the system proxy or an app's manual proxy settings. Successfully importing a subscription only confirms that the configuration was read; it does not mean the remote server is reachable. VMess, VLESS, and other connection parameters, transport settings, and TLS options must still match the server. If a regular proxy connection already fails, fix the node first so you can separate node issues from virtual adapter problems.
These are protocol ports and test examples, not performance measurements or a promise about v2rayN's default listening values. Check the local listening port under Settings → Parameter Settings; menu labels may vary by version. Run the command below only after confirming that the port accepts HTTP proxy requests. The example assumes the listening address is 127.0.0.1 and the port is 10808.
curl.exe --proxy http://127.0.0.1:10808 --head --connect-timeout 10 https://www.example.com/- Receiving HTTP response headers means the proxy chain worked for this request. It does not prove that every website or UDP connection is available.
- If the local port connection fails, first check that the core is running, the listening port matches, and no other process is using that port.
- If the handshake or remote connection fails, check the core logs and verify the node, system time, and server settings.
- Note your current system proxy, routing mode, and DNS settings. Close other tools that capture network traffic and keep a recoverable baseline.
How to Enable v2rayN TUN on Windows
v2rayN provides the configuration and process management interface; a companion component handles TUN traffic. The switch location, network stack options, and startup method can vary by version. Do not treat a desktop app setting as a universal V2Fly or Xray field. Confirm that your installed package includes the TUN component required by that version before elevating privileges.
- Exit and restart with elevated privileges. Quit v2rayN from the system tray and confirm the existing process has ended. Right-click the app or shortcut and select “Run as administrator.” If your version provides an elevated restart option, you can use that instead.
- Select a working node. Choose a node from the server list that you have tested with a regular proxy, and check the current routing mode. For the first test, keep your existing rules; do not change the node, DNS, and network stack at the same time.
- Clear the system proxy. In the main window or system tray menu, select “Clear system proxy.” This reduces variables caused by having two traffic entry points; it is not a mandatory prerequisite for enabling TUN in every version.
- Enable TUN. Find and turn on “Enable Tun” or the equivalent TUN switch in the main interface. Capitalization may vary. If the option is missing, check your platform, installation package, and documentation for your version. Do not install network drivers from unknown sources.
- Check the startup logs. Make sure there are no errors for insufficient permissions, interface creation, or route updates. Then check the system network interfaces and routes before making a request without an explicit proxy.
Routing and DNS: What Happens After Traffic Is Captured
A stable setup needs to answer two questions: which outbound route a connection matches, and which DNS resolution path returns an address for a domain. After TUN captures a connection, routing rules still need to preserve local network access and prevent the proxy server's own connection from re-entering the proxy path and creating a loop. Prefer the configuration generated by the client for your current TUN setup. Do not paste JSON for a different core into it.
Initial traffic capture checklist
- System proxy
- Clear it for isolated testing
- TUN switch
- Check startup logs after enabling
- Local addresses
- Preserve loopback and LAN access
- Proxy node
- Keep using the tested node
This is a client setup checklist, not a set of importable core configuration fields.
DNS checks
- Traditional DNS
- Check how UDP/TCP port 53 is handled
- Encrypted DNS
- Check the app's DoH settings separately
- DNS resolution route
- Make sure the DNS upstream is reachable over the selected route
- IPv6
- Check IPv6 routes and resolution results too
Capturing traditional DNS traffic does not mean in-app encrypted DNS follows the same policy.
Handle LAN addresses according to your actual network layout. For example, 192.168.1.0/24 may be the subnet used by a home router, while a corporate network may use something else. Adding one example subnet does not cover every private network. Check the routing table to confirm the ranges used by printers, file servers, and internal DNS.
- Base domain rules on the available information. An app may resolve a domain itself before opening an IP connection. If your rules depend on domain names, check how your TUN setup preserves or recovers domain information; do not assume every connection includes a domain name.
- Make sure the DNS upstream does not depend on a connection that is not yet available. If the proxy node's address needs to be resolved, avoid a startup dependency where the node must connect before its own address can be resolved.
- Test IPv4 and IPv6 separately. A working webpage does not prove that both address families follow the intended route. Without an IPv6 capture route, an app may use a different outbound path.
- Reload after changing rules. Save and reload the configuration through the client, then test a new connection. Existing long-lived connections may continue using the route they started with.
Verify TUN: Interfaces, Routes, and Live Connections
Do not rely only on the taskbar icon or virtual adapter name. A reliable check aligns three pieces of evidence: the interface exists, the target uses the expected route, and the connection log shows the correct outbound. Interface names depend on the component and version, so they will not be identical on every machine. Routes may also use networks more specific than the default route, so searching only for 0.0.0.0/0 is not enough.
Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
Get-NetRoute -AddressFamily IPv6
curl.exe --noproxy "*" --head --connect-timeout 10 https://www.example.com/Run the first three commands in PowerShell. The last command uses --noproxy "*" to bypass curl's explicit proxy setting and let the request use system routing; it does not bypass TUN. A successful request proves only that the current destination is reachable. Check the logs too to see whether it went direct or through the proxy.
| Test case | Action | How to verify |
|---|---|---|
| App without proxy settings | Clear its individual proxy settings and make a new request | The core logs show the connection and expected outbound route |
| LAN service | Access an actual gateway, printer, or internal site | The local service is reachable and was not sent to a remote proxy |
| Domain resolution | Clear the app cache, then visit a test domain | DNS logs, connection destination, and routing policy agree |
| UDP app | Use the voice or other UDP feature you actually need | The server and selected protocol support it, with no repeated failures in the logs |
ping uses ICMP and is not a TCP or UDP proxy test. A target that does not respond to ping does not mean TUN is broken. Likewise, opening a webpage in a browser does not prove that voice, games, or all UDP requests work. Test each real app using its actual transport protocol.
Troubleshoot TUN Startup Failures, Lost Connectivity, and Adapter Conflicts
Troubleshoot in this order: permissions and components, interfaces and routes, DNS, then the remote connection. Change one variable at a time and save the logs around the time the issue occurred. Virtual machines, corporate remote access software, and other virtual adapters can coexist legitimately. If a problem occurs, first disable competing traffic-capture features instead of uninstalling every network adapter.
The switch turns itself off as soon as I enable it. What should I do?
First check whether the app is running with administrator privileges. Then look for interface creation, missing file, or permission errors in the logs. Confirm that the installed package includes the required component and that security software or policy has not quarantined it. Do not repeatedly switch network stacks based on the failure alone; find the first startup error.
All websites stop loading after I enable TUN. Is it a DNS problem?
Not necessarily. Turn off TUN and retest the existing local proxy connection. If that still fails, check the node first. If the regular proxy works, compare the TUN routes with the DNS logs. Focus on DNS upstream reachability, query routing, and startup resolution for the node's domain if you see DNS timeouts.
Websites load, but voice chat or games cannot connect. What should I check?
Confirm that the app actually uses UDP, then check whether the current proxy protocol and server support that traffic. Look for the destination in the logs, then check the firewall. A successful TCP webpage test cannot replace a UDP test, and changing the local listening port alone will not add server-side support.
My company network or printer is unreachable after enabling TUN. What should I do?
Turn off TUN first and check whether access returns. Then compare the target LAN subnet with the current routes for overlap. Add direct or bypass rules for the actual subnet. If you still need corporate remote access, coordinate routes in accordance with your organization's network policies; do not override managed network settings.
My connection is still down after I close the window. How do I restore it?
First distinguish closing the window from exiting the app: the system tray process may still be running. Reopen the main window, turn off TUN, clear the system proxy, and then quit from the tray. If the process crashed, start it again and shut it down normally. If routes remain, save the routing information and restart the system to confirm recovery.
Exit TUN and Keep a Reproducible Setup
After testing, keep a minimal record of the operating system, client version, current node protocol, TUN switch, routing mode, DNS upstream, and the first error seen when the problem occurred. Do not share subscription URLs, connection credentials, or full configurations containing user identifiers. Your notes should show which step changed the behavior, not just say “it stopped working after I enabled it.”
- Turn off TUN and wait for the logs to show that the relevant process or interface has stopped. Confirm that regular network access is restored.
- If you still want to use the system proxy, set its mode separately. If you are exiting the client, leave the system proxy cleared.
- Test LAN access and your usual sites again, and check whether another tool is still controlling the default route.
- Once the baseline is stable, enable custom routing rules or other advanced options one at a time. Avoid importing multiple rule sets that may override one another.
TUN expands the range of traffic that can enter the processing chain, but the final behavior still depends on routing, DNS, and outbound connectivity. For details on individual fields, see the configuration field reference. Do not mistake client-generated TUN settings for a universal config.json that works with every core.