“Connected, no internet” means your device has joined a local network but cannot successfully reach the internet. The Wi-Fi radio can be working perfectly while the router has lost its upstream connection, DNS is failing, or only one device has a bad configuration.
Test another device first
If every device is offline, focus on the router, modem/ONT, and ISP. If only one device fails, the network itself is probably healthy and the problem is local to that phone or computer.
Check the router’s WAN/internet status
Look at the modem/ONT and router status lights, then open the router interface if available. A missing WAN address, failed PPPoE session, or optical/cable signal warning points upstream.
Restart in a controlled order
For a separate modem and router, power down both. Start the modem/ONT first and wait until it is fully connected to the ISP, then start the router. This gives the router a clean chance to obtain its WAN configuration.
Check whether DNS is the problem
If an IP-based test works but domain names do not, DNS may be failing. Do not randomly change DNS before confirming the symptom. Restarting the router or renewing the device’s network lease can clear stale resolver information.
Look for VPN, private DNS, proxy, or security software
These can break only one device while the rest of the network works. Temporarily disable the feature and test again.
Do not reset the router immediately
A factory reset cannot fix an ISP outage and may make recovery harder by deleting working connection settings. Check the provider’s outage status or contact support when the router shows no upstream service.
First prove local connectivity
If the router page/default gateway opens, Wi-Fi association and local IP routing are functioning. Next inspect WAN status. If the gateway does not open, the problem is local: bad DHCP lease, isolation, router freeze, mesh/backhaul or wrong network.
DNS versus raw connectivity
If an IP-based test works but domain names fail, investigate DNS. If neither works, focus on WAN/ISP routing. Avoid immediately switching to random public DNS because that can hide the actual outage and will not fix a dead WAN link.
One-device versus all-device failure
If only one phone/laptop fails, renew/reconnect it, forget/rejoin Wi-Fi and check VPN/proxy/private-DNS settings. If every device fails simultaneously, the router/modem/ISP path is more likely.
Diagnostic rule: prove the failing layer before changing settings
Start with physical/link state, then local IP/gateway, then router/WAN status, then DNS/application behavior. This order prevents destructive resets and random configuration changes from hiding the original problem. Write down what works and what fails after each step.
When to stop and contact the provider/vendor
Escalate when the fault is upstream of equipment you control, when provider provisioning is involved, when hardware is under warranty, or when the next step would erase settings you cannot reconstruct. Capture model, firmware, timestamps and test results first.
A four-layer field test you can use before changing configuration
1. Link and association
Verify that Ethernet shows a physical link or that Wi-Fi is connected to the intended SSID. A device connected to a similarly named guest, extender or neighbor network can make every later test misleading. On a phone, temporarily disable cellular data if you need to prove the browser is using the local LAN.
2. Local addressing
Read the client IPv4/IPv6 address, subnet/prefix, default gateway and DNS servers. A self-assigned 169.254.x.x IPv4 address usually means DHCP failed. A normal private address without a reachable gateway points to a different failure than a working gateway with no internet.
3. Gateway and WAN
Open or ping/test the gateway using a method appropriate to the device. If local management works, inspect router WAN status rather than resetting Wi-Fi. Look for WAN address, link state, lease/session status and provider alarms on modem/ONT equipment.
4. Name resolution and application
Separate DNS from connectivity. If an IP destination works but names fail, investigate resolver settings/cache. If DNS and routing work but one site/app fails, the problem may be remote, TLS-related, filtered or application-specific.
Document before escalating
Record exact error messages, timestamps, model/firmware, wired versus wireless result and whether multiple devices are affected. This turns “internet broken” into evidence an ISP or vendor can act on.
Wi-Fi-specific evidence to collect
Record band, channel/channel width, RSSI/signal level if available, negotiated link rate, node/access point association and whether the same symptom occurs over Ethernet. A wired control test is especially valuable: if Ethernet is stable while Wi-Fi fails, focus on radio/interference/roaming rather than WAN or DNS.
Client compatibility matters
Old drivers, power-saving behavior, unsupported WPA modes and device-specific roaming decisions can make one client fail while every other device works. Update the client and test another device before changing the whole network around a single endpoint.
What not to do while diagnosing the problem
Do not factory-reset the router merely because a familiar address does not open. Do not change DNS, Wi-Fi channels, DHCP and firewall rules simultaneously. Do not download “router unlock” utilities or enter administrator credentials into a public website. Those actions add risk without proving the failing layer.
A good stopping point
Stop local troubleshooting when the evidence clearly shows a provider outage/provisioning issue, failing hardware, or a model-specific recovery process you cannot safely complete. Preserve logs/screenshots and the exact tests that isolated the fault, then escalate with those facts.
After the fault is fixed
Remove temporary test settings, reconnect any VPN/security tools you disabled, verify several devices, and document the final LAN/gateway/DNS configuration. If a reset was required, restore security settings intentionally rather than assuming every factory option is appropriate.