How to Choose V2Ray System Proxy Modes: Global vs. Bypass Mainland China

First separate the system proxy from the routing mode

In v2rayN, “Set system proxy” and “choose global or bypass-mainland routing” operate at two different layers. The former determines whether an application hands its connection to a local proxy port; the latter determines which outbound path V2Ray or Xray uses after the traffic enters the core. Confusing the two often leads to a situation where the mode has changed but the browser’s results remain the same.

Think of the system proxy as a set of proxy addresses and ports exposed by the operating system for applications to read. Browsers, download tools, and some desktop apps follow this setting and send HTTP or HTTPS requests to the local port monitored by v2rayN. Once the core receives a connection, it matches routing rules based on factors such as the domain, IP address, port, network type, and protocol, then selects a proxy outbound, direct outbound, or blocked outbound.

When checking a configuration, follow the complete chain: does the application honor the system proxy, does the traffic reach the local listening port, which outbound does the routing rule select, and can the chosen node establish a connection? Global mode does not force every local process to read the system proxy. Likewise, enabling the system proxy does not mean every request will pass through a remote node, because routing may still send some connections through the direct outbound.

What the system proxy actually controls

After starting the core, v2rayN opens local HTTP, SOCKS, and other listening endpoints. The exact ports depend on the client’s current settings. When “Set system proxy” is enabled, the client points the operating system’s proxy configuration to these local endpoints. Applications that follow the system setting then send requests to the local machine instead of connecting directly to the destination.

The system proxy’s coverage depends on application behavior. Most common browsers read the system settings, but some command-line tools, standalone updaters, games, and apps with their own network stacks may ignore them. If an application never enters the proxy chain, changing global or bypass-mainland routing will have no effect because the core never receives that traffic. Check whether the app supports manually entering an HTTP or SOCKS proxy, or consider TUN mode when broader traffic interception is needed.

“Clear system proxy” is generally used to stop other applications from connecting to the local port. Restore the system proxy before exiting the client so the operating system does not retain an outdated address, which can make the browser report that the proxy server refused the connection after the core stops. If ordinary webpages fail to load after an abnormal exit, first check for a leftover system proxy instead of immediately deleting nodes or rebuilding the subscription.

Where the system proxy works best

• Primarily controls browsers and desktop apps that follow the operating system’s proxy settings.
• Everyday use cases where you want to enable or pause it easily and keep the affected scope clear.
• Quickly compare direct access with node-based access when troubleshooting a single site.
• You do not need to take over every network interface and do not want to affect software that ignores the system proxy.

What the system proxy cannot fix by itself

• The application completely ignores the operating system’s proxy settings, so no traffic reaches the local port.
• The node parameters, transport layer, security settings, or server status are incorrect.
• The domain has reached the core but routing assigned it to an unexpected outbound.
• Local DNS, browser cache, or another proxy tool is causing resolution or port conflicts.

Global mode: traffic scope and use cases

Global mode generally means that any traffic already inside the core and not handled by a higher-priority special rule is sent through the proxy outbound. Here, “global” applies to the routing layer; it does not mean every process on the operating system is automatically controlled. Connections that do not read the system proxy, specify a proxy manually, or fall under TUN may still leave directly through the local network.

The advantage of global mode is its straightforward path. When testing node availability, ruling out incorrect routing matches, or comparing results across nodes, temporarily reducing interference from domain and IP classification rules can help. If a site is unreachable in bypass-mainland mode but works in global mode, the node’s basic connection is probably working; focus next on domain classification, DNS results, and rule priority.

It also has clear limits. Local services already inside the client, LAN device addresses, loopback addresses, and destinations that must connect directly may still require direct rules. Sending every address through a remote node can cause problems when accessing a router’s admin page, a printer, or an internal company service. In practice, global proxying should often retain exceptions for private addresses and essential local destinations.

Global mode is useful for short diagnostic sessions and for cases where you genuinely want most traffic that has entered the client to use the same node. It is not a speed-boost switch. Page-load speed depends on node load, network path, destination response, transport settings, DNS, and the local system. Switching to global mode changes only the outbound choice; it cannot improve the node or network path by itself.

How bypass-mainland mode chooses direct or proxy access

The main goal of bypass-mainland mode is to send connections classified under mainland Chinese domains or mainland Chinese IPs through the direct outbound, while sending other eligible connections through the proxy outbound. It suits everyday browsing: commonly used local services stay direct, while destinations that need a node go through the proxy. Compared with sending all incoming traffic to a remote location, this usually avoids unnecessary detours and makes services that depend on the local network environment easier to access.

Domain rules and IP rules address two different stages. When an application starts a connection, the core can first evaluate a domain list if it has the destination domain. When a rule depends on the destination IP, the core may continue by matching the result of DNS resolution against IP categories. The domainStrategy in the routing configuration affects when domains are resolved and how the results are used. Follow the current core configuration for the exact generated value; do not infer every detail from the mode name alone.

Bypass-mainland mode does not guarantee perfect classification. A domain may use distributed DNS and service addresses from different regions, or contain multiple subdomains. The rule data must cover the destination domain or the resolved IP for a match to occur. If DNS returns an unexpected result, the domain has not yet been classified, or a custom rule has higher priority than a preset rule, the final outbound may differ from what you expect.

Remember that rules are usually matched in order. Moving a custom direct, proxy, or block rule changes the result of the preset mode. For example, if a domain is explicitly assigned to the proxy and placed before the mainland-domain rule, it may match the proxy rule first even when its resolved address falls within a mainland IP range. Conversely, a higher-priority direct rule can override later proxy decisions.

When bypass-mainland mode is a good fit

1. Your everyday destinations are mixed, and you want local services to connect directly while other traffic follows routing rules.
2. You need to preserve normal access to LAN resources, workplace intranets, or local devices.
3. You want to reduce unnecessary detours for traffic that could connect directly while keeping a unified client entry point.
4. You have confirmed that DNS and rule data are working and are willing to add custom rules for a small number of misclassified domains.

Mode names cannot replace result verification

After choosing bypass-mainland mode, test one destination expected to connect directly and another expected to use the proxy. Do not check only whether the page opens; also inspect the routing or outbound information in the v2rayN log. Relying solely on the browser result can be misleading because of caching, reused connections, and the browser’s own DNS behavior. Re-establish the connection after changing rules and, if necessary, restart the relevant core for a more reliable comparison.

Choose proxy and routing by use case

Everyday browsing: system proxy plus bypass-mainland routing

If you mainly use a browser and desktop software that follows the system proxy, a common combination is to enable the system proxy and choose bypass-mainland routing. The application first sends traffic to v2rayN, and the core then chooses direct or proxy access according to the rules. This combination keeps the control boundaries clear; the word “global” does not imply that every process has been taken over.

After the initial setup, choose a working node, enable the system proxy, and verify a direct destination and a proxied destination separately. If only one domain behaves unexpectedly, add a precise domain rule first instead of immediately switching the entire mode to global. Precise rules are easier to maintain and avoid expanding the affected scope.

Node testing: system proxy plus global routing

When testing a new node, temporarily enable global routing so that test traffic already inside the client uses that node consistently. This makes it easier to determine whether the handshake, transport, and remote outbound are working. If a connection still cannot be established in global mode, check the client log, server address, port, user identifier, transport, security parameters, and system time rather than continuing to adjust bypass rules.

Once the node connects successfully, restore bypass-mainland mode and verify traffic splitting. Testing the basic connection before the rules separates “node unavailable” from “routing mismatch” and reduces interference from changing several configuration items at once.

Debugging a single application: confirm how it connects first

When an application cannot access a destination through the proxy, do not switch to global mode first. Confirm whether it reads the system proxy. Check the app’s network settings and manually enter the local HTTP or SOCKS address provided by v2rayN. If manual configuration fixes the issue, the problem is at the application access layer. If the log shows the connection but the outbound is unexpected, inspect routing next.

If you need to take over more applications that ignore the system proxy, consider TUN mode. TUN handles a broader range of traffic at the network-interface layer and involves administrator permissions, routing tables, DNS, and a virtual network adapter, so troubleshooting differs from ordinary system proxying. Start by understanding the system-proxy path, then enable TUN only when needed to avoid introducing several variables at once.

Temporary troubleshooting: change one condition at a time

1. Keep the current node unchanged and switch routing from bypass-mainland to global.
2. Reopen the target page or close the old connection, then see whether the issue disappears.
3. If access is restored, check the target domain, resolved IP, and custom-rule match.
4. If it still fails, keep global mode and compare it with a node already confirmed to work.
5. After isolating the cause, restore the original mode and keep only the changes needed to explain the issue.

Troubleshoot inactive proxies and connection errors

The browser is unchanged after enabling the system proxy

First check that the operating system’s proxy address points to v2rayN’s local listening port, then confirm that no other program is using the port. Next, check whether the client log shows the relevant connection. If the log contains nothing, the browser may not read the system setting, may use its own proxy configuration, or may be reusing a connection established before the switch. Close the relevant pages, establish a new connection, and test again.

A destination connects directly by mistake in bypass-mainland mode

Record the complete domain instead of inferring from the root domain alone. A webpage may load APIs, scripts, or media from several subdomains, and one of them may match a different rule. Check the log for the actual request domain and outbound tag, then add a precise proxy rule. If the log shows only an IP, continue by checking DNS handling and whether routing retained the domain information.

The destination is still unreachable after switching to global mode

This usually means the issue is not limited to mainland traffic-splitting rules. Check in order that the node is enabled, the core started successfully, the local listening port is open, the node parameters are complete, the system time is accurate, and the current network can reach the server address. If the log clearly shows a timeout, compare another node or network environment. If it reports a configuration parse failure, correct the configuration fields first.

No webpages open after closing the client

Check whether the system proxy still points to a local port that is no longer running. Set the system to use no proxy or clear the system proxy through v2rayN, then test a normal direct connection again. This happens because the local entry point is closed while the operating system still forwards requests to it; it is unrelated to global or bypass-mainland routing.

Routing rules and configuration details

Routing configurations for the V2Ray and Xray cores generally include a domain strategy, rule sets, and outbound tags. Rules use outboundTag to point to a defined outbound. The snippet below only illustrates the relationship between these structures: private addresses connect directly first, while specified domains use the proxy. Actual tag names must match the outbound configuration generated by the client.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.net"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

AsIs means that the routing stage primarily matches the incoming domain form and does not actively resolve every domain for IP rules. Other strategies may resolve domains under specific conditions and continue matching IP rules. The strategy affects whether mainland IP classification can participate in the decision and also affects the DNS request path. When using v2rayN’s preset routing, first understand the generated configuration before deciding whether to adjust it manually.

Adding rules in the client interface is safer than directly editing a generated file while it is in use, because the file may be recreated when the client restarts the core, switches configurations, or updates a subscription. Keep custom rules as narrowly defined as possible: use an exact domain for one domain, suffix matching for a group of subdomains, and the appropriate network range for IP services. The broader a rule is, the more likely unrelated traffic is to share the same outbound.

A subscription provides node connection parameters; it does not necessarily determine which routing scheme the local device uses. Updating a subscription usually refreshes the node list, while the system proxy state, custom routing, and local DNS settings remain controlled by the client configuration. When traffic splitting behaves unexpectedly, repeatedly updating the subscription may not help. First determine whether the node content changed or a local rule matched incorrectly.

On desktop, v2rayN can use the V2Ray or Xray core to handle nodes and routing. On Android, v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Menu labels and default rules may differ between clients, but the diagnostic method is the same: confirm how traffic enters the client, then verify the routing match, and finally confirm the outbound connection. Do not infer the entire configuration result from a mode name in the interface.

Bottom line

For everyday browsing, start with “enable the system proxy and use bypass-mainland mode.” This lets applications that follow the system setting enter the client, where domain and IP rules determine direct or proxy access. When testing a node or ruling out a routing mismatch, temporarily switch to global mode, remembering that it affects only traffic already inside the core. If an application ignores the system proxy, adjust its own proxy settings or consider TUN instead of repeatedly switching routing modes.

The most reliable basis for choosing is not the mode name but the actual chain: did the application connect, did the local port receive the connection, which outbound did the rule select, and did the node complete the connection? Checking these four layers in order separates the issues handled by the system proxy, global mode, and bypass-mainland mode.