V2Ray System Proxy, Global, or Bypass Mainland China? A Guide to the Three Routing Modes

1. System Proxy and Routing: Two Settings to Understand

“I selected Global, so why are some apps still connecting directly?” Usually, the issue isn’t the server protocol—the connection never reached the core. v2rayN is a graphical client that manages configurations, starts the core, and controls the system proxy. The V2Ray or Xray core handles local inbound connections, routing decisions, and outbound connections. VMess and VLESS profiles in a subscription describe how to connect to a remote server; they don’t automatically route traffic from every app on your system.

For example, a browser that follows the system proxy sends requests to the local listener, then the core selects an outbound route based on the domain, destination IP, or inbound tag. Another app may use its own networking stack and ignore the system proxy, connecting directly instead. Switching between Global and Bypass Mainland China won’t change how that app handles its connections.

2. Global, Bypass Mainland China, or Rules Only: Which Should You Choose?

Mode names can vary between clients and routing templates. “Global” and “Bypass Mainland China” are common preset options. Here, “Rules Only” means routing based on custom rules evaluated one by one; not every client offers a button with that exact name. Don’t rely on the mode name alone—check the rule order, resource files, and fallback route.

Global routing isn’t necessarily faster, and it won’t improve your server’s bandwidth or network path. Routing traffic for services in mainland China through a remote server and back can add connection overhead or trigger alerts about logins from another region. Bypass Mainland China isn’t a perfect geographic filter either: a domain may use a CDN spanning multiple regions, and domain-based and IP-based classifications may differ.

3. Everyday v2rayN Setup: Enable the Inbound, Then Choose a Route

The steps below use the common Chinese-language v2rayN interface. Control locations can differ between desktop releases and the classic interface, so look for the menu labels. If your version doesn’t have a routing option with the same name, inspect the routing rules instead of choosing a similarly named mode. For initial testing, leave TUN off to avoid changing multiple variables at once.

1. Check the active profile

   Select an imported profile in the server list on the main screen, right-click it, and choose “Set as active server.” A successful subscription update only means the profile was retrieved; it doesn’t confirm the remote connection works. First, make sure the core starts normally and the logs don’t show an immediate shutdown error.

2. Enable the system proxy

   At the bottom of the main screen, select “System proxy” → “Set system proxy automatically.” Then check that the proxy address recorded in your system matches the client’s inbound listener, for example 127.0.0.1:10808. Replace the example port with the one actually in use.

3. Choose a routing mode

   At the bottom of the main screen, open “Routing” and choose a preset that bypasses mainland China. Common names include “Bypass Mainland China” and “Bypass Mainland China (Whitelist).” If only custom entries are available, first check that they include direct routes for mainland China domains and IPs, along with a proxy fallback.

4. Test each destination

   In the same browser, start a new connection to a service you use in mainland China, a destination that requires a proxy, and a local network service you actually use. Check the logs to see which outbound route was selected; a page loading in the browser doesn’t prove the connection went through the proxy.

5. Save your setup and exit

   Note the working combination of system proxy, routing, and DNS settings. To stop, select “System proxy” → “Clear system proxy” before exiting. If you configured an in-app proxy manually, restore that setting separately so the app doesn’t keep trying to connect to a closed local port.

On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Traffic is usually routed into the client through Android’s VPN permission; this is different from changing the system HTTP proxy on desktop. Check that the app is included in the VPN scope, then review the routing rules, especially any per-app exclusions. Don’t follow the desktop “Set system proxy automatically” steps on Android.

4. Rule Order and DNS: Why Routing Results Can Differ

Common routing rules in V2Ray and Xray are evaluated in order; the first matching rule determines the outbound route. More specific exceptions usually need to come before broad categories. If you want to proxy a mainland China domain but place it after a broad direct rule for mainland China, the earlier rule may already match, preventing the exception from taking effect.

• Check specific exceptions first: Put domains that need the proxy before any direct-routing category that could match them. The same principle applies to direct-routing exceptions.
• Then check rule resources: geosite:cn depends on the corresponding domain data, while geoip:cn and geoip:private depend on the relevant IP data. Missing resources can prevent the configuration from loading, not just make classification inaccurate.
• Set an explicit final route: “No match” doesn’t mean “direct by default.” The core usually uses its default outbound, and the client may generate an explicit fallback rule. Check the actual configuration.
• Understand the DNS path: An app may resolve a domain itself and pass the destination IP to the proxy, or pass the domain to the inbound listener. The core has different information in each case, which affects which domain-based rules it can match.

For example, an app may resolve a domain locally, then connect to the destination IP over SOCKS. Don’t assume the core can always route the connection by the original domain. Sniffing can provide domain information for some traffic, but it can’t identify every protocol. Browser Secure DNS, system DNS resolution, and core DNS are separate settings. After changing one, check the logs and test an actual request.

5. Test Mode Changes: Change One Variable at a Time

If a destination won’t open in Bypass Mainland China but works in Global, keep the active profile, app, and destination the same and change only the routing mode. If Global works, first check whether the destination used a direct route in the original mode, matched the wrong category, or resolved to different IPs over the direct and proxy routes. This narrows down the cause; one successful test alone doesn’t prove the rules are at fault.

1. Record the baseline: Note the current system proxy state, active profile, and routing mode. Check that the logs show no port-binding errors.
2. Start a new connection: Close and reopen the destination page, or restart the test app if needed. Existing long-lived connections may not switch routes immediately when you change modes.
3. Compare outbound routes: If the logs show outbound tags, distinguish direct from proxy routes. Tag names depend on the configuration, so don’t rely on a particular word.
4. Restore the original mode, then add an exception: Switch back to the original routing mode, add a more specific rule for the domain that used the wrong route, and retest with a new connection.

If both modes fail, go back to troubleshooting the inbound and remote connection. Interpret connection refused in context: if the target is 127.0.0.1:10808, the local process may not be listening or the port may be wrong. If the target is a remote address, check the remote service and network reachability. Don’t change the port, protocol, DNS, and routing all at once just because you see one error message.

6. Common Questions About System Proxy and Routing Modes