One of the easiest mistakes in mobile-network testing is to use the word connected for too many different things.
A phone can be attached to a radio network, show full signal bars, and still fail to resolve a hostname. DNS can work while an HTTPS request is blocked. An API can be reachable while a video call keeps reconnecting. A speed-test app can report hundreds of megabits per second while the application that matters is unusable.
This is especially easy to miss when testing a travel eSIM. The phone usually presents one simple status: connected. The network underneath is several separate steps.
The word “connected” hides several paths
A useful mental model looks like this:
phone radio
|
visited mobile network
|
data gateway or roaming path
|
DNS -> TCP/TLS -> application API
Each step can fail independently.
The phone may successfully register on the visited network but select the wrong data line. The data session may exist while DNS requests time out. DNS may return an address while the TLS handshake fails. The application API may respond, but slowly enough that the app treats the request as failed.
That is why “the eSIM works” is not a very useful test result. It describes a conclusion without saying which layer was tested.
A speed test answers one narrow question
A speed test is useful. It measures capacity and, depending on the tool, a form of responsiveness to one selected server. It is not a general health check for the connection.
Download speed tells us how quickly data arrived from that server during the measurement window. Upload speed tells us how quickly data left the device. Ping gives a round-trip time to a particular endpoint. None of these values tells us whether a specific API is reachable, whether a DNS resolver is reliable, or whether the connection survives movement between cells.
This distinction changes how results should be written. “The test recorded 553.52 Mbps download” is an observation. “The network is fast” is an interpretation. “The network will work well for every app” is an unsupported guarantee.
The more useful report keeps the number and the conditions together: device, place, time, local network, test server, and whether Wi-Fi was disabled.
Test from the outside in
When a connection behaves strangely, start with the simplest observable layer and move toward the application.
1. Check the public egress address
On Windows PowerShell:
$net = Invoke-RestMethod "https://ipinfo.io/json"
$net | Select-Object ip, city, region, country, org
On macOS or Linux:
curl -s https://ipinfo.io/json
The public IP is the address visible to an external service. It usually describes an egress point, not the phone’s physical radio location. The org field is a clue about the network organization associated with that IP prefix; it does not prove that every packet followed the same route.
2. Check DNS separately
On Windows:
Resolve-DnsName example.com
On macOS or Linux:
dig example.com
This tests name resolution, not the application itself. A successful DNS response only means that a resolver returned an answer. It does not prove that the returned service is reachable over HTTPS.
3. Make a real HTTP request
PowerShell has historically treated curl as an alias, so curl.exe makes the intention clearer:
curl.exe -I https://example.com
On macOS or Linux:
curl -I https://example.com
The response headers are not a complete application test, but they confirm that the device can resolve the name, establish a connection, negotiate TLS, and receive an HTTP response from that endpoint.
4. Trace the path only when the question requires it
On Windows:
tracert 1.1.1.1
On macOS or Linux:
traceroute 1.1.1.1
Traceroute is useful for investigating path changes and unexpected latency. It is also easy to overread. Routers may filter or rate-limit diagnostic packets, so an asterisk does not automatically mean that the user’s traffic is broken. A trace is partial evidence, not a packet-by-packet transcript.
Three field records, three different claims
The following examples come from a small first-party field log. They are useful because each one supports a different kind of statement.
553.52 Mbps is a point, not a promise
At the Canton Fair Complex in China, an iPhone 12 Pro Max running iOS 26.4.1 recorded 553.52 Mbps download through China Unicom at 1:33 p.m. on April 26, 2026.
The defensible statement is simple:
Under the recorded conditions, the device and profile achieved a 553.52 Mbps download result at that venue and time.
The record does not include a completed upload result, repeated runs, or the test-server details. It cannot support a claim about typical performance at the venue, across China, or across other devices.
Supported applications are not a speed score
A separate Shanghai session on an iPhone 16 Pro reported that ordinary web pages, WhatsApp messages and images, WhatsApp voice calls, Google Maps searches, Instagram media loading or upload, and hotspot sharing were supported during the session.
That is useful evidence, but it is binary and session-level. It does not measure call setup time, audio interruptions, upload duration, video bitrate, packet loss, or performance after a cell handoff.
For a better application record, log the operation, elapsed time, reconnect events, and failure mode. “The call connected” and “the call remained stable for 20 minutes while moving” are different claims.
A complete snapshot is not a representative sample
At Marienplatz in Munich, an iPhone 17 connected to O2 around midday on July 18, 2026 and recorded 175.3 Mbps download, 28.7 Mbps upload, and 102 ms ping.
This is a more complete snapshot than the Canton Fair record because it contains download, upload, and latency. It is not more representative simply because it contains more fields. It is still one session at one location and time.
The location also matters. A result from central Munich should not be presented as a result from a crowded event site, a railway tunnel, or an indoor hotel room.
What to record during the next test
A short test log is more valuable than a long paragraph of impressions. At minimum, record:
- date and local time;
- exact or approximate location;
- indoor or outdoor position;
- device and operating-system version;
- active SIM or eSIM data line;
- local mobile network, if visible;
- whether Wi-Fi was disabled;
- test application and server;
- download, upload, and latency results;
- application workflows and elapsed time;
- failures, reconnects, and changes of location;
- public IP, ASN, DNS, or traceroute results when routing is relevant.
Run the same test at least three times if the result will be compared. If the place is busy, repeat it in more than one time window. Keep the device and server constant where possible, then report the median as well as the lowest and highest result.
This does not turn a small field test into a laboratory benchmark. It does make the result easier to reproduce and harder to overstate.
Why two correct tests can disagree
Different results do not automatically mean that one test is wrong. Mobile performance depends on variables that are often invisible in a screenshot:
- modem and antenna differences between devices;
- indoor walls and venue geometry;
- local cell load;
- time of day;
- movement and cell handoffs;
- test-server location;
- roaming or aggregation paths;
- app version and server-side behavior.
This is also why application results and speed-test results should not be placed on one scale. “WhatsApp voice call supported” describes reachability and continuity during a workflow. “553.52 Mbps download” describes capacity to one test service. Both are useful, but they measure different things.
The right response to disagreement is not to choose the most impressive number. It is to ask which variable changed and whether the test was designed to control it.
The practical definition of “working”
For a traveler, a working connection is usually not the one with the highest peak speed. It is the one that completes the task that matters: loading a map, sending a message, joining a call, uploading a file, or keeping a hotspot alive.
For a developer, that means the test should start from the application workflow and work backward. Identify the endpoint, name resolution, transport, latency, and continuity requirements. Then choose the measurements that can confirm or reject each assumption.
The same method works whether the data line comes from a physical SIM, a travel eSIM, or a roaming arrangement. The label on the subscription does not replace a measurement model.
Conclusion
A full signal bar only tells us that one part of the mobile connection is present. A speed test tells us something about capacity to one server. Neither result, by itself, explains whether an application will work.
The useful path is to test in layers: attachment, DNS, HTTP, application workflow, throughput, latency, and continuity. Record the conditions, separate observations from conclusions, and keep missing data visible.
That approach produces a smaller and less exciting report than a single headline speed. It is also much more useful to the next person trying to understand why a mobile connection works in one place and fails in another.
AI assistance was used to edit this draft; the commands and measurements were checked against the underlying field notes.
Top comments (0)