VPN Checker - Detect VPN Connections

Built and tested by Pavel Ahmed · Last updated October 5, 2026

What Is a VPN Checker and What Does It Do?

What does this tool do?

It takes an IP address, either yours or one you type in, and reports the network behind it: the provider name, the organization that holds the address block, the AS number and the approximate location. It then classifies that network as a likely VPN, proxy or datacenter, or as a normal consumer connection, and shows you which detail led to that classification so you can judge it yourself.

Why is this useful?

A VPN is supposed to replace your real IP address with the provider's. If the result still shows your home internet provider while your VPN app says it is connected, the tunnel is probably not carrying that traffic and your real address may be exposed. The same check works in the other direction: if a bank, streaming service or game server keeps blocking you, seeing your IP flagged as a datacenter address explains why, and tells you the fix is to change exit server or switch the VPN off for that site.

Who uses this tool?

• VPN users: to confirm the tunnel is active and that the address websites see has changed, before doing anything sensitive on an untrusted network.

• Remote workers: to check that a work VPN is routing traffic through the company network and not straight out to the internet.

• Site owners and moderators: to see whether an address from their logs belongs to a hosting network, which is useful context when reviewing spam or abuse.

• Support and QA teams: to reproduce what a customer sees when their address is classified as a proxy.

• Anyone being blocked: to find out whether the block follows the IP address rather than the account.

How Do You Use the VPN Checker?

1. Open the page with your VPN off. The tool loads your current IP automatically. Note the provider name and location that appear, so you have a baseline to compare against.

2. Turn your VPN on and connect to the country or server you want to use.

3. Leave the box empty and press Check. The tool reads the address your connection is presenting to the internet right now.

4. Compare the two results. The IP address, provider and location should all have changed. If any of them still match your baseline, your VPN is probably not carrying that traffic.

5. To check someone else's address, type any IPv4 or IPv6 address into the box and press Check. Your own connection is not involved in that lookup.

These are illustrative records, not live lookups. Documentation addresses (RFC 5737, RFC 3849) and the AS number (RFC 5398) have no real registry owner, so each row was worked out from the term list and scan order described below.

How Do You Read the Results?

The result list has six fields, plus one extra line whenever the status is anything other than a plain pass. Each one comes from public registry and routing data about the address, not from anything on your device.

How the VPN Verdict Is Calculated

The verdict comes from a single lookup to our own service at ip.myipshow.com, followed by a scan of the returned network names. The page makes one request and does not merge answers from several sources: it reads one record and reports exactly what that record says. The steps below run in the order the code runs them, and the order is what decides the outcome at every step.

First, the placeholder strings are cleared

The lookup service answers with the literal strings Unknown ISP, Unknown Organization, Unknown AS and Unknown City when it genuinely has no name for a field. Those strings are the absence of an answer, not an answer, and the very first pass removes them along with Not available, Not found, N/A, None and null before anything else reads the record. Left in place, Unknown ISP would be a truthy network name that matches none of the hosting terms, and the page would then announce No VPN or proxy detected about an address it knows nothing about. Clearing the placeholders here, once, means every later step — the status line, the rows, the copied text and the recent-checks list — sees the same emptiness.

Then each field is filled from a fixed list of keys

The upstream response does not use the same key for the same fact in every case, so each field is filled by trying a fixed list of candidate keys in order and taking the first one that survives the placeholder filter. This is the same walk as a fallback chain, not a merge, so one unknown field cannot hide a real name sitting in the next candidate:

• Network provider tries isp, then connection.isp, then connection.org, then org.
• Organization tries org, then organization, then connection.org, then isp. That last entry is why the Organization row can read the same name as the provider row: when the lookup returns only one of the two, the same string fills both, rather than leaving the second blank.
• AS number tries asn, then connection.asn, then as, then connection.as. A bare number — the service sometimes returns 9009 and sometimes AS9009 — is normalised to the AS… form so both rows read the same whichever form arrived.
• AS name / network domain tries as_name, then asname, then connection.domain. This field is scanned by the verdict but is not printed as a row of its own, which is why the matched-term line can name a field you cannot see in the results above it.
• Location is assembled from three separate lookups — city, then region, then country — each with its own fallback list. The country field tries country_name before country, so the row reads Bangladesh rather than BD. A region that duplicates the city is dropped so the line does not repeat the same name twice.

The network names are scanned in a fixed order

Once the three name fields are filled, they are scanned one at a time, in this exact order: the provider name, then the organization name, then the AS name or network domain. The first field that contains any term from the list ends the scan and is reported as the matched field; a match in the provider name therefore always wins over one in the organization, and a name that only appears in the AS field is the last chance. Each field is lowercased first so the match is case-insensitive, and the scan uses a plain substring search rather than a word boundary, which is why m247 matches inside a longer registered name and cloud matches inside Cloudflare.

The order is not cosmetic. On rented infrastructure the provider row usually names the datacenter while the organization row names the VPN brand renting from it, so scanning the provider first means the tool reports the infrastructure the address actually sits on, and the more specific brand name only surfaces when the provider field is generic or empty.

Three outcomes, not two

The status line takes exactly one of three values, and the third branch is what keeps the other two honest:

1. Likely VPN, proxy or datacenter. At least one of the three name fields is non-empty and a term from the list matched somewhere in it. The exact term and the field it matched in are printed underneath, so a decisive hit like nordvpn reads differently from a broad hit like server inside an otherwise ordinary provider's name.
2. No VPN or proxy detected. At least one name field survived the filter and nothing in any of them matched the list. This is a real negative from a real name, not the absence of data.
3. Cannot be judged. None of the three name fields survived the filter, so there was nothing to scan. This branch exists precisely because a blank name would otherwise fall through to the clean verdict and be reported as a consumer connection when the tool in fact knows nothing about the network. The row underneath says so, and the note under the results explains that this is a gap in the registry data rather than a finding about the address.

What is in the term list, and why it causes false positives

The list is maintained by hand and covers about fifty terms, split across four groups rather than ranked by importance: generic infrastructure words such as hosting, cloud, server, datacenter, vps and colocation; network-level words such as vpn, proxy, tunnel and privacy; wholesale hosts and cloud platforms such as digitalocean, ovh, hetzner, leaseweb, m247, aws, azure and google; and consumer VPN brands such as nordvpn, expressvpn, surfshark and mullvad.

Because the scan matches plain substrings, a term on the list can match a name where it means something else entirely. google matches Google Fiber as readily as Google Cloud, and a business whose name contains the word host is flagged on the strength of that word alone. The matched term is printed for exactly this reason: to let you recognise a false positive instead of taking the verdict on trust.

What is deliberately not calculated

Three things this tool could report but does not, because doing so would require a source it does not have or a claim it cannot verify:

• No Tor exit list query. The Tor Project publishes its exit nodes openly at Tor Metrics, but this page does not fetch that list. Many exits are flagged anyway as a side effect of running in datacenters, and that side effect is not the same thing as a Tor check.
• No port scan. The tool does not connect back to the address to look for open proxy ports. Detecting an open proxy needs an outbound connection to the suspect address on the usual proxy ports, which this page does not make.
• No merging of sources on this page. Every figure comes from the one lookup to ip.myipshow.com, which draws on Cloudflare Radar and ipwho.is and may cache a lookup for up to six hours (thirty minutes when no city is found). The page itself has no fallback provider, so when that endpoint is unreachable it says so rather than substituting a result from somewhere else.

For the questions those three omissions leave open, the Proxy Check covers a broader keyword scan, and the IP Address Lookup returns the same underlying registry fields without a verdict attached.

When Would You Use This Tool?

For a step-by-step version of the before-and-after test, see How to Check If Your VPN Is Actually Working, and if the location never changes, Why Is My VPN Not Changing My Location?

How Do the Detection Methods Compare?

Detection methods differ in what they can see, and none of them observes the tunnel itself. The first table below sets out the signal each method uses, what it is good at, and where it fails. This tool uses the first row only.

What Other Tools Work With This One?

Sources and Further Reading

• RFC 1930: Guidelines for creation, selection, and registration of an Autonomous System (AS). Defines what an AS number identifies.
• RFC 5737, RFC 3849 and RFC 5398: IPv4 and IPv6 address blocks and AS numbers reserved for documentation, used in the examples above.
• Tor Metrics: the Tor Project's published relay and exit data, which this tool does not query.
• About iCloud Private Relay (Apple Support): how Apple's relay service routes Safari traffic. Availability varies by country.

Frequently Asked Questions