v2rayN normally works through a local SOCKS or HTTP proxy. That is convenient for browsers and applications that follow Windows proxy settings, but it does not automatically capture every program. Applications with their own proxy settings, command-line tools, launchers, background services, and software that opens direct sockets may continue to connect outside v2rayN. TUN mode solves this limitation by creating a virtual network adapter and inserting a system-level traffic path that the selected core can process.
This practical guide explains how to enable TUN mode in v2rayN on Windows 10 and Windows 11, select a compatible core, preserve your existing system-proxy configuration, choose between rule-based and global routing, verify that packets are really being captured, and recover safely when DNS, permissions, or route conflicts prevent normal connectivity.
What v2rayN TUN mode changes
TUN mode adds a virtual Layer-3 network interface to Windows. Instead of asking each application to send traffic to 127.0.0.1:10808 or 127.0.0.1:10809, the operating system sends selected IP packets toward the virtual adapter. The TUN-capable core then reads those packets, applies DNS and routing logic, and forwards them through a direct or proxy outbound.
This is different from the Windows system proxy switch. “System Proxy” changes a Windows proxy setting that compatible applications may read. TUN mode changes the packet path at the network layer. Enabling both can be useful during migration, but it can also make troubleshooting harder because a browser may use the HTTP proxy while another application enters through the TUN interface.
TUN does not turn an unavailable node into a working one. The selected VMess, VLESS, Trojan, or other outbound must still have valid server information, credentials, transport parameters, and an operational core. TUN only changes how traffic enters the client. If a normal browser test through the local SOCKS port already fails, repair the node or core first, then enable system-wide capture.
The port numbers above are common examples from v2rayN configurations, not fixed TUN ports. TUN traffic is captured through the adapter and routing table, so changing the local SOCKS port does not directly change the virtual interface. Always check the ports shown in your current configuration before testing with curl, a browser, or another local application.
Prepare Windows before enabling TUN
Start with a reversible setup. Keep the current v2rayN profile, subscription group, active node, routing mode, and local port values unchanged until ordinary proxy mode has been tested. If TUN fails, you should be able to disable it and return to the previous configuration without importing the subscription again.
- Use a current v2rayN 7.x build: menu names and TUN controls can differ between minor releases, so read the labels in the installed build rather than copying a path from an older screenshot.
- Run with suitable permissions: creating an adapter and changing routes may require administrator approval. If Windows shows a User Account Control prompt, allow it only for the v2rayN process you deliberately started.
- Check the core: TUN support depends on the core selected by the client. If the TUN page identifies a sing-box-based mode or asks for a TUN-capable core, do not assume that every Xray or v2ray core can provide the same function.
- Record the existing state: note whether “System Proxy” is enabled, which routing mode is active, and whether a VPN, security suite, virtual machine, or other network filter is running.
- Keep one test node ready: use a known-working VLESS or VMess profile first. Testing TUN and an unverified subscription at the same time creates two independent failure sources.
Conclusion: prove the node before changing the packet path
First connect one browser through v2rayN’s ordinary local proxy and confirm that the selected node works. Then enable TUN and repeat the same test. Comparing two identical requests is far more reliable than changing the node, routing mode, DNS, and adapter together.
Windows may already contain adapters from virtual machines, corporate VPN software, container platforms, or previous transparent-proxy tools. Do not delete unfamiliar adapters simply because their names look similar. Instead, identify the adapter created after TUN is enabled and note its status in Settings → Network & internet → Advanced network settings. A disabled or duplicate adapter is a common source of confusing route behavior.
Enable TUN mode in v2rayN step by step
The exact menu wording depends on the v2rayN edition and release. In recent 7.x builds, TUN-related controls are commonly located under the settings or parameters window, near core selection, routing, DNS, or transparent-proxy options. The important sequence is to select a compatible core, enable TUN, choose routing behavior, apply the settings, and restart the core when requested.
-
Test normal proxy
Select a known-working node, start the core, enable “System Proxy” if required, and confirm one browser request. Record the current local ports and routing mode before making changes.
-
Open parameters
Open v2rayN’s main menu and enter “Settings” or “Parameters settings”. Look for the TUN, transparent proxy, or virtual adapter section. Do not edit the generated JSON unless the interface explicitly requires it.
-
Choose the core
Select the core recommended by the TUN page. If the build provides a sing-box TUN option, use its supported version and allow v2rayN to download or locate the matching core through the normal installation workflow.
-
Enable the adapter
Turn on “Enable TUN mode” or the equivalent option, accept the administrator prompt, and choose the automatic adapter method unless your environment requires a manually named interface.
-
Apply and verify
Save the settings, restart the core if requested, and check Windows network adapters. Test a direct destination and a proxied destination separately before changing DNS or advanced route options.
For the first test, select rule-based routing rather than forcing every destination through the proxy. A typical setup sends private addresses and local network ranges directly, sends selected mainland categories directly, and uses the proxy for other destinations. The exact result depends on the generated rules and GeoIP or GeoSite data available to the selected core.
Rule-based TUN
- Capture
- Virtual adapter traffic
- Routing
- Domain and IP rules
- Private LAN
- Usually direct
- Fallback
- Configured proxy or direct outbound
Best starting point because it keeps local printers, routers, and intranet services reachable while allowing selected traffic to use the node.
Global TUN
- Capture
- Virtual adapter traffic
- Routing
- Proxy by default
- Private LAN
- May need an exception
- Fallback
- Proxy outbound
Useful for a short diagnostic test, but it can make local devices, update services, and region-specific sites fail if exclusions are missing.
Do not confuse the remote destination port with the local v2rayN port. A rule such as port: 443 refers to the destination service port, while 127.0.0.1:10808 refers to a local proxy listener. TUN traffic may never use the local SOCKS listener at all, so checking only whether port 10808 is listening cannot prove that TUN is active.
Verify capture, DNS, and routing results
Verification should test three separate questions: does the adapter exist, does traffic enter the core, and does the selected rule send that traffic to the intended outbound? A page loading successfully is not enough because it may be served from cache, use a browser-specific proxy, or connect through a path that does not represent other applications.
- Open Windows network settings and confirm that the TUN or virtual adapter is present and enabled.
- Check v2rayN’s core log while starting and stopping the adapter. Look for adapter creation, route installation, DNS startup, and inbound connection messages.
- Close the browser’s manually configured proxy, if any, so the test depends on the TUN path rather than a second proxy path.
- Test a local address such as the router management address or a LAN service. It should remain reachable when private-network rules are configured correctly.
- Test an external destination and compare the observed exit region or address with the selected proxy node.
Command-line checks can provide useful evidence. In PowerShell, Get-NetAdapter lists interface status, while Get-NetRoute displays active routes. Use Test-NetConnection example.com -Port 443 to test TCP reachability, but remember that this command does not itself prove which outbound was used. For an HTTP request, compare a request made with the system path against one explicitly using curl --proxy http://127.0.0.1:10809 https://example.com when the HTTP listener is enabled.
How can I tell whether an application ignores System Proxy?
Disable the application’s manual proxy setting, leave TUN enabled, and watch the core log while it connects. If the application works only with System Proxy but not with TUN, check its protocol, DNS behavior, and whether a firewall or security product blocks the virtual adapter.
Why does the browser work but a desktop tool still bypass?
The browser may be using the HTTP listener while the desktop tool opens direct sockets or uses its own network service. Confirm the TUN adapter is running, then inspect the tool’s process rules, firewall permissions, and core log entries during a fresh connection.
Why can I reach websites but not my router?
Global routing may be sending private addresses to the proxy. Add or restore direct handling for private ranges such as geoip:private, verify the LAN gateway, and restart the core so the revised route table is applied.
Should System Proxy remain enabled with TUN?
For a clean diagnosis, test TUN with the browser’s manual and system proxy settings disabled. Afterward, keep both enabled only if you understand the precedence and need compatibility for applications that use HTTP proxy settings instead of the virtual adapter.
Troubleshoot common TUN failures
When TUN cannot start, begin with the first error in the core log rather than repeatedly switching nodes. Adapter creation, permission, DNS, route, and outbound errors occur at different layers. A valid subscription cannot repair a failed adapter, and changing DNS cannot fix a port conflict in another program.
Error: failed to create TUN device
Cause and fix: The required virtual adapter component is unavailable, blocked, or already held by another process. Restart v2rayN with the required permission, check network adapters, close competing VPN or transparent-proxy tools, and retry with the supported core.
Error: access is denied
Cause and fix: Windows rejected adapter or route changes. Approve the administrator prompt, check whether security software is blocking v2rayN, and avoid launching a second copy with a different permission level.
Error: address already in use
Cause and fix: A local listener or DNS endpoint is occupied by another process. Check the configured SOCKS, HTTP, and DNS ports, close the conflicting service, or assign an unused port before restarting the core.
Error: DNS request timeout
Cause and fix: The selected DNS path cannot reach its upstream or is caught in a routing loop. Test with the default DNS mode, exclude the local gateway from proxy routing, and confirm that the TUN core is not sending its own DNS requests back into itself.
Error: failed to find an available destination
Cause and fix: The selected outbound lacks a usable destination or cannot resolve the server address. Check the node address, subscription update result, system time, and core compatibility, then retry with a known-working profile.
A frequent symptom is “the internet stops immediately after enabling TUN.” Disable TUN from the same settings page, restart the core, and confirm that ordinary system-proxy mode works again. If it does, re-enable TUN with the least complex configuration: automatic adapter settings, rule-based routing, default DNS behavior, and one verified node. Add custom DNS, process rules, or global routing one change at a time.
Another symptom is that local applications fail while public websites work. Check whether the generated rules contain a direct route for geoip:private, loopback addresses, and the local subnet. Also verify that the TUN adapter does not become the default route for the gateway itself. A wrong default route can prevent Windows from reaching the router, DHCP service, or DNS server needed to establish the proxy connection.
| Symptom | Most likely layer | First action |
|---|---|---|
| No TUN adapter appears | Permission or core support | Check the selected core, administrator approval, and adapter status |
| Browser works, other apps bypass | Capture path | Disable manual browser proxy and inspect TUN traffic in the core log |
| All sites time out | DNS, route, or outbound | Return to rule-based routing and test the known-working node |
| LAN devices are unreachable | Private-network routing | Restore direct private-IP and local-subnet rules |
| Works until v2rayN restarts | State or startup order | Check automatic startup, adapter persistence, and route installation logs |
After the configuration is stable, keep a rollback note containing the previous routing mode, system-proxy state, local ports, selected core, and TUN settings. This takes less than a minute to create and makes future core or Windows updates much easier to diagnose. TUN mode is most reliable when it is treated as a separate capture layer, not as a replacement for careful node testing and route verification.