System Proxy, Global Mode, and Bypass Mainland China Explained: How to Choose

System proxy, global mode, and bypass-mainland routing often appear together in the same client interface, but they operate at different layers. System proxy settings determine whether an application hands its connections to a local proxy port. The latter two mainly determine which outbound is used after those connections enter the V2Ray or Xray core. Separating the traffic entry point from core routing is fundamental when troubleshooting inaccessible websites, slow mainland services, or applications that bypass the proxy.

First, separate the two control layers: system proxy handles entry, while routing mode handles the exit

On desktop systems, v2rayN listens on local ports after starting the core. In a common configuration, the SOCKS entry is 127.0.0.1:10808, and the HTTP entry is 127.0.0.1:10809. Check the actual ports under v2rayN’s “Settings” → “Parameter Settings”, because migrated configurations, port conflicts, or manual changes may alter them.

When system proxy is enabled, the client points the operating system’s proxy address to these local ports. Browsers and desktop applications that follow system proxy settings then pass requests to v2rayN. Disabling system proxy only removes that entry-point setting from the operating system; it does not stop the core or necessarily terminate established connections. Applications with a manually configured SOCKS address can continue using the local proxy.

Therefore, “enable system proxy and use bypass-mainland mode” is a complete combination, not two mutually exclusive choices. The former sends traffic from applications that support system proxy into the core; the latter then selects an outbound such as direct, proxy, or block based on the domain, IP, port, or inbound tag.

• Application layer: whether a program reads the system proxy settings or manually specifies a proxy port at 127.0.0.1.
• Inbound layer: whether the HTTP, SOCKS, or transparent proxy entry is listening correctly, and whether another program is using the port.
• Routing layer: the order in which domain, IP, protocol, and port rules are matched.
• Outbound layer: whether a matched connection uses a proxy node, connects directly, or is blocked.

System proxy scope: why some applications still connect directly

System proxy is not a system-wide traffic capture mechanism. Most browsers read the system settings, but some downloaders, command-line tools, game launchers, and applications with their own network stacks may ignore them. As a result, an application may connect directly to its destination even when the v2rayN tray icon shows that system proxy is enabled.

To determine whether an application has entered the proxy chain, do not rely on node latency alone. Check the core logs, the application’s own proxy settings, and the exit address together. For a command-line tool, explicitly specify an HTTP proxy and make a comparison request. If the logs show a new connection with the proxy specified but not without it, the tool is not using the system proxy by default.

curl --proxy http://127.0.0.1:10809 https://api.ipify.org
curl https://api.ipify.org

Two requests provide a minimal comparison: the first explicitly uses the local HTTP entry, while the second uses the command-line tool’s default network settings. Whether the exit addresses differ depends on the node, current routing, and local network, but a corresponding connection in the core logs directly shows whether the request entered v2rayN. No subscription or node changes are needed after testing.

On Android, v2rayNG and v2flyNG usually receive traffic through the system-provided VPN service, which is conceptually different from a desktop system proxy. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core; both can continue applying routing rules after traffic enters the core. If per-app proxying is enabled, first confirm that the target app is within the selected scope.

What global mode really means: global routing does not capture every connection

Global mode generally means that traffic already inside the core primarily uses the proxy outbound. It is useful for temporarily testing node connectivity: if a domain fails in bypass-mainland mode but works after switching to global mode, the problem is more likely domain classification, DNS results, or rule order than the node itself.

Global mode still has boundaries

“Global” describes the current routing policy; it does not automatically change every application’s networking implementation. Desktop programs that ignore system proxy settings may still connect directly. A client that listens only on a local HTTP or SOCKS entry cannot capture connections that never enter that entry, regardless of the routing preset. Traffic from other devices on the LAN will not automatically pass through the proxy just because this device switches to global mode.

• The local loopback address and LAN addresses should usually remain direct to avoid losing access to printers, router administration pages, or local development services.
• Connections to the node server itself must not be sent back through the same proxy outbound, or a routing loop may result.
• DNS queries may be issued separately by the system, the core, or the application. A routing mode name alone cannot describe the actual DNS exit.
• Existing long-lived connections may not adopt new rules immediately. After switching modes, reopen the target application or establish a new connection.

When to use global mode briefly

After a subscription update, when only some sites fail, a custom rule appears to match incorrectly, or you need to verify that a VMess or VLESS node can establish a connection, global mode provides a useful comparison. It reduces routing branches but cannot fix node parameters, system time, transport settings, or port conflicts. If it still fails in global mode, return to the logs and check the handshake, DNS, and connection timeout details.

1. Choose a node with a healthy status and confirm that the core is running.
2. Enable system proxy, or confirm that the target application has been manually configured to use the local proxy.
3. Switch to global routing, close the target page, and open it again.
4. Record the destination domain, matched outbound, and error type from the logs.
5. Restore the original routing mode, then make the same request once more for comparison.

How bypass-mainland mode works: domain rules, IP rules, and match order

Bypass-mainland mode usually uses domain categories and IP geolocation data to split traffic. Common mainland domains, addresses resolving to mainland ranges, and private network addresses use the direct outbound; other traffic uses the proxy outbound. Client versions, routing data, and subscription-provided configurations may differ, so the same mode name does not guarantee identical rules.

1. Gather destination details first: the core obtains the domain, destination IP, port, network type, and inbound tag from the connection.
2. Check rules in array order: routing rules are generally matched from top to bottom. Once a rule matches, its specified outbound is used and later ordinary rules are not checked.
3. Process the domain and resolved address: some strategies rely directly on domain categories, while others also use the resolved IP to determine the region.
4. Use the fallback outbound: connections that match no earlier rule enter the proxy or direct outbound according to the default rule.

For example, a mainland service may use an overseas CDN, while an overseas service may host static assets on mainland nodes. Relying on IP geography alone can therefore produce an exit different from what users expect. Domain rules are usually better for expressing which route a service should use; IP rules supplement connections without domain names and resolved-address checks. When traffic is misrouted, first confirm in the logs whether the core sees a domain or only an IP address.

DNS can affect the result as well. If an application performs encrypted resolution, the core handles domain resolution, or the system DNS returns a different address, the same domain may match different IP rules. During troubleshooting, avoid changing DNS, nodes, and routing all at once; otherwise it is difficult to identify what caused the change. A safer approach is to change one variable at a time and establish a new connection.

Choose by scenario: everyday use, development, downloads, and mobile networks

For most everyday desktop use, a sensible starting point is to enable system proxy and select bypass-mainland mode. Services in mainland China keep a short direct path, while other traffic enters the proxy according to the rules. Switch briefly to global mode only when rules misclassify traffic, a unified exit is required, or you need a troubleshooting comparison.

Development environments often require additional handling for package managers, containers, virtual machines, and local callback addresses. A browser using the system proxy does not mean the terminal, containers, or virtual machines inherit the same settings automatically. Check the HTTP, HTTPS, or SOCKS proxy variables in each environment separately, and keep internal repositories, local APIs, and loopback ranges on a direct connection.

• Everyday browsing: keep system proxy enabled and use bypass-mainland as the default route; add a precise domain rule only when an individual site behaves incorrectly.
• Rule troubleshooting: use global mode briefly for comparison, retain the logs, then restore the original route.
• Download tools: check the tool’s own proxy menu first; do not rely only on the system proxy icon.
• Local development: explicitly keep localhost, loopback addresses, and the LAN ranges actually in use on a direct connection to avoid sending callbacks on a longer route.
• Android devices: check the VPN connection, routing preset, and per-app scope rather than applying the desktop system proxy concept.

Standard checks before and after switching modes

A reliable troubleshooting process verifies the entry point first, routing second, and the node last. Repeatedly switching among multiple nodes, DNS settings, and modes destroys the value of the comparison. The sequence below works for v2rayN and maps to the VPN, routing, and core-log screens in v2rayNG.

1. Check core status: after starting the client, review the logs to confirm that local listening succeeded and that there is no port-conflict error such as address already in use.
2. Confirm the traffic entry: on desktop, check the system proxy or in-app proxy; on Android, check the VPN service and per-app scope.
3. Use one fixed test node: use a single node throughout the comparison so node differences do not distort the result.
4. Test both routing modes separately: start with bypass-mainland, then switch to global, establishing a new target connection each time.
5. Read the match result: record the destination domain, destination IP, outbound tag, and error type instead of looking only at the latency shown in the interface.
6. Make the smallest change: if traffic is misrouted, add only one precise rule; if the entry point is the issue, change only the application’s proxy settings.

If a program is unaffected by every mode change, first check whether it reaches the core. If it works in global mode but fails in bypass-mainland mode, inspect rule classification and DNS. If both modes fail, return to node parameters, network reachability, system time, and the core logs. This order prevents an entry-point problem from being mistaken for a routing problem.