Wi-Fi connected but no internet: how to find the real cause in four tests

Your phone says it is on the Wi-Fi. The signal bars are full. And yet nothing loads. This is probably the most common network complaint there is, and the frustrating part is that the message itself tells you almost nothing. "No internet" is not a diagnosis. It is your device saying "I tried to reach a server I trust, and I did not get the answer I expected."

The good news: there are only about five places where this can break, and you can test all of them in under two minutes if you go in the right order. Rebooting the router fixes it roughly half the time, which is why everyone suggests it, but that also means half the time you reboot and nothing changes. Then what?

Here is the order I actually use, from the closest link in the chain to the furthest.

What "connected but no internet" actually means

When your iPhone, iPad or laptop joins a Wi-Fi network, it runs a quiet background check called a captive portal probe. It fetches a tiny file from a known Apple or Google server. If the file comes back exactly as expected, you get the normal Wi-Fi icon. If the request fails, or if something returns a different page than expected, you get the warning.

That single check can fail for wildly different reasons:

• Your device never got a valid IP address from the router.
• It got an IP but cannot reach the router itself.
• It reaches the router but the router cannot reach the internet.
• Everything routes fine but DNS is broken, so no name resolves to an address.
• There is a captive portal (hotel, airport, cafe, office guest network) waiting for you to accept terms.

Each of those has a completely different fix. Guessing wastes time. Testing takes two minutes.

The four tests, in order

The principle is simple: start at the layer closest to you and move outward. The first test that fails is where the problem lives. Everything past it is noise.

1. Can you reach your own router?

   Ping your default gateway, which is usually something like 192.168.1.1, 192.168.0.1 or 10.0.0.1. If this fails, the problem is between your device and the router: a bad Wi-Fi association, client isolation on a guest network, or a DHCP lease that never arrived. Nothing further out matters yet.

   A quick trick if you are not sure of the gateway address: run a LAN Scan on your subnet. It lists every device that answers, and the router is nearly always the lowest live address.

2. Can you reach a raw IP on the internet?

   Ping 1.1.1.1 or 8.8.8.8. These are Cloudflare's and Google's public resolvers, and they are about as reliable as anything on the public internet. This test deliberately skips DNS, because you are pinging a number, not a name.

   If the gateway answers but 1.1.1.1 does not, your router has a working local network but no path out. That is an ISP link problem, a modem problem, or a router WAN configuration problem.

3. Can you resolve a name?

   Look up example.com or apple.com. If pinging 1.1.1.1 worked but the lookup fails or hangs, you have found it: routing is fine and DNS is broken. This is by far the most common cause of "the internet is down" that turns out not to be the internet at all.

   Run the lookup a second time against a specific resolver, for example 1.1.1.1, using the DNS Lookup tool's custom server field. If it works against Cloudflare but not against your router's default resolver, the router's DNS forwarder is the broken piece.

4. Can you actually fetch a page?

   Run an HTTP(S) Check against something plain like http://example.com. Watch the status code and the redirect chain. If a request for a normal site gets redirected to an address you do not recognise, you are sitting behind a captive portal and it is waiting for you to log in. If the request times out while ping and DNS both worked, look for a proxy, a content filter, or a firewall policy.

Four tests. Whichever one fails first is your answer.

Reading the results: a quick lookup table

Find the row that matches what you saw and you have your culprit.

Gateway ping	Ping 1.1.1.1	DNS lookup	Most likely cause
Fails	Fails	Fails	Wi-Fi association or DHCP problem. Forget the network and rejoin, or check for an IP address starting with 169.254, which means no DHCP lease.
Works	Fails	Fails	Router has no path to the internet. Check the modem, the WAN light, and your ISP status page.
Works	Works	Fails	DNS. Switch the device or router to 1.1.1.1 or 8.8.8.8 and retest.
Works	Works	Works, but pages do not load	Captive portal, proxy, content filter, or a broken MTU on the path.
Works	Works, but very high latency or heavy loss	Slow	Congested or degraded link. Time to look at packet loss rather than a hard outage.

The usual culprits, ranked

1. A captive portal you never saw

Hotels, airports, cafes, trains, conference venues and corporate guest networks all put you behind a login page. If the sign in sheet failed to pop up, every request quietly redirects and nothing works. The HTTP(S) Check gives this away instantly: you ask for one host and the redirect chain lands somewhere else entirely. Open any plain http:// site in a browser to force the portal to appear.

2. DNS is down or misconfigured

Your router hands out its own address as the DNS server and forwards queries upstream. When that forwarder gets stuck, which happens a lot on consumer routers after a few weeks of uptime, names stop resolving even though the connection is perfectly healthy. The symptom is a device that pings numbers fine and loads nothing by name. Setting DNS manually to 1.1.1.1 or 8.8.8.8 is both the test and the workaround.

3. No DHCP lease

If your device shows an address like 169.254.x.x (or 0.0.0.0), it asked for an IP and nobody answered. Causes include a router whose DHCP pool is exhausted, two DHCP servers fighting on the same LAN, or a mesh node that lost its uplink. Forget the network, rejoin, and if it repeats, look at the router's DHCP range.

4. The ISP is actually down

It does happen. The tell is that the gateway responds instantly and anything beyond it does not, with traceroute stopping at the first or second hop outside your network. Check your public IP: if the app cannot retrieve one at all, nothing is getting out of your network. Worth a call.

5. IPv6 trouble

Some networks advertise IPv6 but cannot actually route it. Your device prefers IPv6, tries it first, waits for a timeout, then falls back. The result feels like a slow or half broken internet rather than a clean failure. If pinging an IPv4 literal is instant but hostnames are sluggish, this is a good suspect.

6. Wrong system clock

An underrated one. If the device clock is far enough off, TLS certificate validation fails on every HTTPS site and the captive portal probe fails with it. Everything looks connected, nothing secure loads. An NTP Time Check compares your device clock against a real time server and shows the offset in milliseconds.

7. A VPN or profile left behind

A disconnected VPN that left its DNS settings in place, or an old configuration profile, can route queries to a server that no longer exists. If the problem follows your device across networks, this is where to look.

Turning this into a one tap check

The four tests above are the same four tests every single time. Instead of running them by hand, build them once as an automation: ping the gateway, ping 1.1.1.1, resolve a hostname, fetch a URL. One tap, one screen, every answer.

You can also keep the individual checks as bookmarks or Shortcuts using deeplinks:

# Ping a public resolver, 5 packets
https://netdebug.app/open/ping?target=1.1.1.1&count=5

# Resolve a name through Cloudflare instead of the router
https://netdebug.app/open/dns?target=example.com&server=1.1.1.1

# Fetch a plain HTTP page and watch the redirect chain
https://netdebug.app/open/http?target=http://example.com

Because every run is saved in Run History, you also end up with a record. That matters more than it sounds: when the outage is intermittent and your ISP asks "when exactly did this happen," you have timestamps and numbers instead of a story.

The short version

Ping your router. Ping 1.1.1.1. Resolve a name. Fetch a page. The first thing that fails is the thing that is broken, and each failure points at a different fix. Rebooting the router is a fine first move, but if it does not help, you now have something better than guessing.