How IPGet works

Two kinds of tool, and why the difference matters

Every tool on this site is one of two things, and knowing which one you are using changes what its answer means.

A server-side tool asks IPGet's server to do something on the network — resolve a name, open a connection, complete a TLS handshake — and reports what happened. The result describes the internet as seen from one machine in one datacentre. That is exactly what you want when the question is "is this reachable from outside my network", and exactly what you must be careful with when the question is "does this work for everyone".

A browser-side tool reads something your own browser already knows, or computes an answer locally. Nothing is sent to us, there is nothing for us to log, and the answer is about your device rather than about the internet.

The single vantage point, stated plainly

IPGet runs on one server. When it opens a TCP connection, makes an HTTP request or completes a TLS handshake, that traffic leaves from one address, in one place, over one network path. Almost everything that follows is a consequence of that fact.

If a host firewalls our address specifically, the port checker will report a timeout while the service works perfectly for you. If a CDN answers differently by region, the headers we see are the headers served to that region. If a route between our provider and the target is congested, a latency figure describes the congestion rather than the target.

DNS propagation is the deliberate exception. Rather than asking one resolver and presenting the answer as fact, it queries four separate public resolvers and shows each one's response individually, because the disagreement between them is the useful part.

Why some answers are "unknown"

Most diagnostic sites present a confident verdict for every input, because a confident verdict looks more authoritative. IPGet does not, and the difference is deliberate.

The VPN and proxy detector returns one of three verdicts — yes, no or unknown — and attaches a confidence of high, medium or low to the signals behind it. It reaches those verdicts from network registration data: which organisation an address belongs to, whether the range is registered to a hosting provider, whether it appears in public exit-node data. That data genuinely does not always distinguish a consumer connection from a datacentre one, and when it does not, "unknown" is the accurate report.

The same principle runs through the rest of the site. A DNS lookup that fails is reported as a failure, not as "no record" — because "we could not check" and "there is nothing there" lead to opposite conclusions and only one of them is a problem you need to fix. A port that never answers is reported as a timeout rather than as closed, because a silently dropped packet and an actively refused connection are different facts about the host.

What the port checker actually does

It opens a real TCP connection from our server to the address you named, notes what happened, and destroys the socket immediately. It never speaks a higher-level protocol, never sends a payload, never reads response data and never follows anything. It is TCP only — there is no UDP check, and a tool claiming to test UDP from a browser form should be treated with suspicion.

Because the feature makes our server connect somewhere a stranger chose, it is constrained in several ways at once. Targets are resolved first and every resolved address is tested for being publicly routable, so private ranges, loopback and link-local addresses are refused. The connection is then made to the resolved address rather than to the hostname, which closes a DNS-rebinding hole: an attacker who controls a zone could otherwise answer with a public address for the safety check and a private one microseconds later for the connection.

Ports are restricted to a list of 38 commonly probed service ports. That keeps the tool useful for its purpose while making it useless as a general-purpose port scanner — an unrestricted range would turn this into scanner-as-a-service and would get our address blocklisted within days. See the port checker for the list and for what each result state means.

What the SSL checker actually does

It completes a TLS handshake with the host and reads the certificate that was presented. Crucially, it does not abort when validation fails. Aborting would tell you only that something was wrong; reading the certificate tells you which certificate is wrong, which is the thing you need in order to fix it.

So the result separates two questions that are usually collapsed into one. What certificate is this host serving? — issuer, subject, alternative names, validity window, chain. And separately, would a browser accept it? — reported as valid, expired, not-yet-valid, untrusted or hostname-mismatch. A certificate can be fully observable and completely untrusted at the same time, and that combination is the single most common thing people come to the SSL checker to diagnose.

What IP geolocation can and cannot tell you

An IP address is not a location. Geolocation works by looking the address up in a database that maps registered ranges to places, and that database is assembled from registry records, network operator declarations and inference. It is often right about the country, frequently right about the region, and routinely wrong about the city.

The coordinates a lookup returns are usually the centre of a city or region rather than a building, and they should never be read as a street address. A mobile connection may appear hundreds of kilometres away at the operator's gateway. A VPN or proxy shows the exit server's location, which is the entire point of using one. A corporate network may route through a head office in another country. None of these is a bug in the lookup — they are what the underlying data is.

Rate limits, and why they exist

Every endpoint that touches the network is rate limited per client address, and the budgets are deliberately uneven: the tools that make our server do the most work outward get the smallest allowance. A port check costs an outbound connection, so it is limited more tightly than a DNS lookup, which is limited more tightly than reading your own address.

The limits protect the targets as much as they protect us. A diagnostic tool with an open budget becomes a way to probe someone else's infrastructure through a third party, and the people running that infrastructure are entitled not to have that happen. If you need programmatic access, the public API documents the limits per endpoint and returns them in response headers.

What is not stored

There is no query log. A lookup is answered and discarded — the domain you checked, the address you resolved and the port you tested are not written anywhere, so there is nothing to hand over, sell or leak later.

The recent-lookup lists some tools show live in your browser's own storage and never reach us; clearing site data removes them entirely. Analytics, when enabled, record which tool was used and in which language, never what was typed into it, and never an address. The full detail is on the privacy page, which is written to be read rather than to be legally sufficient.

Where the results come from

DNS answers come from real queries to the resolvers listed above, sent from our server at the moment you ask. Port, TLS and HTTP results come from real connections made at that moment. WHOIS data comes from the registry or registrar's own WHOIS service, and its shape varies considerably between top-level domains, which is why some fields are present for one domain and absent for another.

IP geolocation is the one piece of data IPGet does not produce itself: it comes from a third-party provider, and its accuracy is that provider's accuracy. Everything else on the site is a measurement we make, with the limitations described above.