IP Check

See every exit IP at once — mainland, international, Cloudflare edge and server-side viewpoints probed in parallel with an automatic split-routing verdict, cross-checked across five geo providers, plus WebRTC / timezone / IPv6 leak checks.

See every exit IP you have at once. A plain IP lookup tells you one address, but with a proxy, VPN or split-routing rules in play, mainland sites, international sites and Google may each travel a different path. This tool probes four viewpoints in parallel — a mainland-China source, an international source, the Cloudflare edge (which reveals the actual edge node you reach) and Zapbox’s own server — then reads the result for you: all four matching means no split routing; mainland differing from international means your rules are working. Below that, the same IP is cross-checked against five geolocation providers, which frequently disagree (one says Hanoi, another Ho Chi Minh City, and the ISP names differ too) — and whichever provider a website uses is the one judging you. Finally the checks proxy users actually care about: whether WebRTC leaks your real IP around the proxy, whether your browser timezone contradicts your IP, and whether IPv6 is going direct while only IPv4 is proxied. Everything runs in your browser.

How to use

  1. Opening the page probes all four viewpoints in parallel; each card renders as soon as it answers, so a slow or blocked endpoint never holds up the others.
  2. Read the verdict at the top: no split routing, split routing active, or which endpoints were unreachable.
  3. Scan the cross-check table — highlighted cells are where the providers disagree.
  4. Work through the leak checklist and act on any red or amber item; hit “Copy report” to paste the whole picture to someone else.

FAQ

Why would the four viewpoints show different IPs?
Because you are splitting traffic. Proxy clients (Clash, Mihomo, Shadowrocket…) are usually configured to send mainland traffic direct and international traffic through the proxy, so a mainland provider sees your real ISP address while an international one sees the proxy exit. Confirming that at a glance is the whole point of this tool. If all four agree, nothing is being split right now.
What is the “edge node” on the Cloudflare card?
It is the code of the Cloudflare data centre you actually reached (HKG = Hong Kong, NRT = Tokyo, LAX = Los Angeles…). That reflects your real network position better than a GeoIP lookup, which is a database that can be stale or mislabelled — the edge node is where the routing actually landed. If the IP claims one country but the edge node is on another continent, the geo data is likely wrong or the route detours.
Why do providers disagree about the same IP, and which is right?
Each provider collects and infers its data independently, and freshly allocated ranges, cloud ranges and IPs used across regions are especially inconsistent. There is no single correct answer — **it depends which provider the site you care about uses**. That is how to read this table: if one provider places you somewhere unhelpful and your target site happens to use it, that is how you will be judged. Handy for localisation testing and fraud-check debugging.
Why is there no DNS leak test?
Because we cannot do it honestly. A real DNS leak test needs an **authoritative DNS server**: a unique subdomain per test, NS delegation pointing queries at your own server on UDP 53, then observing which resolvers show up. Our deployment (a Railway container) cannot provide that. Rather than ship a check that looks real but measures nothing, we say so plainly: use dnsleaktest.com or bash.ws for that. Same for ping / traceroute / speed tests — browsers have no raw sockets, so there is no honest ICMP to be had.
Is my IP uploaded or logged?
Your browser talks **directly** to the public APIs (ipip.net, ipwho.is, Cloudflare, ipinfo.io, ip.sb, bigdatacloud) — those requests never pass through our servers, though your IP is naturally visible to those APIs (seeing it is how they answer). The only card that touches us is “Zapbox server”, whose entire purpose is to show what we see; we store nothing, and our analytics records the route only, never an IP. The WebRTC, timezone and language checks are fully local with no requests at all.
Does “no WebRTC leak detected” mean I am safe?
Not quite. Chrome hides local addresses behind mDNS names (xxxx.local) by default, so often nothing concrete shows up even with WebRTC enabled — “not detected” means nothing surfaced this time, not that WebRTC is off. To actually rule it out, disable WebRTC in your browser settings or via an extension, then re-run the check.

Related tools