TUN mode creates a virtual network interface so Windows traffic can be routed without configuring a proxy separately in every application. In v2rayN, successful setup depends on more than selecting a switch: the client must be able to create the interface, the required core must support the generated TUN configuration, and Windows routing and DNS must behave as expected. This guide covers preparation, setup, verification, common errors, and rollback. Menu labels can differ between v2rayN releases, so use the release notes and the setting’s description if your screen does not match exactly.
What TUN mode changes in v2rayN
A conventional system proxy tells compatible applications to connect to a local proxy listener. Applications that ignore Windows proxy settings may continue to connect directly. TUN mode works at a different layer: v2rayN asks a compatible core to use a virtual network interface, and Windows sends selected IP traffic through that interface. The core can then apply routing rules and choose an outbound connection.
This does not mean every connection is automatically proxied. The TUN configuration may include exclusions for local networks, routing rules that send some destinations direct, or DNS behavior that differs from ordinary proxy mode. Apps can also use their own networking or DNS behavior. Treat TUN as a way to capture and route traffic, not as a promise that every program will use the same route.
Keep TUN mode distinct from the Windows system proxy. They may be enabled together in some configurations, but enabling both without understanding the route can make testing confusing. For a first test, choose one routing method, connect one known-working node, and avoid running another VPN or traffic-capture utility at the same time.
- Use TUN mode when an application does not follow the Windows proxy setting or when you need traffic capture at the network-interface level.
- Use the system proxy when the applications you need already honor Windows proxy settings and you want a simpler setup.
- Check routing rules if only some destinations or applications use the expected outbound. A direct rule can be intentional rather than a TUN failure.
Prepare Windows, permissions, and the core
Before changing settings, connect a node that already works in the ordinary v2rayN proxy mode. This separates a node or subscription problem from a TUN problem. If the node cannot connect before TUN is enabled, first check the core log, server details, and the client’s normal proxy test. TUN mode cannot repair an invalid node configuration.
Use a current v2rayN release that documents TUN support, and check its release notes for the required core and Windows requirements. The interface and available options can change between releases. TUN support is implemented through the core configuration and a virtual network interface; it is not a transport protocol such as VLESS or VMess. Do not assume that switching the node protocol alone enables TUN.
Save any custom routing or DNS settings before editing them. If v2rayN offers a configuration export or backup option, use it; otherwise, record the settings you intend to change. Do not copy a TUN JSON example from a different core or release and paste it blindly into v2rayN. The client may generate a core configuration whose field names and supported options depend on the selected core version.
Windows may display an elevation prompt when the client needs permission to create or configure a virtual adapter or change routes. Approve it only when you intentionally launched the trusted client and understand why it needs elevated access. If you use a standard account, ask an administrator to authorize the change rather than repeatedly dismissing the prompt or disabling Windows security controls.
- Confirm that Windows has completed pending restarts, especially after installing network components or a core update.
- Temporarily pause other VPN or network-filtering tools for the test; do not remove them unless you have identified a conflict.
- Know how to return to the normal system-proxy setup before you start, so a failed route does not leave you without a usable connection.
Enable TUN mode and start it safely
Because v2rayN menus vary by interface and release, follow the setting by its purpose rather than relying on an exact screenshot. In the settings area, look for the TUN or virtual-interface option, read any prompt about core requirements, and confirm the selected core can run the configuration. Some releases expose TUN through a settings page; others place the control in a menu or tray action. If you cannot find it, check the help text for your installed release instead of adding an unrelated core option.
-
Check the node
In the main v2rayN window, select a node that connects in ordinary proxy mode. Confirm that the core starts and that a basic request succeeds before changing the traffic-capture method.
-
Check the core
Open the core or settings controls and verify that the TUN option is supported by the selected core and release. If the interface reports a missing component or unsupported configuration, resolve that first.
-
Review routing
Open the TUN, routing, or DNS options shown by your release. Keep defaults for the first test unless you have a specific requirement. Note any bypass rules for local networks and any DNS mode you change.
-
Start TUN
Enable the TUN control and accept the Windows permission prompt if expected. Watch the v2rayN status and runtime log for the virtual interface and core startup result.
-
Test one app
Open a browser or other test application and check a destination that you know is reachable through the selected node. Avoid changing DNS, routing rules, and node settings simultaneously.
If the TUN control turns on but the core exits, record the first relevant log message rather than only the final status. If Windows asks for permission each time, note whether the client is being launched with the same account and privileges. A permission problem, adapter creation problem, and node connection problem occur at different stages and need different fixes.
Verify traffic capture, DNS, and logs
Do not rely only on a TUN toggle that appears enabled. Confirm three separate things: the core starts without a fatal error, Windows has a usable network connection, and a test application’s traffic follows the route you intended. A successful browser page alone is not enough to prove that every application is captured; it may be using a cached connection or a different proxy setting.
| Check | Where to look | What a useful result looks like | If it fails |
|---|---|---|---|
| Core startup | v2rayN runtime or core log | The selected core remains running and reports no TUN initialization failure | Check core compatibility, required components, and the first error line |
| Windows interface | Windows network settings or adapter list | A virtual interface is present while TUN is active | Check permissions, adapter creation, and conflicts with other network tools |
| Application request | A fresh request from the test application | The destination loads and the core log shows a corresponding connection | Check routing rules, app proxy settings, and whether the request is cached |
| DNS behavior | Core logs and a new domain lookup | The name resolves using the configured DNS path and the request reaches its intended outbound | Review DNS settings, domain rules, and any local-network exclusions |
Use a fresh browser tab or restart the test application to reduce the chance that an existing connection hides the result. Compare the outcome with TUN disabled and ordinary proxy mode enabled. If the ordinary proxy test works but the same app fails only under TUN, focus on interface creation, routing, DNS, or exclusions rather than replacing the node immediately.
Check local destinations deliberately. Many configurations exclude private address ranges so printers, routers, and local services remain reachable. If a local resource works while a public destination follows the proxy, that can be the intended rule. Conversely, if all public traffic appears to bypass the selected outbound, inspect the route rules and the core log before changing the node.
Practical rule: verify one layer at a time
First confirm that the core starts, then confirm that Windows creates the interface, and only then judge application routing. This order prevents a DNS or node failure from being misdiagnosed as an adapter problem.
Fix common failures and return to the previous setup
When TUN fails, preserve the exact error text and identify when it appears: while enabling the option, during core startup, after the interface appears, or only when an application makes a request. That timing is often more useful than repeatedly switching nodes. Change one setting at a time and restart the TUN connection after each change.
Windows says permission is required. What should I do?
Confirm that you intentionally started v2rayN and that the prompt corresponds to its network operation. Approve it with an authorized account if appropriate. If elevation is denied, stop and ask the device administrator instead of trying to bypass Windows controls.
TUN is enabled, but no pages load. Where do I start?
Check whether the core is still running and read the first TUN or DNS error in its log. Then disable TUN, test the same node with the ordinary proxy, and compare. If only TUN fails, review core compatibility, DNS, and routing rules.
One program still connects directly. Is TUN broken?
Not necessarily. Check whether its destination matches a direct or bypass rule, whether the app uses a separate network component, and whether its request appears in the core log. Test a fresh request before changing global routes.
How do I undo the setup?
Turn off TUN in v2rayN, stop or restart the core as prompted, and restore the previous system-proxy choice if you changed it. Confirm that Windows can connect normally and that the virtual interface is no longer being used. Restart Windows only if the client or system reports that it is necessary.
For a core startup error, check whether the selected core supports the TUN settings generated by the client and whether the needed component is present. For a route or adapter error, close competing VPN or filtering software for a controlled test. For a DNS-only failure, restore the previous DNS settings and test again before editing domain rules. Do not delete network adapters or reset the entire Windows network stack as a first response; those steps can affect unrelated connections and remove useful diagnostic evidence.
To roll back cleanly, disable TUN from the v2rayN control that enabled it, stop the core, and return Windows proxy settings to the state you recorded earlier. Test ordinary connectivity before making any further changes. If the client exits unexpectedly or Windows still appears to route through the virtual interface, restart the client first and follow any release-specific cleanup instructions. Keep the relevant log lines, but redact subscription links, server addresses, identifiers, and credentials before sharing them.