System proxy and Tun determine how traffic reaches the client; routing modes determine which outbound route handles it. For everyday browsing, start with the system proxy and Bypass Mainland China. Switch to Global temporarily to troubleshoot routing, and consider Tun only for apps that ignore system proxy settings. This guide covers common v2rayN workflows on Windows, including port checks, command-line tests, and a safe rollback sequence.
System Proxy and Routing Modes: Ingress vs. Egress
Enabling the system proxy does not mean enabling Global mode. The system proxy writes a local proxy address to the operating system settings for apps that follow them. Global usually refers to a set of client routing rules that sends connections already received by the core through the proxy outbound. These settings are independent, so the system proxy can be on while routing sends traffic direct.
A connection passes through three stages: the app sends a request, the local inbound accepts it, and routing rules select an outbound. VMess and VLESS are connection protocols between the client and remote server; they do not make a browser use the system proxy automatically. A successful subscription update also does not prove that app traffic is reaching the client.
| Setting | What it does | What it cannot guarantee on its own |
|---|---|---|
| System proxy | Directs apps that follow system settings to a local proxy port | Does not capture every process, UDP traffic, or apps with their own proxy settings |
| Global routing | Routes connections received by the core through the proxy outbound | Does not capture connections that never reach the core |
| Bypass Mainland China routing | Uses domain, IP, and other rules to route traffic direct or through the proxy | Does not guarantee that every mainland China service using an overseas domain will be identified for direct routing |
| Tun mode | Uses a virtual network adapter and system routes to capture traffic from more apps | Does not disable outbound routing rules or guarantee coverage of every exceptional route |
Global vs. Bypass Mainland China: When to Use Each
For everyday use, start with split routing. Mainland China websites, LAN devices, and internal services are usually best reached directly; route other traffic that needs a proxy through the remote outbound. This avoids unnecessary detours and keeps local traffic off the server. Use Global temporarily to check whether a problem is caused by routing rules.
Two Routing Options
Global routing
- Useful for checking whether a domain is incorrectly routed direct.
- Useful when you temporarily want all traffic already captured by the client to use the proxy outbound.
- Before accessing local devices, check that private IP ranges are still routed direct.
- After switching modes, reconnect; existing connections may not change routes immediately.
Bypass Mainland China routing
- Useful when accessing services in mainland China and other regions at the same time.
- Depends on domain rules, IP data, and the actual rule order.
- Services using overseas domains or CDNs may still be routed through the proxy.
- For an issue with a specific site, add a rule for its domain first.
Use split routing day to day and Global temporarily for troubleshooting. Once you identify the cause, restore your usual setup; Global is not a fix for every network problem.
“Bypass Mainland China” does not determine routes based on page language or your location. In Xray routing, geosite:cn classifies domains, while geoip:cn classifies IP addresses. Some domains can match before DNS resolution; rules that depend on IP addresses are affected by the routing DNS strategy. A Chinese-language website does not mean every domain it uses will go direct.
- Rule order: Rules are usually checked from top to bottom, and the first match selects the outbound. Put domain-specific exceptions before broader rules that could override them.
- Pages with multiple domains: Login, images, and API requests may use different domains. Check each one instead of looking only at the main domain in the address bar.
- Default outbound: Traffic that matches no rule follows the generated core configuration. You cannot infer its route from the mode name alone.
System Proxy: Ports and Setup
First establish a working baseline with the system proxy, then consider Tun. The menu names below are based on common Windows interfaces; labels and locations can vary between desktop and WPF editions and across versions. Look for settings with the same name or function, and use the listening ports shown by your current client.
These ports are illustrative examples, not guaranteed defaults for every version. Some configurations use a mixed inbound that accepts both HTTP and SOCKS on one port; others use separate ports. The port number alone does not tell you which protocols it supports.
-
Confirm the Active Configuration
Select a valid server configuration in the main window, then choose “Set as active server” from the right-click menu. Wait for the core to start and check the logs for port conflicts or configuration errors.
-
Check the Listening Ports
Open “Settings” → “Parameter Settings” and find “Local listening port” and the related inbound settings. Confirm the protocol and port. If the interface shows one mixed port, configure apps according to the protocols it actually supports.
-
Set Up the System Proxy
Open the “System Proxy” menu at the bottom of the main window and select “Set system proxy.” Some versions also offer this in the tray menu. In Windows, check the address and port under “Settings” → “Network & Internet” → “Proxy.”
-
Choose Routing Rules
Choose a Bypass Mainland China profile from the “Routing” menu at the bottom of the main window. Check the active rules under “Settings” → “Routing Settings,” including private IP ranges, domains that should go direct, and the fallback route.
-
Test a New Connection
Close and reopen the test page, and restart the test app if needed. Check the destination and outbound in the logs for the new connection. A successful node latency test alone does not confirm that the browser is configured correctly.
Tun Mode: When to Use It and Its Limits
Consider Tun only when an app ignores system proxy settings, has no manual proxy option, or needs its UDP traffic captured. Tun uses a virtual network adapter and system routes to handle IP traffic, usually covering more apps than the system proxy—but that does not mean every connection goes through the remote server. Connections captured by Tun still follow routing rules.
System Proxy Baseline
- How traffic enters
- Apps follow the system proxy settings
- Listening address
127.0.0.1- Example ports
- HTTP
10809; verify against your actual configuration - Routing
- Use Bypass Mainland China for everyday traffic
Works well for browsers and other apps that follow the system proxy; use it to verify this connection path first.
Tun Capture Setup
- How traffic enters
- Virtual network adapter and system routes
- Permissions
- Permissions to create a network adapter and modify routes
- DNS checks
- DNS queries follow the intended routing setup
- Exclusions
- LAN, internal subnets, and essential service connections
Useful for apps the system proxy cannot capture; check for routing issues and network conflicts after enabling it.
v2rayN's Tun feature also depends on the selected Tun implementation and its supporting components. A proxy protocol and the Tun switch are not interchangeable. A working VMess or VLESS configuration does not mean the Tun component is ready; likewise, creating a virtual adapter successfully does not prove that the remote server supports the required UDP forwarding.
- Permissions: Grant the permissions requested by the client. If setup fails, check the startup logs first instead of repeatedly importing the subscription.
- Route conflicts: Corporate network access, other virtual adapters, and overlapping private subnets can all change the connection path.
- DNS: System, browser, and Tun DNS settings can coexist. A browser's own encrypted DNS can change the resolution path, so check it separately.
- UDP: Confirm that app traffic reaches Tun, the local forwarding path supports UDP, and the remote configuration allows the traffic.
- Existing connections: Restart the target app after changing how traffic is captured so old connections do not keep using the previous route.
Proxy Troubleshooting: Commands and Logs
To troubleshoot, bypass the system proxy settings and specify the local proxy port directly. If explicit proxying works but the browser does not, check the browser settings, extensions, and system proxy integration. If explicit proxying also fails, start by checking the listener, active configuration, and remote connection.
Here are two ways to test from a Windows terminal. These examples assume the sample HTTP and SOCKS ports are enabled and use a reserved example domain to show the command format. Replace it with the destination you need to troubleshoot. A successful command does not prove that any particular region's services are accessible.
# Send an HTTPS request through the HTTP proxy port
curl.exe --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 20 -I https://example.com/
# Use a SOCKS proxy and resolve the destination domain on the proxy side
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/The key difference between socks5h and socks5 is where the destination domain is resolved. The former sends the domain to the proxy side, though the core configuration still determines how it is resolved. The 10-second and 20-second values in the command are the connection timeout and total time limit—not measured latency or a performance guarantee. Command-line tools may not use the Windows system proxy automatically, so this example specifies the proxy explicitly.
| Test result | Check first | Next step |
|---|---|---|
| Local connection refused | Core is not running, port is incorrect, or the inbound is missing | Check the startup logs and listening settings |
| Timeout after proxy handshake | Remote connection, destination service, DNS, or routing | Use the logs to identify which stage failed |
| Command works; browser fails | Browser-specific proxy settings, extensions, or stale connections | Check the system proxy, then restart the browser and test again |
| Global works; split routing fails | Domain routed direct, IP rules, or DNS resolution differences | Check the destination's outbound and refine the relevant rule |
| Website works; app fails | App ignores the system proxy or uses UDP | Check the app's proxy options first; consider Tun if needed |
Common Questions and Rollback Steps
Why does an app still connect directly after switching to Global?
First check whether the app's connections reach the client. It may ignore the system proxy, use its own proxy settings, or still be using a connection established before the switch. If the request is missing from the logs, changing routing rules usually will not help. Fix how the traffic enters the client before changing its outbound route.
Why is a mainland China website still routed through the proxy with Bypass Mainland China enabled?
The site may rely on API or resource domains that are not included in the domain classification, or an earlier custom rule may match first. Identify the specific domain and outbound, then add a direct rule if needed. Do not route an entire large shared domain or every overseas address direct because one resource has a problem.
Should the system proxy stay enabled when Tun is on?
There is no single answer that applies to every configuration. If Tun captures the target app, the system proxy may not be needed as its entry point. Some apps may still prioritize their own proxy settings. For troubleshooting, start with one clearly defined way to capture traffic to reduce variables, and make sure Tun does not capture the core's own remote connection and create a loop.
Can I use the same menus on Android?
No. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. On Android, both typically use the system-provided virtual network interface to capture traffic. This entry mechanism differs from the Windows system proxy, and protocols and fields should be checked against the core in use. The same troubleshooting principle still applies: first confirm that traffic reaches the client, then check its outbound route.
If network access breaks broadly after enabling Tun, roll back to the verified baseline in this order. Change one layer at a time and record the result; this makes the cause easier to find than changing the node, DNS, rules, and core all at once.
- Turn off Tun and wait for the client to remove its routes. Check whether LAN access and the original network connection are restored.
- Check the system proxy: point it to the correct local port when needed, and clear it or restore its previous settings when finished.
- Keep one known-working active configuration and use an explicit proxy command to test the path from the local inbound to the remote server.
- Temporarily switch to Global and reconnect to see whether split routing is the cause. Restore your everyday rules after testing.
- If traffic capture is still needed, enable Tun on its own and check permissions, DNS, route conflicts, and app connections one by one.