Wi-Fi Connected But No Internet: Find the Cause Before You Start Resetting Things

The Wi-Fi icon shows a full connection. The network name is right. And nothing loads.

This is a genuinely useful symptom, because it rules out a whole class of problems immediately. Your device successfully found the access point, authenticated to it, and joined the network. The radio link works. Whatever is broken sits above that link — in the addressing, in name resolution, in the router, or out on your provider's network.

That is why the advice you will most often be given — restart the router, or reset your network settings — is a poor first move. Both are blunt instruments that can work by accident, and one of them destroys real configuration you will have to rebuild. Four quick tests will tell you which part of the chain is at fault, and they take about three minutes.

Before anything: what a network reset actually costs

Two of the "fixes" commonly recommended for this symptom are destructive, so it is worth knowing the price before you pay it rather than after.

On iPhone and iPad, Apple describes Reset Network Settings as follows: it "resets all Wi-Fi networks and passwords, cellular settings, and VPN and APN settings". Every saved Wi-Fi password on the device, gone — including networks you cannot easily rejoin, like a workplace network you no longer have credentials for.

On Windows, Microsoft describes the network reset as one that "removes any network adapters you have installed and the settings for them. After your PC restarts, any network adapters are reinstalled, and the settings for them are set to the defaults." Microsoft adds that afterwards "you might need to reinstall and set up other networking software you might be using, such as VPN client software". Microsoft itself lists network reset as the last step in its troubleshooting sequence, not the first.

A router factory reset is more expensive again. It typically clears your Wi-Fi name and password, any port forwards, static DHCP leases and, on many setups, the broadband credentials your ISP provided. Do not start there.

Test 1: is it one device, or all of them?

Pick up a phone and try a website on it, ideally over the same Wi-Fi network. Then, if you can, turn Wi-Fi off on that phone and try again over mobile data.

This single test splits the problem in half, and both Apple and Google put it in their own guidance — Apple advises testing another device on the same network, and Google's Android guidance suggests switching between Wi-Fi and mobile data to isolate where the failure is.

• Only one device is affected: the fault is on that device. Skip to Test 3.
• Every device on the Wi-Fi is affected, but mobile data works: the fault is in your router or upstream of it. Go to Test 2.
• Mobile data is also failing on a site you know is up: the site may simply be down. Try a couple of different, well-known sites before assuming your network is broken.

Test 2: is it your router, or your ISP?

If everything on the network is affected, the next question is whether the break is inside your home or outside it.

The clearest indicator most people already have: check your router's status lights, and specifically whether the internet or WAN light shows an established connection. Most routers distinguish "the local network is up" from "there is a working line to the provider", and that distinction is exactly what you need here.

If your setup has a separate modem and router — two boxes rather than one — treat them as two separate things to check. Both Apple and Microsoft do: Apple's guidance is to "restart your router and cable modem by unplugging the devices and then plugging them back in", and Microsoft's sequence has you restart the modem and the router, waiting around 30 seconds before powering them back up.

Also worth two minutes: check whether your ISP is reporting an outage, via their status page or app on mobile data. Apple's own guidance ends at exactly this point — if you are connected to Wi-Fi but cannot reach the internet, contact your provider. A surprising share of these incidents are simply someone else's problem, and no amount of resetting your equipment will help.

Test 3: what address did your device actually get?

This is the test that most often produces an actual diagnosis rather than a guess, and it is the reason this symptom exists as a distinct category.

Joining a Wi-Fi network and getting a usable IP address are two separate steps. Your device can complete the first and fail the second. When that happens on Windows, the device gives itself an address in the 169.254 range — a link-local address, defined in IETF RFC 3927, which a host self-assigns when no address configuration is available. Microsoft calls this Automatic Private IP Addressing, and lists it as one of the three ways a Windows adapter gets configured, alongside DHCP and a manual alternate configuration.

The critical property of these addresses is in the RFC itself: link-local addresses "MUST NOT be sent to any router for forwarding", and they are "not suitable for communication with devices not directly connected to the same physical (or logical) link". In plain terms, a device with a 169.254 address can talk to the local link and nothing beyond it. That is precisely the "connected, no internet" symptom.

On Windows, run ipconfig /all in a command prompt and read the IPv4 address for your Wi-Fi adapter. On a phone, the assigned IP address is usually visible in the network's details screen.

• An address starting 169.254 means DHCP failed. Your router did not hand out an address — because its DHCP service is not running, because its address pool is exhausted, or because something between you and it is interfering. Restarting the router is a legitimate fix for this specific finding, which is quite different from restarting it hopefully.
• A normal private address (typically starting 192.168, 10., or in the 172.16 to 172.31 range) means addressing worked, and you should move on to Test 4.
• A static address someone configured manually, on a network whose addressing has since changed, will produce exactly this symptom too. Microsoft documents a relevant trap here: ipconfig /renew "is available only on computers with adapters that are configured to obtain an IP address automatically", so on a statically configured adapter the command you were told to run does nothing at all.

Test 4: is it DNS?

If addressing is fine, the next most common culprit is name resolution — your device can reach the network but cannot turn a website name into an address.

The fast test: try to load a site by IP address rather than by name, or try a different app that does not depend on the same resolution path. If numeric addresses work and names do not, you have a DNS problem.

On Windows, Microsoft documents ipconfig /flushdns as flushing and resetting the DNS client resolver cache, noting that "during DNS troubleshooting, you can use this procedure to discard negative cache entries from the cache, as well as any other entries that have been added dynamically". A negative cache entry — a remembered failure — is a real and under-appreciated cause of a name that stays broken after the underlying problem is fixed.

On Android specifically, there is a modern cause worth knowing about: Private DNS. Google documents that "by default, your device uses Private DNS with all networks that can use Private DNS". If a Private DNS provider has been set manually and that provider is unreachable — or is blocked on the network you are currently using — name resolution fails on that network while everything else looks fine. It is found under the network settings on the device and is worth checking before anything more drastic.

The other real causes, and how to recognise them

**A captive portal you have not signed into.** Hotel, café, airport and campus networks commonly require you to accept terms or log in first. IETF RFC 8910 describes the arrangement directly: users "need to connect to a captive portal device and agree to an Acceptable Use Policy (AUP) and/or provide billing information before they can access the Internet". Modern devices usually detect this and pop up a sign-in page, but detection fails often enough that the symptom presents as plain "connected, no internet". The test is to open a browser and try to load any plain, non-encrypted page and see whether you are redirected.

**A VPN or security product that is intercepting traffic.** Apple's guidance is explicit about this: uninstall VPN or security software, restart, and test again. A VPN whose server is unreachable, or whose kill-switch is active, produces a network that is connected and carries nothing. Disconnect it fully — not just disconnect the tunnel, but disable the client — as a test.

**A wrong system clock.** This one presents strangely: some sites work and secure sites fail with certificate warnings. Certificates carry a validity period, defined in RFC 5280 as "the time interval during which the CA warrants that it will maintain information about the status of the certificate", with explicit start and end times. A device whose clock is badly wrong — often after a battery removal, a long period switched off, or a fresh install — sees valid certificates as not-yet-valid or expired, and refuses the connection. Setting the date and time correctly, or re-enabling automatic time, fixes it instantly.

**Two devices with the same IP address.** If somebody has manually assigned a static address that the router later handed to something else, both devices behave erratically. This is a real failure mode, though we could not find a manufacturer document describing it, so treat it as a hypothesis to test rather than a documented cause: the test is to set the device back to automatic addressing and see whether the problem disappears.

The Windows commands, and what they actually do

Microsoft's own Wi-Fi troubleshooting sequence includes a step of running network commands, so these are legitimate — but each does something specific, and knowing what saves you from cargo-culting.

• ipconfig /release "sends a DHCPRELEASE message to the DHCP server to release the current DHCP configuration and discard the IP address configuration", and Microsoft warns that it "disables TCP/IP for adapters configured to obtain an IP address automatically". Between release and renew, that machine is off the network. Do not run it over a remote connection.
• ipconfig /renew requests a fresh lease, and as noted works only on adapters set to obtain an address automatically.
• ipconfig /flushdns clears the resolver cache, including remembered failures.
• netsh winsock reset "resets the Winsock catalog to a clean state, removing any custom LSPs to resolve network problems caused by corrupted Winsock settings", though Microsoft notes "it doesn't affect Winsock Name Space Provider entries". Reserve this for a machine where a badly-behaved network product has been installed and removed.
• netsh int ip reset appears in Microsoft's own troubleshooting article, but we could not locate current Microsoft documentation describing exactly what it resets — the reference pages that used to cover it now return errors. We are telling you that rather than inventing a description of it.

Microsoft's broader advice, on the same documentation, is that PowerShell is now the recommended way to manage networking on Windows rather than netsh.

Microsoft's full published order is worth following, because it moves from cheap to expensive: check the connection, confirm airplane mode is off, forget and rejoin the network, restart the modem and router, try the other band, test another device, run the network commands, reinstall the adapter driver, ping the default gateway, disable adapter power saving, check Windows Update, restart — and only then, as a last resort, network reset.

When this does not matter to you

• One app is broken and everything else works. That is an application or a service outage, not a network problem, and no network change will fix it.
• It resolved itself in under a minute and has not returned. Brief DHCP renewals, band switches and provider blips all produce a momentary version of this symptom. A single, self-healing incident is not worth investigating.
• You are on a public network you have just joined. Assume a captive portal first; everything else on this list is unlikely by comparison.
• Only your work laptop is affected, on a machine your employer manages. Corporate VPN, DNS and certificate policy can all produce this symptom by design. Contact your IT support rather than running resets that may breach policy or lock you out further.

If nothing here worked

You should now be able to say which of four things is true: the fault is one device, the fault is your router, the fault is upstream at your ISP, or the fault is a specific service. That is a far better position than where you started, and it is the difference between a five-minute support call that gets somewhere and one that does not.

If everything points at the router and it is old, our guide on what to check before buying new hardware covers whether a replacement is genuinely warranted — and if you decide it is, which Wi-Fi generation is actually worth paying for.