--- title: "Browser Environment Check Explained: IP, Leaks, Fingerprints" description: "How to read each module of the cdnping /ip browser environment check: IP geolocation, DNS and WebRTC leaks, IPv6, fingerprints, and automation flags." url: https://cdnping.org/en/blog/browser-environment-check-explained language: en published: 2026-10-20 category: "IP & privacy" tags: ["browser environment check","privacy self-check","DNS leak","WebRTC","browser fingerprint"] source: cdnping.org license: Free to quote and summarize with a link to the url above. --- # Browser Environment Check Explained: IP, Leaks, Fingerprints A browser environment check lists everything a website can see at the moment you open its page: where your exit IP comes from, which path your DNS queries take, whether WebRTC exposes a second address, what your system time zone and language are, and whether the browser looks like it is being driven by a script. When you read the results, don't fixate on a total score. Look for the items that contradict each other. Those inconsistencies point to the parts of your network setup or privacy settings that need attention. This article walks through the modules on cdnping's [IP and environment check](/en/ip) page in order, explaining what each one tests, what a normal result looks like, and what an anomaly means. The goal is privacy self-checking and troubleshooting: find out what you are exposing, then decide whether to fix it. It does not cover how to fake an environment to get around any platform's risk controls or regional restrictions. That usually violates terms of service and is not what this tool is for. ## What does an environment check look at? The checks on the /ip page fall into three layers: | Layer | Modules | Question it answers | | --- | --- | --- | | Network exit | Multi-database geolocation, RDAP registration data, native/broadcast, IP type, purity | What IP does a website see, and what is its origin and reputation? | | Routing and leaks | Mainland China split routing, multiple exits, DNS leak, WebRTC leak, latency profile, IPv4/IPv6 | Do different requests take the same path, and does any address leak out through a side channel? | | Browser and device | Engine version inference, time zone/language/fonts, hardware fingerprint, automation traces | Is the information the browser reports about itself consistent? | Fingerprint checks are computed locally in your browser and the results are not uploaded. The page can produce a watermarked result image, and you can hide your IP before sharing it. For where cdnping's data comes from and how it is measured, see [Methodology](/en/methodology). ## How do I read the exit IP group? ### The geolocation databases disagree. Which one is right? /ip queries the same IP against 11 geolocation databases and gives a location and confidence level based on a vote. These databases draw on registration records, route announcements, and each vendor's own collection, and they update at different speeds. Disagreement is common, especially for address blocks that recently changed hands. How to read it: when confidence is high and most databases agree, you can treat the result as the location most websites will assume. If the votes are scattered, the IP may land in different countries or cities depending on the site. If you later run into "the page language changed for no reason" or "I'm being asked for extra verification," come back to this item first. ### How do RDAP data and "native IP / broadcast IP" relate? RDAP returns what the regional internet registry has on file for the address block: who holds it and which country it is registered in. If the registered country matches the usage location voted on by the geolocation databases, it is generally called a native IP. If it is registered in country A but announced through routing and used in country B, it is what people call a broadcast IP. Neither is better or worse. It only affects how some websites judge where you are. For details, see [Native IP vs. broadcast IP](/en/learn/native-ip-vs-broadcast-ip). ### What do the IP type and purity score tell me? IP type is one of four categories: datacenter, residential, mobile, and Tor. The exit of a cloud server is usually labeled datacenter. That describes the block's purpose and ownership. It is not a penalty. For how websites see the two types differently, see [Datacenter IP vs. residential IP](/en/blog/datacenter-ip-vs-residential-ip). The purity score aggregates 14 reputation sources, including ip-api, proxycheck, IP2Location, StopForumSpam, Tor exit lists, a hosting ASN list, and several DNS blocklists. Each hit is shown with its weight, so don't look only at the final score. A hit on "hosting ASN" means something very different from a hit on "spam blocklist." The criteria for each source and its false-positive cases are covered one by one in [How the IP purity score is calculated](/en/blog/ip-purity-score-explained). ## How do I read the routing and leak group? ### What do the three mainland China split-routing results mean? The page reads the client IP and latency reported back by CDNs of Chinese sites such as NetEase, Tencent, Douyin, Weibo, Youku, and Xiaohongshu, and compares them with your overseas exit. There are three possible conclusions: - **Direct domestic connection**: Chinese sites and overseas sites see the same Chinese IP. - **Mainland split routing**: Chinese sites see a Chinese IP and overseas sites see a different exit, meaning your proxy or network routes traffic by destination. - **Global proxy**: Chinese sites also see the overseas exit, so domestic traffic takes a detour. If you thought split routing was on but the result says global proxy, that explains why Chinese websites load slowly. For the mechanism, see [How Chinese sites see your real IP](/en/blog/how-chinese-sites-see-your-real-ip). For the concept of split routing itself, see [What is split tunneling](/en/learn/split-tunneling). ### Why does multi-exit detection look at Claude, ChatGPT, and Grok separately? The page reads the Cloudflare trace under each of these services' domains to see which IP you exit from when you visit that domain. If your proxy rules assign different nodes by domain, several exits will show up here. Multiple exits are not an error in themselves. But if you expected them to match and they don't, your rules contain a match you hadn't noticed. ### How do I tell a DNS leak or WebRTC leak? DNS leak: the page records which recursive resolver is resolving domain names for you. If your traffic goes through a proxy but DNS queries still go to your local ISP's resolver, the ISP can still see which domains you visit. That is a leak. The usual fix is to enable encrypted DNS in the browser or system; see the [DNS over HTTPS setup guide](/en/blog/dns-over-https-setup-guide). WebRTC leak: to set up peer-to-peer connections, WebRTC collects the address candidates available on your machine. If the public address the page obtains through WebRTC differs from the exit seen by HTTP requests, your real address can be read by any web page script. For how to turn it off in each browser, see [How to fix a WebRTC leak](/en/blog/fix-webrtc-leak-chrome-firefox-safari). For a comparison of how the two leaks work, see [DNS leak vs. WebRTC leak](/en/learn/dns-leak-webrtc-leak). ### How does the "latency profile" spot a relay? The page gets two numbers at once: the round-trip time from your browser to the server, and the TCP round-trip time Cloudflare measured from the server to your exit IP. On a direct connection the two should be close. If the browser round trip is clearly larger than the exit round trip, the extra time is usually spent on a relay link between you and the exit. This result can explain "the exit is close to the target, but it feels slow in practice": the slow part may be between you and the exit, not between the exit and the target. ### What if my IPv4 and IPv6 exits differ? On a dual-stack network, the browser tries IPv6 first. If your proxy only takes over IPv4, IPv6 traffic goes straight out through your local ISP. The result is an IPv4 exit overseas and an IPv6 exit in China. For troubleshooting steps, see [IPv6 proxy not working](/en/blog/ipv6-dual-stack-proxy-mismatch). ## How do I read the browser and device group? ### What does it mean when the inferred engine version doesn't match the User-Agent? The User-Agent is a string the browser reports about itself, and extensions or settings can rewrite it. /ip uses 23 features to infer the actual engine version (for example, whether an API introduced in a particular version exists). When the two disagree, common causes are an extension that modifies the UA, a wrapper browser built on an older engine, or a browser that hasn't been updated in a long time. For ordinary users, the most practical response is to update the browser to the latest version and review which extensions you have installed. ### What happens when time zone, language, fonts, and IP location don't match? These three come from system settings: the time zone from the operating system, the language from browser preferences, and the font list from the software you have installed and the system language. A mismatch with your IP location is perfectly normal, for example when traveling, using a proxy, or running an English-language OS. What you should know is that the combination itself is also an identifiable trait. For what each item exposes, see [Browser fingerprint and environment check: when time zone, language, fonts, and IP don't match](/en/blog/browser-environment-consistency). ### What counts as a hardware fingerprint? These fingerprints typically include Canvas and WebGL rendering output, the GPU model string, CPU core count, memory tier, and screen resolution. Any single item has limited discriminating power, but combined they can tell devices apart to a considerable degree. The page shows these values so you know any web page script can read them. They are computed locally and not uploaded. ### The "automation traces" item flagged something. Is my computer infected? Generally no. This item checks for signs that the browser is controlled by an automation framework, such as flags like `navigator.webdriver` and properties left behind by the debugging protocol. Running your own test scripts, using a browser extension with automation capabilities, or having launched the browser with a remote debugging port can all trigger it. If it fires during everyday browsing, disable all extensions and test again, then re-enable them one at a time to find which one is responsible. ## A self-check order you can follow Once you have results, work through them in this order, because earlier problems affect how you read later ones: 1. Check leaks first. If either the DNS leak or WebRTC leak is abnormal, fix it using the links above, then refresh /ip and test again. While a leak is unfixed, none of the exit conclusions below are reliable. 2. Then check IPv4/IPv6. If the two exits are in different regions, confirm whether your proxy handles IPv6, or temporarily turn IPv6 off in the system and test again. 3. Verify split routing and multiple exits. Confirm that "mainland split routing / global proxy / direct domestic connection" matches what you expect, and that the multi-exit results match your proxy rules. 4. Look at the latency profile. If the browser round trip is far larger than the exit round trip, the problem is on the relay link. Before switching nodes, confirm that your local network isn't simply slow. 5. Review the exit IP intelligence. If the geolocation databases disagree widely or the purity check has many hits, note the specific sources that hit and decide whether each is a factual description such as "datacenter attribute" or a record that deserves attention, such as an abuse blocklist. 6. Finish with the browser layer. If the engine and UA disagree, update the browser and clean up extensions. If automation traces fire, disable extensions one by one and retest. Retest after each change, and use the page's screenshot feature (which can hide the IP) to save before and after results for comparison. If you are troubleshooting a development environment's network, you can continue with the [online speed test](/en) on the cdnping home page to measure first-connection and round-trip times to AI APIs and CDNs. The full procedure is in the [Developer network self-check checklist (2026)](/en/blog/developer-network-self-check-2026). ## What are the limits of these results? - They only represent this one moment and this one browser. Switching browsers, changing networks, or toggling a proxy will change the results. - Geolocation and reputation databases lag. After an IP changes hands, it can take a while for the databases to converge. - No single result can tell you how a particular website will treat you. Each website uses different data sources and rules. /ip lists publicly available signals, not any platform's internal verdict. - Consistent does not mean anonymous. If every item is normal, it only means your setup has no obvious hole. Browser fingerprints can still tell devices apart. cdnping is a free network observation site for developers. It has a commercial partnership with AGI Plan, has no login, and does not sell data.