If an app ignores the Windows system proxy, v2rayN’s regular proxy mode may not capture its traffic. TUN mode uses a virtual network adapter to route more device traffic through the proxy core instead. This guide walks through the prerequisites, the setup sequence, and practical checks for confirming that traffic is flowing. It also covers the most common causes of failure: insufficient permissions, a conflicting VPN or network adapter, a core that does not support the selected mode, and DNS or routing problems. Menu wording can vary between v2rayN builds, so use the labels in your installed version and check the startup log rather than assuming that a toggle alone means TUN is working.
What TUN mode changes on Windows
In ordinary system-proxy mode, v2rayN asks Windows applications to use a local proxy address. The application must honor the Windows proxy settings, or provide a way to enter the proxy address itself. That works for many browsers and desktop programs, but not every application reads those settings. Some command-line tools, games, launchers, and background services open network connections directly, so they can bypass the proxy without showing an error.
TUN mode takes a different approach. It creates a virtual network adapter and routes selected traffic through that adapter so the proxy core can process it. This operates below an individual application’s proxy setting. When configured correctly, it can therefore cover programs that do not use the Windows system proxy. It is not a separate protocol and does not make a broken node usable: the core still needs a valid outbound server configuration, and the network still needs to reach that server.
TUN also changes the scope of the configuration. System-proxy mode is mainly an instruction to compatible applications; TUN mode can affect traffic from many applications and Windows services. That broader capture is useful, but it means routing rules matter more. A direct rule may send a destination outside the proxy, while a proxy rule sends it through the selected node. A rule that catches the wrong traffic can make local devices, intranet sites, or other VPN connections stop working.
The SOCKS port shown above is a common v2rayN default, not the TUN adapter’s port. TUN does not require you to enter that port in every application. If an app is still configured to use a manually entered proxy, remove that setting for the first test or verify that it points to the active local listener. Otherwise, the app could try to use two different proxy paths and give misleading results.
Check the prerequisites before enabling TUN
Start by confirming that v2rayN can connect through your chosen node in its normal mode. Select a known working server and run the client’s real connection test, then open a browser with the system proxy enabled and load a site you can normally reach through that node. TUN mode adds traffic capture; it does not repair a node that fails its handshake, has an invalid address, or cannot reach its server port. Establishing this baseline makes later results much easier to interpret.
Use a current v2rayN build that exposes TUN mode and includes or can launch a compatible core. The exact menu label and core options may differ by release. In the interface, look under Settings for a TUN-related option, or inspect the core selection and TUN settings provided by your build. If the option is absent, do not try to create a virtual adapter manually as a substitute. First update v2rayN from the site’s download page, then review the release’s included core choices and configuration notes. A core must support the settings v2rayN is asking it to run.
Plan to approve the Windows permission prompt. Creating or configuring a virtual network adapter and changing routes can require elevated rights. Close other VPN or tunneling clients during the first setup, including tools that install their own virtual adapters. Two clients attempting to control routes or DNS at the same time can produce a connection that appears partly functional: the browser works, but a game, DNS lookup, or local network connection does not.
- Keep a note of your current network state, including whether Windows system proxy is enabled and which other VPN clients are running.
- Confirm that the selected node works before turning TUN on. Check the core log for a successful outbound connection rather than relying only on a green status icon.
- Use an account allowed to approve the Windows elevation prompt. If a managed computer blocks adapter installation, ask its administrator instead of bypassing policy.
- For a clean test, disconnect other VPNs and pause other traffic-capture clients. Do not remove a corporate or required connection without authorization.
Enable TUN mode step by step
Menu names can shift between v2rayN builds, but the sequence is the same: confirm the node, open TUN settings, choose a supported configuration, approve adapter setup, and verify that the core starts without an error. If your interface uses different labels, follow the equivalent TUN and core controls rather than copying a path from a different release.
Test the node
Select a working node in v2rayN and run its real connection test. If the test fails, resolve that first; TUN capture cannot fix a failed proxy handshake.
Open TUN settings
Open Settings and locate the TUN mode or TUN configuration controls. Check that the selected core is available and supports the displayed TUN options.
Choose routing
For the first test, use the simplest available routing mode that sends the test application through the proxy. Avoid adding custom DNS or complex bypass rules until basic connectivity works.
Start with permission
Enable TUN and accept the Windows administrator prompt if it appears. Wait for the core and virtual adapter to finish starting before opening applications.
Verify traffic
Check the core log for a new request, then test a browser and an application that normally ignores Windows proxy settings. Turn TUN off if the adapter or core reports a startup error.
Some builds expose separate controls for enabling TUN and configuring details such as the virtual interface, DNS, or route behavior. Keep the defaults for the first pass unless the interface identifies a specific requirement. If you change several options at once, it becomes difficult to tell which change caused a failure. Record the original values or take a screenshot of the settings before experimenting.
When Windows asks to install or configure a network component, check that the prompt belongs to the expected application or driver and approve it only if it does. A permission prompt that was denied can leave v2rayN running while the virtual interface is missing. In that case, turn TUN off, close the client, restart it with the required permissions, and enable TUN again. Avoid repeatedly toggling the setting while Windows is still installing the adapter.
Verify routing and DNS with controlled tests
Start with a comparison rather than a single page load. With TUN off, note whether the chosen application can reach the test destination. Turn TUN on, wait for the core to start, and repeat the same action. In v2rayN’s core log, look for a request from the test destination and the outbound selected for it. A browser loading a page proves only that some traffic works; it does not prove that all applications are being captured or that the intended routing rule was used.
| Check | Where to look | What a useful result looks like | If it fails |
|---|---|---|---|
| Core startup | v2rayN core log | The selected core starts and reports no TUN or adapter creation error | Check permissions, core availability, and the first startup error |
| Adapter presence | Windows Settings → Network & internet → Advanced network settings | A virtual adapter appears while TUN is active | Restart v2rayN with the required permissions and enable TUN again |
| Application capture | Core log while the test app makes a new request | A request for the test destination appears and matches the expected outbound | Check whether the app reused a connection, bypassed capture, or hit a direct rule |
| Name resolution | Core log and a fresh domain lookup | The domain resolves and the resulting connection reaches the expected outbound | Review TUN DNS settings and any DNS filtering or competing VPN |
| Local network | One known router, printer, or intranet address | Local resources remain reachable under the selected routing policy | Review private-network routes and direct/bypass rules |
Use a new request for each test. Browsers keep connections open, cache DNS answers, and may reuse a connection established before TUN was enabled. Close and reopen the test application, or use a new destination, before deciding that capture failed. Likewise, do not treat a failed ICMP ping by itself as proof that the proxy is down: the destination may block ping even when an application connection works.
DNS deserves a separate check because it may follow a different path from the application’s connection. A domain can fail to resolve even while direct IP connections work, or resolve to an address that the routing rules handle differently. First test with the default DNS configuration supplied by the build. If you later change DNS, change one setting at a time and inspect the core log for lookup errors. Do not assume that enabling TUN automatically guarantees that every DNS request uses the proxy.
Practical check: verify the request, not just the switch
A TUN toggle can be on while traffic still fails because the adapter did not start, the core rejected its configuration, or a routing rule sent the request elsewhere. The strongest quick check is a fresh request visible in the core log with the outbound you expected.
Fix permissions, connectivity, and VPN conflicts
When TUN does not work, identify the first failed layer. If the core never starts, focus on core selection and its error message. If the core starts but Windows shows no virtual adapter, focus on permission and adapter installation. If the adapter exists and requests reach the core, focus on routing, DNS, or the outbound connection. This order prevents unrelated changes—such as replacing a working node when the real problem is a blocked adapter—from making diagnosis harder.
Windows proxy works, but TUN does not. What should I check first?
Open the core log immediately after enabling TUN. If the core reports a permission or adapter error, restart v2rayN with the required Windows permissions and enable TUN again. If startup succeeds, check whether the virtual adapter appears in Advanced network settings.
The toggle is on, but my app still connects directly. Why?
Close and reopen the app to force a fresh connection, then trigger a request while watching the core log. If no request appears, check whether another VPN or traffic-capture client owns the route. If it does appear, inspect the matched routing rule and outbound.
Browsing works, but domains sometimes fail to load. Is the node broken?
Not necessarily. Test a fresh domain lookup and check the core log for DNS errors. Restore the TUN DNS defaults for a baseline, then review any custom DNS setting, security filter, or other VPN that might be intercepting name resolution.
Can I leave another VPN connected at the same time?
Do not use that as the first test. Disconnect other VPNs and TUN-based clients, verify v2rayN alone, then re-enable the other connection only if its configuration and routing requirements allow it. Competing routes can cause intermittent or one-way connectivity.
How do I restore normal network access after a failed test?
Turn TUN off in v2rayN, stop the core, and disconnect other test clients. If connectivity does not return, restart Windows to clear stale routes or adapter state. Do not delete adapters or reset network settings unless the logs or an administrator point to that specific problem.
For a core startup failure, copy the first relevant error from the core log and use it to narrow the cause. A missing executable or unsupported option points toward core availability or version compatibility. An access-denied message points toward Windows permissions. A successful startup followed by outbound timeouts points away from adapter installation and toward the node, server reachability, DNS, or routing policy. Change only the setting linked to the observed failure, restart the core, and repeat the same test.
Once basic TUN routing works, add exceptions deliberately. A direct route for private network addresses can preserve access to a router or office resource, but an overly broad direct rule can also bypass the proxy for destinations you intended to tunnel. If you use custom rules, test one local address and one external destination after each change. When finished, keep a simple rollback path: turn TUN off, restore the known-working node and settings, and re-enable the feature only after the log identifies a specific fix.