V2Ray System Proxy Modes: Global Proxy vs. Bypass China

At a glance

System proxy settings determine whether an app sends connections to a local proxy port. Global and bypass-China modes determine which outbound route the core uses for connections it receives. For everyday browsing, start with “Automatically configure system proxy” and bypass-China routing; switch to global temporarily when troubleshooting routing. This guide uses v2rayN on Windows to walk through checking ports, testing with command-line tools, and reading logs—so you don’t mistake “proxy enabled” for “all traffic goes through the node.”

System Proxy vs. Routing: Two Separate Settings

First check whether a connection reaches the core; then check how the core chooses an outbound. v2rayN is the client interface for managing nodes, starting the core, and configuring the system proxy. The V2Ray or Xray core receives connections, applies routing rules, and connects to servers. A subscription provides node details; it does not enable the system proxy or guarantee that every app will use one.

Entry point: System proxy

Applies to: Apps that follow system proxy settings
Local address: 127.0.0.1
Example port: 10808; use the port actually listening on your system
What it does: Sends app requests to the local proxy listener

If an app ignores the system proxy, changing the routing mode won’t send it through the core.

Exit route: Core routing

Applies to: Connections that have already reached the core
Matching criteria: Domain names, IP addresses, ports, and more
Global mode: Typically sends ordinary destination traffic through the proxy outbound
Bypass China: Routes matching destinations in mainland China through the direct outbound

Mode names are just presets; actual behavior depends on the routing rules they generate.

For example, a browser that follows system proxy settings first connects to 127.0.0.1:10808 on your computer. The core may then connect directly to sites in mainland China and send other traffic through the node. The browser is using the local proxy, but not every connection passes through the remote server. That’s why “system proxy enabled” and “the site still uses my local network egress” can both be true.

Global Proxy vs. Bypass China: Which Should You Use?

For everyday access to a mix of sites in and outside mainland China, start with bypass-China routing. If you suspect a domain is being sent direct by mistake, switch to global temporarily for comparison. Global routing is not network-adapter-level traffic capture or a speed boost. It won’t take over apps that ignore the system proxy, nor guarantee that games, voice calls, or other UDP traffic use the same entry point.

Bypass-China routing

Recommended

Services in mainland China usually connect directly; other destinations follow the preset routing rules. This can avoid detours for domestic connections, but depends on domain and IP rule data. Missing classifications, outdated data, or rule-order issues can lead to incorrect routing.

Best for: everyday browsing, working with services in mainland China, and researching sources abroad.

Global routing

Sends ordinary destination traffic that reaches the core through the proxy outbound, making it easier to rule out routing rules as the cause. Sites in mainland China may also take a longer route through a remote server, affecting latency, regional access, and login risk checks.

Best for: brief troubleshooting, checking your proxy egress, or apps that need a consistent exit route.

Direct routing

Requests may still pass through the local core before connecting to the destination directly over your local network. This is useful for establishing a network baseline, but direct routing is not the same as clearing the system proxy.

Best for: comparing local network reachability and isolating node-related issues.

“Bypass China” does not mean the client checks the real-time location of every server and sends anything physically located in China direct. The core typically matches traffic against rule data rather than looking up each destination’s physical location. Regional CDNs, different DNS answers for the same domain, and apps that connect directly to IP addresses can all affect classification. To check whether LAN traffic goes direct, verify that the preset includes private-address rules; don’t infer it from the mode name.

Configure v2rayN: Check the Entry Point, Then Set Routing

These steps use the common v2rayN 7.x interface. Fields may vary across minor versions, layouts, and core combinations. Check the port in your current configuration instead of copying 10809 from an older guide. Configurations may provide either a mixed listener or separate HTTP and SOCKS listeners; the same port number does not mean the same protocol.

Select a node

In the main window’s node list, select the node, right-click it, and choose “Set as active server.” Make sure the node comes from a valid subscription or existing configuration and that the core starts successfully. Whether the protocol is VMess, VLESS, or another type does not change how to diagnose the separate entry-point and routing layers described here.
Check the port

Go to “Settings” → “Parameters,” then check the local listening port and listener protocol. Note the actual values. The examples in this guide use 10808, which applies only if that port provides SOCKS or the relevant mixed listener. After saving changes, make sure the core has restarted with the new configuration.
Enable the entry point

In the “System proxy” menu at the bottom of the main window, choose “Automatically configure system proxy.” You can also right-click the tray icon, open “System proxy,” and choose the same option. “Automatically configure” means the client sets the system proxy; it does not mean PAC-based routing.
Set the routing mode

Choose the bypass-China preset from the “Routing” menu at the bottom of the main window. Check whether the preset also meets your needs for direct LAN access. For comparison, switch to “Global” in the same menu without changing the node or DNS at the same time.
Reconnect

Close and reopen the target page, or restart the app if needed, so it doesn’t keep using an existing connection with the previous outbound. Check the destination address and outbound tag in the logs. After switching back to your usual preset, test one destination in mainland China and one outside it.

Browser Works, Command Line Doesn’t: Test with an Explicit Proxy

A successful browser connection only shows that the browser’s connection path works. Command-line tools may read environment variables or ignore desktop system proxy settings entirely; apps may also have their own proxy settings. Specify the proxy address explicitly to avoid uncertainty about which settings a tool is using.

# SOCKS test: resolve the destination domain through the proxy
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

# Direct-connection comparison: explicitly bypass proxy settings
curl --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com/

In Windows PowerShell, write curl.exe instead of curl at the start of the command to avoid parameter differences caused by the same-name alias in older environments. The 10-second value is the connection timeout; 20 seconds is the total request timeout. Neither is a performance measurement. An HTTP error from the destination can still mean the connection was established, so the status code alone does not prove the node is down.

What you see	Check first	Next step
Explicit proxy works, browser fails	Whether the browser uses the system proxy or has its own proxy settings	Check the system proxy address, restart the browser, and test again
Immediate “connection refused” error	Nothing is listening on the local port, or the port is incorrect	Check the core startup logs and verify the listener protocol and port
Local listener connects, but the destination request times out	The node, server connection settings, remote DNS resolution, and destination reachability	Keep routing unchanged and compare with a known-working node
Global works, bypass-China fails	The domain or IP is routed direct, but the direct connection path is unavailable	Check the matching rule and add a more specific proxy rule for the destination

socks5h sends the destination domain to the proxy for resolution; that differs from resolving it locally first. However, proxy-side resolution does not guarantee that the domain lookup itself goes through the remote node. That depends on the core’s DNS and routing configuration. To test an HTTP listener, use --proxy http://127.0.0.1:10808, provided the current port supports HTTP proxying.

How Bypass-China Rules Match: Domains, IPs, and the Default Outbound

Routing rules are checked in order; usually, the first matching rule determines the outbound. Put specific exceptions before broader rules. The V2Ray/Xray-style routing snippet below illustrates the intent to “send private addresses direct, send mainland China domains and IPs direct, and proxy everything else.” It is not a complete, ready-to-run configuration.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

direct and proxy are outbound tags and must match entries in the full configuration’s outbounds. The names alone do not create direct or proxy functionality.
geosite:cn and geoip:cn require rule data available to the core. Missing data can cause loading failures, and the contents of the data affect classification results.
IPIfNonMatch means the core can resolve a domain to an IP and try IP rules if no domain rule matches. The resulting address may change the routing path and add DNS lookup overhead.
The final rule explicitly catches TCP and UDP connections. Without a catch-all rule, unmatched connections usually use the first outbound; don’t assume they will use the proxy.

When using v2rayN routing presets, manage rules in the client’s routing settings instead of pasting this snippet into a generated runtime file. The client may regenerate that file when it restarts or switches configurations. Sniffing can supply domain information for some connections, but it cannot reliably recover domains for every direct-IP connection and should not be the only fix for routing problems.

Desktop Browsing and Standalone Apps: Configure Each Entry Point

Recommended setup: Configure the entry point per app, then verify routing consistently

Apps that follow system proxy settings

Enable “Automatically configure system proxy” and start with bypass-China routing.
Use a new browser connection to test a destination in mainland China and one outside it.
If one site behaves unexpectedly, switch to global temporarily for comparison, then adjust the rules.

Apps with their own proxy settings

Enter 127.0.0.1 and the actual listening port in the app.
Select HTTP or SOCKS5 explicitly; don’t copy a port number without checking the protocol.
Test command-line tools with explicit proxy options first, then decide whether to set environment variables.

System proxy settings determine the app’s entry point; routing determines its exit. Consider TUN mode separately if you need to capture a wider range of traffic.

TUN mode captures eligible traffic through a virtual network interface, which works differently from a standard system proxy. It involves system routes, permissions, DNS, and bypass settings. Don’t make TUN your first fix just because a command-line tool ignores the system proxy. Testing with explicit proxy options makes the issue easier to isolate.

On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Capturing traffic through the system VPN interface works differently from Windows system HTTP proxy settings; check per-app scope and core routing separately. Don’t apply desktop steps to Android unchanged: similar mode names do not mean the entry points work the same way.

FAQ: Global Mode Not Working, No Internet After Exit, and Routing Issues

Why do some apps still use my local connection when global mode is selected?

First check whether the app’s connection reaches the local listener. Test the same destination with an explicit proxy command; if that works, check the app’s own network settings. Global routing only handles connections that reach the core. Apps that ignore the system proxy are not automatically captured when you switch to global.

Why can’t my browser connect after I close v2rayN?

The system may still be pointing to a local port that is no longer listening. Restart v2rayN, choose “Clear system proxy” in “System proxy,” then exit normally. In Windows, you can also check manual proxy settings under “Settings” → “Network & Internet” → “Proxy.” Follow your existing network requirements for organization-managed proxy settings.

Sites fail with bypass-China but work in global mode. How do I fix this?

Keep the node unchanged, note the domain that fails, and check the outbound tag in the logs. If a direct rule matches it, add a proxy exception for that domain before the broader direct rule. Reconnect the app and test again; there’s no need to leave all everyday traffic in global mode.

Sites in mainland China slow down in global mode. Should I switch protocols?

Switch back to bypass-China and test the same page with a new connection. If direct access works again, the detour is more likely the problem than VMess or VLESS. Change only the routing mode at a time; changing the protocol, node, and DNS together makes it difficult to identify the cause.

Does enabling the system proxy guarantee that DNS queries go through the node?

No. An app may resolve domains itself, a browser may use Secure DNS, and the core may have its own DNS policy. First distinguish the connection path from the DNS resolution path, then check the browser’s DNS settings and the core’s DNS configuration. The system proxy toggle or exit IP alone cannot prove how DNS was resolved.

Base your conclusion on three checks: whether the local listener is working, whether the destination connection reaches the core, and which outbound the logs select. An exit-IP lookup reflects only that particular request; it says nothing about all traffic on the device. Troubleshooting in the order “entry point → routing → node” is more reliable than repeatedly switching modes.