After you switch your IP, you open a website and check your public address. The number has changed — so does that mean the switch worked? Not so fast. A different public IP only tells you that the address your traffic leaves from has changed. Whether IPv6 moved with it, whether DNS resolution still works, and whether WebRTC is exposing some other public address all still need to be confirmed.
When you use an IP checking tool, don't try to verify everything at once. Confirm the address first, then check the connections, and look at IP quality last. Following that order makes it much easier to work out which part of the chain is actually causing the problem.

Before switching, write down your current public address. Once the switch is done, run an online IP check at ToDetect (todetect.net) and compare the two results.
Three things matter here: whether the IP address changed, whether the country and region match what you expected, and whether the ASN and network type look normal.
Say you were on a network in China and expected a US IP after switching, but the test still shows your old address. That means the route your browser is using probably hasn't changed at all.
If the IP did change but the city doesn't quite match your expectation, that isn't necessarily a fault. IP geolocation relies on third-party databases, and some addresses only resolve to the carrier's city. Check a second source to cross-confirm instead of switching again just because the city name differs.
Plenty of people only look at IPv4 and forget about IPv6. In practice, a single network can hold both public addresses at the same time, and the browser may use different protocols depending on the site you visit.
So once the switch is done, check IPv4 and IPv6 together.
Bear in mind the two formats are naturally different. The question isn't whether the numbers match — it's whether both are leaving through the network path you intended.
If IPv4 has switched but IPv6 still shows your original public address, it's worth looking at your IPv6 configuration. And if your network doesn't use IPv6 at all, there's no point insisting that the test page show an IPv6 address.
Once the public IP checks out, the next thing to verify is whether requests are being routed somewhere else.
Start with the DNS leak test. DNS turns domain names into IP addresses, and most tools show you which DNS servers you're using and which network they belong to.
There's a common misread here: a DNS server sitting in a different place from your public IP doesn't automatically mean a leak. Public DNS providers run servers across many regions. What actually matters is whether the resolvers being detected fit your current network setup.
Then run the WebRTC test. WebRTC is the browser technology behind real-time audio and video, and under certain network conditions it can expose extra IP information.
Look for any unexpected public address. If the results include a local network address or some masked local identifier, that on its own isn't proof of a public IP leak — you have to read it together with the address type.
A successful switch doesn't guarantee a good address. ToDetect's IP purity check and IP risk lookup give you a clearer picture of the address's network properties, reputation, and past records.
| Check | What to look at | How to read the result |
|---|---|---|
| IP risk score | Overall risk level of the current IP | Treat the score as a reference; focus on why the risk is there |
| Network type | Residential, data center, mobile, and so on | Confirm the network type matches what you expected |
| Blacklist record | Whether the IP appears on any public blocklist | If it does, verify where the listing came from and what type it is |
| Abuse history | Spam, malicious requests, or similar reports | Judge by when the record was made and what it was for |
| ASN info | The network the IP belongs to and who runs it | Confirm it's the network you expected |
Keep in mind that different tools draw on different data sources and score things differently, so the same address getting two different ratings is nothing unusual.
IP purity and whether the switch worked are two separate questions. The first is about reputation; the second is judged mainly from the public IP and the actual connection path. Don't mix them up.
Last, take a quick look at your browser fingerprint. Time zone, language, browser version, screen parameters — none of these update just because your public IP changed. So an IP address that doesn't line up with your browser's time zone doesn't automatically mean the switch failed.
For example, someone physically in Asia connecting through a US exit while the browser keeps its original time zone is entirely plausible.
Browser fingerprint checks are better suited to understanding the device environment you're on. They shouldn't be used on their own to decide whether an IP switch took effect.
• If the test still shows the old IP, first confirm the network switch went through, then refresh the page or reopen the browser and test again.
• If IPv4 looks right but IPv6 doesn't, check your IPv6 network configuration first.
• If you see a DNS server you don't recognise, compare it with your system or browser DNS settings — don't judge the problem by the server's location alone.
• If WebRTC reports another public address, confirm whether that address belongs to some other network connection currently active on the device.
One more thing: IP geolocation databases can lag behind. When region details look inconsistent, compare a couple of sources so you don't mistake a database difference for a network fault.
Right away, ideally. If the network setup stays the same over time, you can retest whenever a connection problem shows up or after you change any configuration.
No. IP purity reflects certain reputation traits of the address. Whether the switch worked depends mainly on the public address and the real connection path.
If all you want to know is whether the exit address changed, a public IP check is usually enough. If you also care about DNS, IPv6, and WebRTC connectivity, test each of them separately.
To judge whether an IP switch took effect, keep three things apart: the address change, the network connections, and the quality of the IP. Confirm the public IP first, then look at IPv4, IPv6, DNS, and WebRTC, and only then check IP purity and your browser environment if you need to.
ToDetect (todetect.net) provides online IP checks, IP risk lookup, DNS leak testing, WebRTC testing, and browser fingerprint testing. After switching networks, you can go through the results item by item as needed and keep before-and-after records for comparison.
Rather than staring at a string of IP numbers, knowing what each check actually tells you — and where to look when something seems off — is what lets you judge whether your network is behaving the way it should.
Efficiently solve multi-account management, environment isolation, and account security