# Is it my Wi-Fi or the internet?

> Four checks, in order, from your phone, with no terminal needed. Each one rules out a different piece, so you know who to restart or who to call.

Source: https://apps.swtlm.com/blog/is-it-my-wifi-or-the-internet · TLM Apps — focused mobile apps from a team of engineers.
Published: 2026-07-06 · Updated: 2026-07-06 · TLM Software Design

Ping your router first. If that is slow or drops packets, the fault is your
Wi-Fi. If the router answers cleanly, ping a numeric address such as 1.1.1.1;
a failure there points at your internet connection rather than your network. If
both answer and websites still will not load, the problem is name lookup rather
than connectivity. Each check rules out one hop, which is what turns "the
internet is broken" into something you can act on.

## Four hops, four different problems

Between your phone and a web page there are four places to fail, and they need
four different responses:

1. **Phone to router** — the Wi-Fi itself. Distance, interference, a bad band.
2. **Router** — the box. Overloaded, confused, out of addresses.
3. **Router to the internet** — the line and your provider. Nothing you can fix
   from inside.
4. **Name lookup (DNS)** — the service that turns `example.com` into a number.
   Everything is reachable and nothing is findable.

The connected icon on your phone reports **only the first hop**. That is why
"connected, but nothing works" is the most common version of this problem and
the least informative: the phone is telling you the truth about the only thing
it was asked.

## The four checks, in order

Do them in this order. Each one only makes sense if the previous one passed.

It is the standard advice and it is out of order. A restart does fix a real
class of fault, such as a router that has run out of addresses or wedged a
table, but it also destroys every piece of evidence about which hop was
broken. Run the four
checks, then restart. Two minutes of diagnosis is what stops the same fault
being a mystery again next week.

## Reading what comes back

The number a ping reports is the round trip: out and back, in milliseconds. On
a home network you are looking at three things.

**Does it answer at all.** A reply is a reply. A timeout is a timeout. Any
timeouts in a run to your own router is a Wi-Fi problem, full stop.

**How steady the numbers are.** Twenty replies at 4, 5, 4, 6, 5 ms is a healthy
link. Twenty replies at 4, 90, 6, 250, 5 ms is a link that is technically up
and will make a video call unwatchable. That variation is jitter, and it
matters more than the average for anything live.

**How many came back.** Nineteen replies out of twenty is 5% packet loss. On a
local hop that is a fault, not a fluctuation.

What each of those means for whatever you were actually doing, whether a call,
a game or a download, is in [what ping, jitter and packet loss
mean](https://apps.swtlm.com/blog/what-ping-jitter-and-packet-loss-mean).

## Two things worth knowing before you trust a ping

**A ping that fails does not always mean a host is down.** Ping uses ICMP, and
plenty of servers and firewalls simply drop ICMP on purpose. Ignoring a ping is
a perfectly normal configuration, so a timeout against a *remote* host is
ambiguous: it could be down, or it could be declining to answer. This is why
the order above starts with your own router — a hop where nothing has any reason
to drop the packet, and uses `1.1.1.1` for the internet check — a resolver that
answers ICMP by design.

**Ping tests reachability, not speed.** It measures how long a very small
packet takes to make a round trip. That is the right measurement for a call, a
game or a video conference, all of which care about delay and consistency. It
tells you close to nothing about how fast a large file will download, which is
throughput and a completely different test —
[what ping, jitter and packet loss mean](https://apps.swtlm.com/blog/what-ping-jitter-and-packet-loss-mean)
takes that apart properly. A connection can have an excellent
ping and poor bandwidth, or the reverse, and confusing the two is the most
common way these results get misread.

## Common results, and what they point at

| What you see | Where it is |
|---|---|
| Router ping times out | Wi-Fi. Distance, interference, or the band. |
| Router fine, 1.1.1.1 times out | The line or the provider. Check for an outage; then call. |
| Both fine, names do not resolve | DNS. Change the phone's DNS, or the router's. |
| Everything fine, one site down | That site. Nothing to fix here. |
| Fine on mobile data, broken on Wi-Fi | Inside your home. Start at the router. |
| Broken on both | The provider, or a wider outage. |

## Doing this without a terminal

The ranking advice for this problem tells you to open a command prompt, which
is fine on a laptop and unavailable on the device most people are holding when
they ask.

[Ping Network Tool](https://apps.swtlm.com/ping-network-tool) is what we built for the phone version,
and it has two modes because the two audiences for this question want opposite
things.

**Simple mode** answers the whole question with one tap, in words: *internet is
available*, *host is not reachable*, or *DNS is not resolving*. That is exactly
the three-way split above, and it is the default on first launch — the History
and Network tabs are not even shown until you ask for them.

**Advanced mode** runs a Linux-faithful ping: sequence number, TTL and
round-trip time for each packet, line by line, with a live graph and the same
min / avg / max / loss summary a terminal prints. Traceroute is one button
away, hop by hop with the round-trip time for each, which is how you find out
*which* hop is adding the delay rather than that something is. Every session is
kept in a local history, so "was it this bad last Tuesday" is answerable.

On a desktop, ICMP traditionally needs a raw socket and administrator rights.
Neither phone platform will grant that to an app, which is why so many mobile
ping tools quietly fake it. Both iOS and Android expose an *unprivileged* ICMP
datagram socket instead — the same mechanism behind Apple's own sample code —
so the packets [our own tool](https://apps.swtlm.com/ping-network-tool) sends are real ICMP with no
special permission. Where ICMP is blocked
outright, the app falls back to timing a genuine TCP connection on port 443 or
80, so the round-trip time is still measured rather than estimated.

One platform difference worth naming, because it is not a bug: the Network tab
showing your gateway, DNS server and external IP is Android-only. iOS has no
public API for the configured DNS resolver or gateway, so rather than ship a
tab with one field in it we hide it there entirely.

It has no ads at all — a deliberate exclusion, not an oversight — and the
diagnostic work is free. A single one-time purchase adds TCP ping and lifts the
cap on background monitoring. There is no subscription — the reasoning is in
[what a puzzle game subscription costs](https://apps.swtlm.com/blog/what-a-puzzle-game-subscription-costs).

The rest of the small utilities we make are on the [Tools page](https://apps.swtlm.com/tools), and
why a services company builds them at all is on the [About page](https://apps.swtlm.com/about).

## Frequently asked questions

**My phone says connected but nothing loads. What does that mean?**

It means the Wi-Fi link between your phone and the router is fine, and something beyond the router is not. Wi-Fi and internet are two separate hops, and the connected icon only reports the first one.

**How do I test the internet from a phone without a terminal?**

Ping an address that is a number rather than a name, such as 1.1.1.1. If a numeric address answers and a website still will not load, the fault is name lookup rather than connectivity.

**Why does the mobile data test matter?**

Turning Wi-Fi off and loading the same page on cellular tests the whole path through a completely different provider. If it works, everything wrong is inside your home.

**What is DNS, in one sentence?**

The service that turns a name you typed into the numeric address a device can actually reach. When DNS is broken, numbers work and names do not.

**When should I restart the router?**

After the checks, not before. A restart destroys the evidence and fixes a specific class of fault; doing it first means you learn nothing when the problem returns tomorrow.