System Proxy, Global, or Bypass China? Comparing v2rayN Routing Modes

System Proxy vs. Routing: Entry Point and Outbound Route

In v2rayN, “Set system proxy” and “Global” are separate controls. The first changes the operating system's proxy settings so apps such as browsers that honor them send requests to a local proxy port. The second is the routing policy used by the core after a request arrives. Think of them as an entrance and a fork in the road: without an entrance, changing the fork won't redirect that request.

These steps use the Windows system proxy as an example. Desktop interfaces and proxy integration vary by version and operating system; menu locations depend on the installed version. In the main window, open “System proxy” and select “Set system proxy,” then choose a routing preset separately. A system proxy being enabled does not prove that every request exits through a remote node.

Global, Bypass China, and Blacklist: How Traffic Is Routed

Routing preset names aren't always consistent. Some versions or imported rule sets use “Bypass China”; others call a similar setup “Whitelist.” “Blacklist” usually means that only listed destinations use the proxy. Names describe the intended behavior, but actual routing depends on rule contents, rule order, and the default outbound for unmatched traffic. The comparison below covers common strategies, not a fixed configuration standard tied to any one label.

The key difference between Bypass China and a blacklist is how they handle “unknown” destinations. Bypass China usually sends unknown destinations through the proxy; a blacklist usually connects to them directly. A new service might use separate domains for its homepage, authentication, and static assets. If the blacklist includes only the homepage, the page may load while sign-in fails. That doesn't necessarily mean the node protocol is at fault.

Rule Order and DNS: Why the Same Mode Can Behave Differently

The core checks routing rules in order, and the first match determines the outbound. If a specific domain's proxy exception comes after a broad direct rule, it may never take effect. Handle local network destinations carefully, too: router admin pages, printers, and internal file services usually need direct access, not a remote node.

1. Put specific exceptions first. For example, to proxy full:service.example, place the rule before any general rule that could match the domain.
2. Then add local network and region rules. geoip:private is commonly used to match private IP addresses; geosite:cn and geoip:cn rely on domain and IP data sets, respectively.
3. Check the default outbound last. In common Xray/V2Ray configurations, requests that match no routing rule typically use the first outbound. Check the generated configuration—omitting a rule does not automatically send traffic through the proxy.

The snippet below shows only the routing section to illustrate why exceptions go first. It is not a complete, importable configuration: it assumes the outbounds already include tags named proxy and direct, and that the running core has loaded the relevant data files. The example domain is fictional and does not point to a real service.

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

So if a site in mainland China uses the proxy, the preset hasn't necessarily failed. The domain data may not cover it, the app may have submitted only an IP, or the resolved address may not belong to the mainland China IP ranges. Conversely, a service outside China that uses domains hosted in mainland China may send some requests direct under Bypass China. Routing applies to individual requests—not browser tabs or a site's brand as a whole.

Everyday Setup: Handle Browsers and Standalone Apps Separately

Start with one way to capture traffic and keep the setup simple. For browsers that honor the system proxy, try “Set system proxy” with Bypass China. Command-line tools, games, and download managers may not read system proxy settings, so check their proxy options individually. Consider TUN only when you've confirmed the existing setup doesn't capture enough traffic. Avoid enabling multiple interception methods at once, which makes it harder to tell where a request entered the core.

A subscription provides node details; routing selects an outbound for each request. Updating a subscription usually won't fix incorrectly ordered local rules. If a node is down, all three routing modes may fail. If only one mode fails, check the rules and DNS first. Change one setting at a time and note the original configuration so you can compare results; changing the node, entry point, and routing all at once makes it impossible to isolate the cause.

Controlled Comparison: Test Modes with the Same Node

A speed test can't verify how an app's requests are routed. A latency test may show that one test destination is reachable, but it doesn't prove that browser traffic used the same entry point. Choose a frequently used site in mainland China, a site that requires a proxy, and a local network destination. Keep the node unchanged and record the result in each of the three modes. Don't rely on made-up latency or speed figures; use your local logs and actual requests.

1. Confirm that the core is running. Check the startup logs for listener failures, port conflicts, or errors loading rule data files. If another process is using 10808, fix the entry point first.
2. Test Global first. Start a new request and confirm that the destination works through the current node. If the page is cached, refreshing may not be enough—close the relevant tab or restart the test app.
3. Then test Bypass China. Compare the same destination. If access logs are available, check the destination address and outbound tag. The tag may not be proxy or direct; use the values in your current configuration.
4. Test the blacklist last. Check whether the homepage, authentication endpoints, and asset domains are all on the proxy list. Look for requests that are going direct while others use the proxy.
5. Add only the smallest necessary exception. Prefer an exact domain rule over routing all traffic through the proxy to fix one endpoint. Save it to your regular configuration only after confirming it works.

Existing long-lived connections may not switch outbounds immediately when you change modes, so create a new connection for a fair comparison. Logs may contain subscription URLs, node credentials, or destination details; redact sensitive information before sharing screenshots. For more help tracing a connection, see connection troubleshooting in Advanced Usage. For installation and entry point setup, see Quick Start.

FAQ: What to Check When the Proxy Isn't Working