V2Ray System Proxy vs. Global and Bypass China Modes: How to Choose a Routing Mode

System Proxy vs. Routing Mode: Access and Outbound Routes

v2rayN is a GUI client for managing nodes, subscriptions, and the core. App requests first enter the core through a local proxy endpoint, then routing rules select an outbound route such as Direct, Proxy, or Block. The system proxy registers a proxy address with the operating system, so apps that honor that setting send requests to the local endpoint. It does not determine whether the final destination is reached directly or through a remote node.

1. Access layer: A browser can read the system proxy settings, or an app can be configured to use an HTTP or SOCKS proxy. TUN captures eligible traffic through a virtual network interface.
2. Decision layer: The core checks details such as the destination domain, IP address, and port against the active rules.
3. Outbound layer: A Direct match reaches the destination over your local network; a Proxy match establishes a remote connection through the selected node.

So, “Why do domestic sites still connect directly when the system proxy is on?” is usually not a sign of a problem. With Bypass China routing, direct connections to destinations in mainland China are expected. Conversely, if you switch to Global but a game still doesn't use the node, the game may not honor the system proxy, meaning its requests never reached the core.

Global, Bypass China, and Direct: What Each Routing Mode Does

Preset names may vary slightly between versions. Don't rely on the mode name alone; check the rules, their order, and the default outbound. The table summarizes what common presets are intended to do, but doesn't replace checking the rules in your current configuration.

Using VMess, VLESS, or another protocol does not automatically determine how traffic is routed. Importing a subscription mainly provides node settings; check separately whether it includes additional configuration and whether the client uses it. After updating a subscription, verify the active node and routing mode rather than assuming they stay unchanged.

v2rayN and v2rayNG: Where to Change the Settings

The steps below use v2rayN on Windows and v2rayNG on Android. Client versions, layouts, and translations may differ, so use the setting names shown in your current version. Note the original values before making changes to avoid losing track of what caused a problem.

v2rayNG uses the Xray core; v2flyNG uses the v2fly core. Both are Android clients, but their settings screens and supported features aren't interchangeable. Check the installed version and configuration when reviewing the core and settings used by v2rayN, too. To compare behavior across devices, record at least the client version, core version, access method, and routing mode.

Test with a Local Port: Did the Request Reach the Proxy?

Start with a small, repeatable test. The examples below assume the test configuration uses 127.0.0.1:10809 for the HTTP endpoint and 127.0.0.1:10808 for the SOCKS endpoint. These are example values, not fixed defaults for every version. If you're using a mixed port, enter the actual endpoint instead.

In Windows Terminal, use curl.exe to avoid command environments that interpret curl as something else. The requests below fetch only response headers; if the test site doesn't accept HEAD requests, remove -I and try again. The example URL is for connectivity testing, not benchmarking.

# Test a direct connection without using a proxy
curl.exe --noproxy "*" -I --max-time 15 https://example.com/

# Explicitly use the local HTTP proxy
curl.exe --noproxy "" --proxy http://127.0.0.1:10809 -I --max-time 15 https://example.com/

# Explicitly use SOCKS and resolve the destination domain through the proxy
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 -I --max-time 15 https://example.com/

• Local connection refused immediately: Check the port, listening address, and core status first. This doesn't yet indicate a problem with the remote node.
• Explicit proxy request succeeds, but normal browsing fails: Check whether the browser honors the system proxy, has its own proxy settings, or is still using an existing connection.
• Request times out after reaching the core: Check the destination and outbound details in the logs, then investigate node reachability, the handshake, and DNS. A timeout alone doesn't prove there's a routing problem.
• An HTTP status code is returned: At least one HTTP response was received. A status such as 403 may reflect the destination service's access policy, not a broken proxy connection.

socks5h sends the domain to the proxy for handling, but where it is ultimately resolved and which resolver is used still depend on the core's DNS and routing configuration. Don't assume this option guarantees that all DNS traffic goes through the remote node.

Work, Gaming, and Development: Choose a Route for Each App

Routing modes aren't speed settings. An extra remote hop can add latency, while a direct connection can still be affected by local network quality. First identify the destinations an app needs, then choose the access method and outbound route. That's more effective than repeatedly switching to Global.

Many games don't read the desktop system proxy, and an HTTP proxy is not a general-purpose UDP tunnel. Even with TUN enabled, confirm that the node, protocol, and server support the traffic in question. Gaming latency depends mainly on the network path, congestion, and packet loss; web page load times aren't a reliable indicator.

Development tools often have their own proxy settings, too. Setting environment variables in a terminal only affects programs that read them, and processes already running may retain the old environment. Configure appropriate exclusions for intranet repositories and test services to avoid sending domains resolvable only on the company network through an unsuitable DNS path.

When Bypass China Doesn't Behave as Expected: Check Rules, DNS, and Connections

“A site in mainland China” is how a user describes it; routing rules match domains, IP addresses, and other criteria. A Chinese-language site may use overseas APIs, and a single page may request resources from multiple CDNs, login services, and media hosts. If only part of a page fails to load, identify the specific failing domain rather than drawing conclusions about the entire site.

1. Confirm that a new request reaches the client. Retest with a command that explicitly uses the local proxy port. If the core logs show no matching request, check the access method and log level first.
2. Check rule order. Routing rules are usually evaluated in order, so a broad rule near the top may take precedence over a more specific one below it. After adding a domain rule for direct access, make sure it appears before any rule that would override it.
3. Check the rule data. geosite:cn classifies domains; geoip:cn classifies IP addresses. They don't make the same kind of match, and updating the rule data may change the results.
4. Check DNS and destination details. IP-based rules may rely on an existing destination IP or trigger a lookup according to the active domain policy. Differences between browser secure DNS, core DNS resolution, and company intranet DNS are all worth checking.
5. Establish a new connection before testing again. Changing a route may not alter the outbound path of an existing connection. Close the relevant connection or reopen the app, then test again; reconnect the client if needed.