How Chinese Sites See Your Real IP: Split-Tunnel Detection Explained

Blog / IP & privacy

How Chinese Sites See Your Real IP: Split-Tunnel Detection Explained

If your network setup routes Chinese domains directly (bypassing the proxy), then any Chinese website you visit sees the mainland exit IP of your home broadband or mobile network. The proxy plays no part in that leg. Any web page can send a background request to a Chinese CDN, read that mainland IP back, and compare it with the exit IP it sees itself. That tells the page whether you are in "mainland split" mode. The split-tunnel check in cdnping's IP and environment test does exactly this.

This article explains why the mechanism works, what each of the three results means, and how to verify it yourself.

Why split routing gives you two exits

With rule-based split routing, the client decides per connection, by domain or IP range, how traffic leaves your machine: overseas domains go through the proxy, and Chinese domains go direct. Chinese sites don't get slowed by a detour, but your device now has two exits at the same time.

Say you open a page hosted overseas, such as cdnping.org:

  1. The browser requests cdnping.org. That connection goes through the proxy, so the cdnping server sees the proxy's exit IP.
  2. A script on the page then sends a request to some Chinese CDN address. That domain matches the "direct" rule, so the connection leaves from your local network.
  3. The Chinese CDN node sees your mainland exit IP.

Two servers see two different IPs. If the Chinese side is willing to return the IP it saw to the browser, the page ends up with both values. For how the routing configuration itself works, see our split tunneling explainer.

How a Chinese CDN hands your IP to the browser

The CDN already knows your IP

Once a TCP connection is established, the server necessarily knows the peer address, or it couldn't send a reply. When a CDN node forwards a request to the origin, it usually also writes that address into a request header so the origin knows who the visitor is. So the fact that a Chinese provider knows your IP is nothing new. It's true of every website you visit.

The key question is the next step: can a third-party web page read that IP?

Echoing the client IP in the response body or headers

Some Chinese CDNs and edge services expose endpoints for diagnostics, traffic scheduling, or speed testing, and these include the client IP in the response. There are two common forms:

  • In the response body, for example a JSON or plain-text reply containing the visitor's IP.
  • In a response header, for example a field like X-Client-IP (the name is only an example; each vendor names it differently).

These endpoints are usually meant for troubleshooting, such as letting an ops engineer confirm which node a user was routed to. But once they are publicly reachable, anyone who sends a request can read the result.

CORS decides whether a web page can read it

Browsers enforce the same-origin policy: a script on cdnping.org that requests another domain cannot read the response by default. Whether it can depends on the CORS headers the other side returns:

Response headerPurposeEffect on detection
Access-Control-Allow-Origin: * or one that includes the requesting originLets cross-origin scripts read the responseWith it, an IP in the response body can be read
Access-Control-Expose-HeadersLists the non-standard response headers scripts may readIf the IP is in a custom header, it must be listed here or the script can't get it
NeitherThe script can't read the contentSuch an endpoint can't be used to read the IP; you only learn whether the request completed and how long it took

The Chinese CDN echoing the IP is the precondition, and CORS permission is the condition. An address that satisfies both becomes a "what is my mainland IP" lookup that any web page can call.

Latency is the second piece of evidence

Timing alone carries information. A direct round trip to a Chinese CDN is typically tens of milliseconds; if the request first leaves China and comes back, the round trip is noticeably longer. cdnping's check also records latency to these Chinese nodes and uses it to corroborate the IP results, so it doesn't rely on any single endpoint's response.

How cdnping's mainland split check reaches a verdict

The mainland split check on the /en/ip page sends requests to Chinese CDNs run by NetEase, Tencent, Douyin, Weibo, Youku, Xiaohongshu, and others. It reads the client IP and latency each one returns, compares them with the exit IP cdnping itself sees, and gives one of three conclusions:

ResultIP seen by Chinese CDNsIP seen by cdnpingLatency to Chinese nodesMeaning
Mainland splitMainland IPOverseas IPLowChinese traffic goes direct, overseas traffic goes through the proxy; two exits at once
Global proxyOverseas IPOverseas IPHighAll traffic goes through the proxy, including visits to Chinese sites
Direct (no proxy)Mainland IPMainland IPLowNo proxy in use, or the proxy isn't taking over browser traffic

What "mainland split" means

Overseas services see the proxy's exit, and Chinese services see your broadband or mobile exit. A single page in a single browser can read both IPs. From a privacy standpoint, "using a proxy" does not mean "websites can't know your mainland IP."

What "global proxy" means

The Chinese CDNs also return an overseas IP, and latency to Chinese nodes is high, which means even visits to Chinese sites are detouring abroad. Chinese sites then see the proxy exit. The cost is slower access to Chinese services, and some of them may ask for extra verification because of the overseas IP.

What "direct" means

Both sides see a mainland IP. With no proxy running, that's the normal result. If you think your proxy is on, check whether it is actually taking over the browser: the system proxy may not have taken effect, a browser extension may be disabled, or the current network may bypass your settings.

What if different CDNs disagree?

Sometimes the Chinese CDNs don't agree, for example most return a mainland IP while one or two return an overseas IP. Common causes are split rules that cover only some Chinese domains, or a domain that resolves to an overseas node. In that case, looking at each CDN's IP and latency individually is more useful than looking at the overall verdict.

Hands-on: run a check and generate a result image

In the browser

  1. Open cdnping.org/en/ip and wait for all checks to finish.
  2. Read the mainland split verdict, plus the IP and latency each Chinese CDN returned.
  3. Compare against the table above and see whether everything is consistent.
  4. The same page also has DNS leak and WebRTC leak checks. These are two other paths that can expose mainland network information.
  5. To send results to a colleague or paste them into a ticket, use the result-image feature on the page to export a watermarked image. With the hide-IP option turned on, IP addresses are not shown in the image, so it is safe to share publicly.

On the command line

You can verify the same mechanism with curl. First look at your current overseas exit:

# Cloudflare's trace endpoint returns the client IP it sees (the ip= line)
curl -s https://www.cloudflare.com/cdn-cgi/trace | grep '^ip='

Then check whether an endpoint's CORS headers allow cross-origin reads (replace the URL with the one you want to inspect):

# Send an Origin header to simulate a cross-origin GET and print only the response headers
curl -s -o /dev/null -D - -H "Origin: https://example.com" "https://<要检查的地址>" \
  | grep -i -E 'access-control-allow-origin|access-control-expose-headers'

If Access-Control-Allow-Origin comes back and the IP appears in the response body or in an exposed header, any web page can use that endpoint to read your exit IP. Whether terminal traffic goes through a proxy depends on the terminal's own proxy settings, which may differ from the browser's. If the command-line result doesn't match the browser result, first confirm that both are taking the same path.

Self-check list

  • I know which mode I'm in: mainland split, global proxy, or direct
  • All the Chinese CDNs agree, with no domain slipping through
  • The resolver shown in the DNS leak test is the one I expect
  • The WebRTC test doesn't expose a local or mainland public address
  • Hide IP was turned on before sharing the result image

What it means for privacy when one page reads both exits

A web page that gets both your overseas exit and your mainland exit can link the two addresses, and it needs no permission prompt to do so. For most people this may not be a problem, but you should know it can happen.

IP is also not the only signal. Time zone, language, fonts, and latency patterns all reflect your network environment, and the /en/ip page shows these items together so you can see the whole picture. Fingerprints are computed locally and are not uploaded.

cdnping's checks only tell you the current state; they don't provide ways to get around any platform's detection. When using overseas AI services, follow each service's terms and local regulations, and treat regional restrictions honestly.

If you use coding tools like Claude Code or Codex from mainland China and need APIs billed in RMB, take a look at AGI Plan. AGI Plan is a commercial partner of cdnping. AGI Plan is a multi-provider LLM aggregation gateway, and it states clearly that it is not an officially authorized channel.

Next steps

  • Run a check at /en/ip, export a result image with the IP hidden for your records, then run it again after you change networks or settings and compare.
  • To find out whether your exit is a native IP or a broadcast IP, read native IP vs. broadcast IP.
  • If an AI service won't connect during a check, first look at Is it down? and API status to see whether the service itself is the problem, then troubleshoot your own network.

Related articles

Keep reading