This guide is for users who have imported a server and can connect through a browser, but whose terminal or other apps don't use the system proxy. The steps focus on Windows: verify the server, run v2rayN as administrator, enable TUN, check routes and DNS, and restore network settings afterward. TUN expands which traffic can be captured; routing rules still determine whether it uses the proxy.
TUN vs. system proxy: different entry points, same routing rules
A system proxy gives apps a local proxy address, such as 127.0.0.1:10808. An app must honor this setting to send requests through the proxy. Browsers usually use the system proxy, while command-line tools may require environment variables or explicit proxy options. So if a browser connects but a terminal doesn't, the server isn't necessarily down.
TUN is a Layer 3 virtual network interface. System routes send matching IP packets to the interface, where the TUN component handles connections and selects an outbound route. Apps don't need to understand HTTP or SOCKS proxies. v2rayN is the configuration and management interface; the core component it launches handles packet capture, parsing, and forwarding. Common versions use components related to sing-box for TUN. Check the current version's logs for details; enabling TUN does not mean Xray natively creates a virtual network adapter.
| What to check | System proxy | TUN mode |
|---|---|---|
| Traffic capture point | Local HTTP or SOCKS listening port | Virtual network adapter and system routes |
| App compatibility | Apps must use the proxy setting or be configured manually | Apps usually need no proxy configuration |
| Permissions | Usually configurable as a standard user | Changing interfaces and routes usually requires elevated privileges |
| UDP traffic | An HTTP system proxy alone can't handle all UDP traffic | Can be captured, but the outbound route and server must also support UDP |
| Is all traffic proxied? | Depends on app settings and routing rules | Depends on the capture scope and routing rules |
Decide whether your apps need TUN
If you only need a proxy in your browser, start with the system proxy. Try TUN when terminals, games, or other apps can't be configured to use a proxy. Keep direct-connection rules in place; capturing traffic doesn't mean every connection must go through a remote server.
Before you start: check the server, permissions, and local ports
First, select a verified working server in v2rayN. A subscription distributes server configurations; VMess and VLESS are protocols used by servers; TUN is a local traffic entry point. They serve different purposes. Switching to TUN won't fix a server that already fails to connect.
- In the main window, select the target server and set it as active from the right-click menu. With the system proxy enabled, first open an HTTPS page that normally loads reliably.
- Open Settings → Parameter Settings and note the local listening port. Tabs and field names may differ between versions, so use the values shown in your current interface.
10808below is only an example. - Temporarily exit other VPNs or virtual network tools that control system routes. Leave your regular network adapters enabled; don't disable system devices in bulk.
- Save your work and exit v2rayN, including any background process in the system tray. Right-click the app and select Run as administrator, then approve the system permission prompt.
Local entry point
- Listening address
- 127.0.0.1
- Example port
- 10808; use the value in your settings
- How to verify
- Test HTTPS with the system proxy first
- Local network access
- Not required for local TUN
Don't change the listening address to all network adapters just to enable TUN.
TUN startup checklist
- Run with
- Windows administrator privileges
- Initial routes
- Keep your current working routing setup
- Initial MTU
- Keep the current version's default
- Check the logs for
- Interface creation, route installation, and DNS errors
Establish a repeatable baseline before changing network settings, one at a time.
If you still see a missing component error when running as administrator, check that the installation archive was fully extracted, that security software hasn't quarantined a core file, and that the file path shown in the log exists. Don't download similarly named driver files from untrusted sources. If you need to reinstall, choose the package for your system on the download page.
Enable TUN: change one traffic entry point at a time
The TUN controls are in different places across v2rayN versions. A common setup has an Enable TUN switch at the bottom of the main window, with related options under Settings → Parameter Settings in the TUN section. If your version has a separate TUN menu, use that entry instead. Don't follow screenshots from another version to change fields that aren't there.
- Confirm the active server. Check the selected server in the main window and the outbound configuration in the logs to make sure you're testing the intended connection.
- Clear the system proxy. Select Clear system proxy from the system proxy menu, and temporarily disable any proxy set manually in your browser. This ensures you're testing TUN, not the old local proxy entry point.
- Keep the default TUN settings. For the first test, don't change the network stack, MTU, routing mode, and DNS at the same time. Defaults are more likely to match the current version's configuration logic.
- Turn on Enable TUN. Wait for the core to start, then check the logs for a virtual interface or route installation. If it exits immediately, address the first error instead of toggling the switch repeatedly.
- Start a new connection. Close existing browser tabs or terminal sessions, then try again. Existing long-lived connections may not switch routes as soon as the setting changes.
Don't force remote server traffic back through TUN. The management app usually avoids routing loops by binding to an interface or adding bypass routes, but running several network tools at once can disrupt this. If the logs repeatedly show connections to the same server address, timeouts, and an unusual rise in traffic, turn off TUN first and investigate route conflicts.
DNS setup: distinguish lookup failures from connection failures
DNS resolves domain names to IP addresses; routing determines how connections are sent. Once TUN captures traffic, DNS requests also need a working route. If remote DNS must go through the proxy, but the proxy server's hostname can only be resolved through that remote DNS, startup can get stuck in a dependency loop.
- Resolving the server hostname: Make sure DNS has a route available during startup. Don't casually replace a server hostname from a subscription with a temporary IP; certificate checks and server configuration may depend on the original hostname.
- Resolving direct-connection domains: Make sure DNS results work with the direct route, especially for intranet services, printers, and company domains.
- Resolving domains through a proxy: If remote DNS is configured to use the proxy, make sure the server connection can be established first.
- Secure DNS in browsers: A browser may use its own encrypted DNS, so different results in the browser and terminal don't necessarily mean the system DNS cache is corrupted.
Under Settings → DNS Settings, or the DNS section in Parameter Settings in your version, note the current values first. Then review options for direct and remote DNS resolution. Fields vary by core and version; don't paste a standalone core's JSON snippet into an arbitrary field in the GUI. For a first setup, use the defaults provided by your version.
# Windows PowerShell: Check network adapter status and DNS settings
Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-DnsClientServerAddress -AddressFamily IPv4
# Check the system's DNS resolution path; replace with the domain you're troubleshooting
Resolve-DnsName example.com
# Clear the Windows DNS cache after changing DNS
ipconfig /flushdnsResolve-DnsName checks the system's DNS resolution path, not the result from a browser's built-in resolver. After clearing the cache, start a new connection and restart the test app if needed. If the name resolves but HTTPS times out, check the server, routes, and firewall instead of repeatedly changing DNS.
Verify traffic capture: cross-check the interface, routes, and apps
A lit switch alone doesn't prove TUN is working. Compare network interfaces and routes before and after enabling it, then make a request from a terminal with no proxy configured and check the v2rayN logs. Interface names and indexes depend on the version and local setup, so don't look for just one fixed adapter name.
# Windows PowerShell: View IPv4 routes and interface indexes
Get-NetRoute -AddressFamily IPv4 |
Sort-Object InterfaceIndex, DestinationPrefix |
Format-Table DestinationPrefix, NextHop, InterfaceIndex, RouteMetric
# Check whether the current terminal inherited proxy environment variables
Get-ChildItem Env: | Where-Object Name -Match 'proxy'
# Test a new HTTPS connection without an explicit curl proxy
curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com/Here, --noproxy "*" tells curl not to use application-level proxy settings; it does not bypass the operating system's TUN routes. If the rules send the test domain direct, success only proves that this route works—it doesn't prove traffic went through the remote server. To test proxy routing, choose a destination you need to reach that matches a proxy rule, then check the outbound route in the connection log.
| What you see | Likely cause | Next step |
|---|---|---|
| No new interface; startup log shows a permissions error | TUN interface was not created | Exit all background processes, then restart as administrator |
| Interface exists, but there's no log entry for the target connection | Traffic isn't captured by the route, or the target is excluded by a rule | Check interface routes, excluded subnets, and other VPNs |
| Domain lookup fails, but the server still connects | DNS settings or resolution path issue | Check the resolver, domain rules, and browser secure DNS |
| Web pages work, but UDP apps fail | UDP outbound support or routing rules don't match | Confirm UDP support on the server and outbound route, then check the firewall |
| Small requests work, but large downloads stall | Possible MTU or path compatibility issue | Note the current value, then test a smaller MTU by itself |
Check the outbound route in the logs, not just whether a page loads
During testing, note the target domain, test time, and outbound route shown in the logs. A successful connection that matches a direct rule is not the same as one that matches a proxy rule. Confirm the actual route before evaluating speed or reliability.
To investigate a possible MTU issue, note the original value, change only the MTU in TUN settings to 1400 for a comparison test, then restart TUN. This is a troubleshooting starting point, not an ideal value for every network. Restore the original value if there's no improvement. Don't change DNS, the network stack, and the server at the same time, or you won't know which change made a difference.
Troubleshooting and restoring your network after TUN
Why does the Enable TUN switch turn off right away?
Open the logs and find the earliest error from this startup. If permissions are insufficient, exit all v2rayN processes and restart as administrator. If a component is missing, check the installation directory and quarantine history. If configuration parsing fails, restore the TUN settings you just changed. Repeatedly clicking the switch won't help identify the error.
Do I need to enable the system proxy when TUN is on?
For the first test, clear the system proxy so the two entry points aren't mixed together. Once TUN is capturing traffic, most apps don't need a local proxy configured. You can configure a proxy separately for an app that requires one, but make sure you know which entry point it uses during testing.
Web pages load, but the company intranet and printer don't. What should I do?
Check whether your routing rules send local network destinations direct. Common private IPv4 ranges include 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Company domains may also depend on internal DNS. Confirm the actual addresses and your company's network requirements before adding rules; don't route the entire company network through a remote outbound connection without a reason.
IPv4 works, but some websites still stall. Could IPv6 be the issue?
Test the same destination with curl.exe -4 -I https://example.com/ and curl.exe -6 -I https://example.com/, then check IPv6 routes and DNS responses. If the IPv6 route fails, align TUN's capture scope and DNS policy with the network's actual capabilities. Don't permanently disable IPv6 based on a single slowdown.
My PC has no internet after I close v2rayN. How do I restore it?
Open v2rayN again, turn off Enable TUN, clear the system proxy, then exit normally. In Windows Settings → Network & Internet → Proxy, check that no manual proxy address remains. If the connection still doesn't recover, reconnect to the network or restart the computer. Don't delete all network adapters or default routes.
When exiting, turn off TUN before closing the app so it can remove temporary interfaces and routes. If the issue only occurs after waking from sleep, switching Wi-Fi networks, or connecting to a company VPN, note what triggered it, then restart TUN and test again. A network switch changes the physical route out; old interface bindings and connections may need to be re-established.
- Before reporting an issue, note the v2rayN version, Windows version, TUN-related core version, and time of the first error.
- Keep the steps to reproduce: whether the system proxy was cleared, whether other VPNs were closed, and which domain or app failed.
- Before sharing logs, remove subscription URLs, user IDs, passwords, and server credentials. Keep the error type and any network details needed to diagnose the issue.
Choose a client and platform
Choose the v2rayN package for your operating system. After installation, confirm the server and system proxy work before enabling TUN as described here. For help importing a subscription and selecting a server, see the usage guide.