Methodology

Evidence labels

OBSERVED: seen directly by your browser or by one of our measurement servers. A server observation (for example the address it saw) is stronger than a browser timing.

REPORTED: stated by you or by an outside data source, such as an IP database or a provider's documentation.

INFERRED: derived by a named, versioned rule from named evidence.

UNKNOWN: not measured, not enough evidence, or not possible from a website.

What a website cannot see

No website can read your IMSI, ICCID, APN, cell tower, active eSIM profile or the route inside the mobile core. An ASN identifies the visible IP network, not necessarily the seller, SIM issuer, local operator or roaming partner. GeoIP is a database estimate, not proof of where a gateway is.

Visible identity

Each measurement server determines the source address of your request from its own socket. Forwarded headers are only trusted from our own reverse proxy. The server enriches the address locally with IP databases (DB-IP Lite for network and city, IPinfo Lite when configured), checks Apple's published Private Relay egress list, and returns a signed receipt without the raw address (only a pseudonym that is valid within this one test). Your browser shows the raw address to you only.

How we determine the route

The server looks up which network owns the address your traffic comes from (DB-IP ASN Lite) and where IP databases place it (DB-IP City Lite). A curated list with sources says what kind of network that is: a telecom provider of a country, a hub for travel eSIMs or an IPX carrier, a cloud, a relay or VPN host, or a fixed line. Without a list entry we only guess from the registered name, and say so.

When our server runs its own small DNS zone, the test also asks for a random name in it. Your phone's DNS server has to look that name up with us, so we see which network that DNS server belongs to (never its address in the result). A DNS server in the same network as your exit is a second, independent signal; a public DNS service such as Google or Cloudflare says nothing about the route.

We combine that with the country you say you are in, how your phone is online and, if you fill it in, the network name at the top of your screen. A provider of that country means a local exit; a provider of another country means home routing; a hub means an exit through an intermediary; a data centre can be a hub or a VPN; a relay means we cannot see your own route. Wi-Fi (reported, seen by an Android phone, or a fixed-line network) means the test did not measure your SIM.

How sure we are depends on how many independent signals agree: that the test ran over your SIM, a confirmed entry in our list, the network name on your phone and the DNS server. One signal gives 'not sure', two give 'likely', three or more give 'very likely'. Signals that contradict each other, or a speed-of-light check that rules out a place, give 'not sure'. On a network that also sells fixed lines in your own country we say 'not sure' unless your phone reports a mobile connection: everything else holds over that provider's Wi-Fi too. A VPN you report only counts when the exit could be one. A Wi-Fi verdict rests on what we observed (a fixed-line network, a very fast answer, the browser's own report), not on your answers. And if our server answers within 8 ms above the speed of light, the test probably did not run over a phone's radio link: that is our own threshold, not a standard (ITU-R M.2410 gives 4 ms one way as the most a 5G system may take, so faster is possible in principle).

Everyday quality follows public guidance: Netflix for video (3 Mbit/s SD, 5 Mbit/s HD), ITU-T G.114 for calls (150 ms one way) and about 50 ms for fast games. We measure to our own server, so calls and games are rated for that direction. The distance to a far exit gives a lower bound for the extra delay to large websites: twice the distance at 210 km per millisecond, after taking off the uncertainty of both places.

The speed test

The full test asks our server for data over 6 connections at once, for about 10 seconds per direction; the data saver test over 4 connections, with at most 25 MB per direction. Each connection asks for the next part as soon as the last one has arrived, and the parts grow until each takes about three quarters of a second.

The figure is the average over the steady part of each direction: the first 2 seconds are left out, because a new connection starts slowly. Downloads are timed by your browser, uploads by our server as it receives them. From 1000 Mbit/s up we write Gbit/s.

While data flows, your browser measures the response time a few times a second over a separate connection. The difference with the quiet response time is what queues in your router or modem add: the reason calls and games stutter while someone downloads. Up to 10 ms nobody notices, up to 30 ms only fast games, up to 100 ms calls and games suffer, above that a busy line feels stuck.

We measure to our own server. What lies beyond it, and anything faster than one browser tab and our server can move, stays out of the figure.

Your address before the test

As soon as the start page opens, it asks our server under three names (your browser's own choice, IPv4 only and IPv6 only) which address it sees. The server answers with that address, the network it belongs to, where IP databases place it and its reverse DNS name. Nothing of this is stored; another website cannot ask our server about its visitors.

HTTP response delay

The main metric is request-to-first-byte (responseStart − requestStart from Resource Timing) of small, uncached HTTPS requests, after two warm-up requests per server. Servers are measured in interleaved, rotating order. When the browser hides that timing we fall back to the full fetch duration and say so. It is not an ICMP ping.

We show median, lowest value, the middle 50% and the number of samples. 'Variation' is the mean absolute difference between consecutive samples; it is not RTP jitter. A 95th percentile is only shown from 20 samples.

Phases that did not happen (a reused connection, cached DNS) are reported as not performed, never as 0 ms. TLS is never counted twice.

The light-speed check

Light in standard fibre covers about 204 km per millisecond; we use 210 km/ms to stay on the safe side. If your traffic left the mobile network at place E, a request to server N must take at least 2 × (distance you→E + distance E→N) / 210 ms. Measured times can only be longer than that, so a lowest measured time below the floor rules E out. Uncertainty radii of your location, the server and the place are subtracted first, so the check errs on the side of not excluding.

It can rule places out; it can never point at the exit. Long delays fit many places, and a slow radio link can hide a nearby exit.

Gave only a country? Then we count from the point of that country nearest to each server or place, using country borders from Natural Earth (public domain), shortened by 50 km for their simplification. That is less sharp than a city, but it can still say 'you cannot be in Spain'.

Findings, not a score

There is no overall quality score. Each finding lists observations, an interpretation, alternative explanations, how sure we are (not sure, likely, very likely), what is missing and at most one useful retest. A foreign GeoIP result alone is never more than 'likely'.

Thresholds (inference 1.8.0): a foreign server must beat the best local one by at least 10 ms in both median and minimum; 'very likely' needs 20 ms, eight samples each and separated middle halves. Local delay counts as high above 80 ms minimum. A server needs five valid samples to take part in comparisons.

Data budget

Quick diagnosis uses at most 2 MiB, the connection test at most 20 MiB and the deep test at most 100 MiB of test payload, counted by one budget manager that reserves bytes before every request. Header bytes are an estimate. Page assets, TLS and retransmissions come on top. Servers enforce their own limits per signed grant.

Throughput is reported in decimal Mbps as 'measured at this data budget'. Short transfers may not fill a fast line.

Corrections

If you think a result or rule is wrong, send the session id and what you observed. Corrections change the rule set version; old findings keep the version they were made with.