This guide uses v2rayN on Windows desktop. First, verify the node with the system proxy; then enable TUN as an administrator and test routing, DNS, and app connections separately. It’s useful when a browser connects but command-line tools or other apps don’t use the proxy. After TUN captures traffic, routing rules still determine whether it goes direct or through the proxy.
System Proxy vs. TUN: Where Traffic Is Captured
A system proxy provides a local proxy address to apps that follow the system settings. The app sends requests to the proxy’s listening port, and the client forwards them. Apps using their own network stack, separate proxy settings, or direct UDP connections may bypass this setting. A working browser doesn’t prove that other apps are using the proxy.
TUN provides a virtual interface at the network layer. System routes send matching IP packets to this interface for the TUN backend to handle, then forward them through a direct or proxy outbound. Apps generally don’t need to support HTTP or SOCKS proxies, but that doesn’t mean every network protocol or address will be routed successfully.
Distinguish between two meanings of “global”: TUN’s traffic capture scope and the proxy scope set by routing are controlled separately. Even with TUN enabled, local network addresses, private IPs, and rule-matched destinations can still connect directly. To proxy all capturable public internet connections, check the routing mode and fallback outbound—not just whether the TUN switch is on.
Before You Start: Record Ports, Node, and Routing Baseline
In v2rayN, select an imported node and set it as the active server, then use the system proxy to load a real webpage. A latency result alone isn’t enough: a successful test only confirms that its specific probe path works, not that DNS, TLS, and application traffic are all working. If this step fails, first check the node address, credentials, transport settings, and server status.
10808 is only an example for the tests below. Open Settings → Parameter Settings and find the local listening port setting. Replace the port in the commands with the actual value. Depending on the version, you may see a mixed listener or separate SOCKS and HTTP ports. Use the HTTP proxy test command below only if you’ve confirmed that the port supports HTTP proxying.
- Note the active node, routing mode, and system proxy status. Back up the client configuration if needed.
- Exit other VPN, accelerator, and proxy apps that take over the default route or DNS. Keep just one traffic-capturing app active for the baseline test.
- Confirm that the current package includes the required core components. If the logs report a missing executable, install the component before trying TUN again.
- On a company-managed device, first confirm that network and endpoint security policies allow virtual interfaces. Don’t bypass management policies by disabling security software.
Enable TUN on Windows: Administrator Rights and TUN Settings
These instructions are for v2rayN versions with an “Enable TUN” switch. Button locations may vary between desktop and WPF editions and across versions. The main window usually has the TUN switch; settings are generally under Settings → Parameter Settings, on a TUN-related page. If you don’t see these options, check the client version and package type. Don’t manually create a network adapter with the same name in Windows network settings.
- Exit completely before elevating. Quit v2rayN from the system tray and make sure the existing process has stopped. Then right-click the program and select “Run as administrator.” Reopening only the window while the tray process is still running may leave the client using the old process’s permissions.
- Confirm the active node. Check the current server and routing mode in the main window. Keep using a node you’ve already verified. When enabling TUN for the first time, don’t also change subscriptions, transport settings, or DNS.
- Check the TUN settings. Keep the defaults for the stack, MTU, and routing settings on your first try. If you use a custom configuration, make sure automatic routing is enabled; otherwise, the virtual interface may not capture the connections you expect.
- Clear the system proxy. Use the client’s system proxy menu to clear the system proxy and test TUN on its own. The two features aren’t inherently incompatible, but enabling both makes browser tests inconclusive about whether TUN is working.
- Enable TUN and watch the logs. Turn on “Enable TUN” in the main window. Check for permission errors, interface creation failures, core process exits, or configuration parsing errors. If an error appears, turn TUN off and address the first clear error in the logs.
Routing and DNS: Keep LAN Access and Prevent Outbound Loops
TUN has to solve a basic routing problem: app traffic needs to enter the tunnel, but traffic from the proxy core to its server must not be sent back into the tunnel indefinitely. The client and backend normally handle this with route exclusions, interface binding, or similar mechanisms. Multiple traffic-capturing apps, manually added default routes, or incomplete custom settings can break this arrangement.
Initial test baseline
- Traffic capture
- Enable TUN only; clear the system proxy
- Active node
- Keep the node already verified with a real connection test
- TUN stack and MTU
- Keep the current version’s defaults
- DNS settings
- Keep the working client settings; don’t change resolvers at the same time
Change one variable at a time, then use the logs to identify capture, resolution, or outbound issues.
Adjust after the baseline passes
- LAN destinations
- Allow private ranges such as 192.168.0.0/16 to connect directly as needed
- Proxy server
- Make sure its connection isn’t routed back into TUN
- Public internet destinations
- Choose an outbound according to the current routing rules
- DNS path
- Make sure the resolver is reachable through the corresponding outbound
These are items to check, not configuration keys you can import. The exact fields depend on the backend version.
A LAN rule that lists only 192.168.0.0/16 is incomplete. Check your actual network for ranges such as 10.0.0.0/8 and 172.16.0.0/12, as well as IPv6 link-local addresses. Set printers, file shares, and gateway admin pages to connect directly as needed; don’t assume a setting named “Bypass LAN” covers everything.
DNS needs testing too. Standard UDP/TCP port 53 queries and encrypted DNS built into an app don’t follow the same path. If a browser uses its own resolver, results may differ from the system’s. With FakeIP enabled, a synthetic address doesn’t automatically mean DNS is broken; check whether the backend can still map it back to a domain. Clearing the cache won’t fix an unreachable resolver.
Verify Traffic Capture: Don’t Just Refresh the Browser
For testing, turn off any manually configured browser proxy and confirm that the system proxy is cleared. Close and reopen the app to avoid reusing existing connections. The commands below distinguish an explicit proxy connection from a regular system-routed connection. The test domain provides a repeatable HTTPS request; it doesn’t show whether a specific website matches a proxy rule.
# Run in Windows PowerShell
# Use the first command only if you’ve confirmed that port 10808 supports HTTP proxying
curl.exe -I --connect-timeout 10 --proxy http://127.0.0.1:10808 https://example.com
# Prevent curl from using an explicit proxy; let system routing handle the request
curl.exe -I --connect-timeout 10 --noproxy "*" https://example.com
# Check current interfaces and IPv4/IPv6 routes
Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
Get-NetRoute -AddressFamily IPv6
# Check system DNS query results separately
Resolve-DnsName example.com- Compare results with TUN off and on. Turn TUN off, run a request without an explicit proxy, then enable TUN and try again. Also check whether the client logs a new connection from the app. One successful request doesn’t prove the traffic took a different route.
- Check the matched outbound. A test destination may already be set to connect directly by a rule. To verify proxy routing, choose a destination explicitly configured to use the proxy and check the connection record or appropriate routing logs.
- Test IPv4 and IPv6 separately. If needed, add
-4or-6to the request. If one works and the other fails, check traffic capture and outbound support for that address family instead of assuming the node is down. - Test the target app on its own. After testing a browser and command-line requests, check the app that actually has the problem. UDP support depends on the TUN backend, node protocol, and server; an HTTPS test can’t confirm it.
Don’t just look for a 0.0.0.0/0 route pointing to the virtual interface. Automatic routing may use more specific split routes. Check the destination, prefix length, and interface to see which route is actually selected. Increase log verbosity only temporarily, and remove node addresses, credentials, and private browsing details before sharing logs.
Common Issues: Check Permissions, Traffic Capture, DNS, and Outbound Routing
TUN reports an error and switches itself off?
First quit v2rayN completely from the system tray, then run it as an administrator. Check the first interface, permission, or core startup error in the logs. If a component is missing or a configuration field is incompatible, fix the package or revert the custom TUN settings. Administrator rights won’t fix a configuration parsing error.
System proxy works, but enabling TUN cuts off all network access?
Exit other VPNs and accelerators, leaving just one traffic-capturing app. Turn TUN off to restore the baseline, then check route changes and server connection logs after enabling it. If the proxy server connection is also being captured, review custom route exclusions instead of repeatedly switching nodes.
Connections work, but domain names won’t resolve?
Use Resolve-DnsName example.com to check system DNS resolution separately, then inspect the client’s DNS logs and resolver outbound. Run ipconfig /flushdns to clear stale cache only after confirming the configuration is fixed. Check the browser’s own DNS settings separately.
Printers or company intranet sites unreachable after enabling TUN?
Record the actual address of the intranet destination and check private-range direct routes and interface routes. Company-specific domains may also depend on internal DNS; a public resolver usually won’t return the right result. Save the original configuration before making changes, and don’t blindly add the entire company address range to the proxy.
Web browsing works, but games or voice chat don’t?
First check that the app isn’t bound to a different interface. Then inspect UDP connection logs and confirm that the node supports UDP. If small packets work but larger connections stall, investigate MTU or path MTU next. Don’t start by changing the MTU without evidence.
Turn TUN Off and Roll Back: Stop Traffic Capture Before Exiting
When you no longer need TUN, turn off “Enable TUN” in v2rayN and confirm that regular network access is back before quitting the client. To switch back to the system proxy, first make sure the local proxy listener is working, then set the system proxy again from the client. This lets you distinguish the virtual interface route from app proxying and avoids leaving a system proxy pointed at a stopped process.
- Turn TUN off normally and check the logs for backend shutdown and route cleanup.
- Clear any system proxy settings you no longer need, then reopen and test the target app.
- If network access is still down after an abnormal exit, restart the client and toggle TUN off and on normally, or restart Windows. Then check for leftover routes.
- Don’t delete unfamiliar virtual adapters, clear the entire route table, or reset every network interface. These actions can also break other network configurations you need.
TUN controls how app traffic enters the client. Node availability, DNS resolution, and routing-rule outbound selection are separate concerns. Record results in this order: system proxy baseline, TUN-only test, and target app retest. This usually makes issues easier to isolate than changing several settings at once. For more on routing rules and DNS, see Advanced Setup; for terminology, see the glossary.