How do I fix WiFi that is connected but has no internet?

WiFi says connected but nothing loads? In most cases the problem is one of four things: your router lost its WAN link, your device got a bad IP address from DHCP, your DNS resolver is down, or a captive portal is blocking traffic. Work through the four diagnostic steps below in order — most people are back online in under ten minutes.

Is It Just Your Device?

Before touching any settings, grab a second device — a phone or tablet — and try loading a page over the same WiFi network. If the second device works, the problem is isolated to your computer or primary device. If nothing on the network has internet, the issue is between your router and your ISP.

This single check cuts the troubleshooting tree in half. Device-only failures point to IP address, DNS cache, or local configuration. Network-wide failures point to the router's WAN link or an ISP outage.

Step 1: Check Your IP Address

Open a terminal or command prompt and inspect your current IP address. A healthy DHCP-assigned address will be in one of the private ranges: 10.x.x.x, 172.16.x.x through 172.31.x.x, or 192.168.x.x. Any address starting with 169.254 is an APIPA self-assigned address — your device could not contact the DHCP server and assigned itself a fallback. With a 169.254 address your device is not properly on the network and cannot reach any outside resource.

Windows:

Look for the IPv4 Address and Default Gateway lines under your WiFi adapter. Write down the gateway IP — you need it in Step 2.

macOS:

The output shows IP address, subnet mask, and router (gateway). Alternatively:

Linux:

The second command shows your default gateway directly.

Step 2: Ping Your Gateway

Using the gateway IP from Step 1, test whether your device can reach the router at all. Do not assume a default address — use the value your own ipconfig or networksetup output showed. Common router defaults include 192.168.1.1, 192.168.0.1, 10.0.0.1, and 192.168.2.1, but your network may use something different.

If the gateway replies with round-trip times under 10 ms, your local WiFi link is healthy and the problem is upstream from the router. If the gateway does not reply, the issue is your local wireless link — interference, distance, or the router is locked up. Try moving closer to the router, then restart it.

Step 3: Separate Connectivity from DNS

This is the single most important diagnostic step. Ping a public IP address directly, bypassing DNS entirely:

There are two possible outcomes, and they point to completely different fixes:

• 1.1.1.1 replies but websites still do not load — your internet connection is working. The problem is DNS. Your device is reaching the internet but failing to translate domain names into IP addresses. Fix: switch to a public DNS resolver (see Fix 2 below).
• 1.1.1.1 does not reply — there is a genuine connectivity failure between your router and your ISP. No DNS change will help until the WAN link is restored.

To confirm a DNS failure specifically, run a direct lookup:

If nslookup returns IP addresses but your browser shows DNS_PROBE_FINISHED_NXDOMAIN or 'Server not found', the resolver your OS is pointing to has failed while 1.1.1.1 still works. You can also use our DNS Lookup tool to check whether a specific domain resolves through Google Public DNS — useful for confirming whether the failure is local to your network or affects the domain more broadly.

Root Causes, Ranked by Frequency

1. Router lost WAN connectivity — the most common cause by far. The router maintains WiFi for all local devices but the DSL, cable, or fiber link to the ISP has dropped. All devices on the network share the symptom; pinging the gateway works but 1.1.1.1 does not.
2. ISP DNS resolver failure — your ISP's name servers are returning errors or timing out. Pinging 1.1.1.1 succeeds but nslookup fails or returns SERVFAIL.
3. DHCP failure resulting in a 169.254 address — the router's DHCP pool is exhausted, DHCP is disabled, or the router is overloaded. Affects devices that recently joined or tried to renew their lease.
4. Captive portal not dismissed — hotel, cafe, airport, and some corporate networks require a browser login before traffic flows. The device associates with the network but all traffic is intercepted until authentication completes.
5. ISP outage — nothing locally fixable. Requires checking the ISP's status page from a separate mobile data connection.
6. MTU mismatch — persistent and easy to misdiagnose. Large packets are silently dropped. Common on PPPoE DSL connections and active VPN tunnels.

Fix 1: Restart the Router and Modem

This resolves the majority of WAN dropout and DHCP exhaustion cases. Power off the modem first, then the router. Wait 30 seconds. Power on the modem and wait until its WAN or Internet indicator turns solid — DSL and cable modems typically take 30 to 90 seconds to sync with the line. Then power on the router and wait another 60 seconds before testing. A full power cycle clears routing table corruption, DHCP lease exhaustion, and most firmware-level hangs in a single step.

Fix 2: Switch Your DNS Resolver

If Step 3 confirmed DNS is the problem — 1.1.1.1 pings fine but domain lookups fail — change your resolver away from your ISP's servers to a reliable public one.

Windows 10 / 11: Settings > Network and Internet > Wi-Fi > click your network name > Properties > Edit under DNS server assignment > Manual > IPv4 On > set Preferred DNS to 1.1.1.1 and Alternate DNS to 8.8.8.8. Click Save.

macOS Ventura and later: System Settings > Network > Wi-Fi > Details > DNS tab > click + > add 1.1.1.1 > add 8.8.8.8 > OK. You can remove the original ISP entries by selecting them and clicking the minus button.

Android 9 and later: Settings > Network and internet > Advanced > Private DNS > Private DNS provider hostname > enter one.one.one.one. This enables encrypted DNS over TLS and routes all lookups through Cloudflare, bypassing the ISP resolver entirely.

iOS 14 and later: iOS does not expose per-network DNS settings in the system UI. The most reliable method is to set DNS on the router itself so it pushes 1.1.1.1 to all devices via DHCP option 6. Alternatively, install a DNS configuration profile from a trusted provider's app.

Linux with systemd-resolved:

For a permanent change, edit /etc/systemd/resolved.conf and add DNS=1.1.1.1 8.8.8.8 under the [Resolve] section, then restart the service:

Fix 3: Flush Your DNS Cache

After switching resolvers, your OS may still serve stale cached responses — including negative entries that say a domain does not exist. Flushing forces fresh lookups against the new resolver.

Windows:

macOS (Ventura / Sonoma):

Linux (systemd-resolved):

After flushing, open a private or incognito browser window to test — regular tabs can cache their own DNS results independently of the OS cache.

Fix 4: Release and Renew Your DHCP Lease

If your IP address was a 169.254 address, or if ipconfig /all shows an address outside the expected private ranges, force the device to request a fresh address from the router.

Windows:

macOS: System Settings > Network > Wi-Fi > Details > TCP/IP tab > click Renew DHCP Lease.

Linux:

If renewing still returns a 169.254 address, the DHCP service on the router is the problem — restart the router.

Fix 5: Dismiss a Captive Portal

On hotel, airport, coffee shop, and some corporate networks, all traffic is blocked until a browser-based login or terms acceptance is completed. Most operating systems detect this automatically and present a login prompt. If the prompt never appeared, force it: in a browser, navigate to http://neverssl.com — a plain HTTP site maintained specifically to trigger captive portal redirects. Complete whatever login or acceptance page opens and internet access restores immediately.

Fix 6: Check for an ISP Outage

If a full modem and router restart does not restore WAN connectivity, the problem may be on your ISP's network. Check their outage page from a mobile data connection — not the broken WiFi — or call their support line. For understanding whether a specific public resolver like 1.1.1.1 or 8.8.8.8 is itself reachable, Google Public DNS documentation describes expected behavior and can help you distinguish a local routing failure from a problem with the resolver itself.

Fix 7: MTU Mismatch

MTU mismatch is uncommon but persistent and commonly misdiagnosed as an intermittent connection problem. Symptoms: search results and small pages load but large pages time out, images fail to render, HTTPS sites hang while plain HTTP works, and video streaming stalls after a few seconds. The cause is that your router's WAN MTU is set higher than the connection can actually carry — oversized packets are dropped silently without any error.

Test whether full-size packets can reach a public DNS server without fragmentation:

On macOS, ping flag syntax varies by OS version — consult man ping for the DF-bit option on your version. If the 1472-byte test fails but a smaller size like 1400 succeeds, your effective MTU is below 1500. For PPPoE DSL, the correct WAN MTU is typically 1492 — PPPoE adds an 8-byte header that reduces the usable payload from the standard Ethernet 1500. Log into your router's admin panel and lower the WAN MTU setting. The exact menu label varies by firmware; look for WAN Setup, Internet Connection, or Advanced Network. On OpenWrt: Network > Interfaces > WAN > Edit > Advanced Settings > Override MTU.

Router Admin Panel Access

Enter the gateway IP from Step 1 directly into your browser's address bar — do not guess or use a default. Common vendor admin URLs for reference:

• TP-Link: tplinkwifi.net or 192.168.0.1
• ASUS: asusrouter.com or 192.168.1.1
• Netgear: routerlogin.net
• Netgear Orbi: orbilogin.com
• Xiaomi / Mi: miwifi.com
• Linksys: linksyssmartwifi.com

On DD-WRT firmware, DNS overrides are under Setup > Basic Setup > Network Address Server Settings. On OpenWrt, go to Network > DHCP and DNS to set the upstream resolver pushed to all clients. Configuring DNS at the router level is the only way to push a working resolver to iOS devices, which lack per-network DNS settings in the system UI.

How to Confirm the Fix Worked

Run all three checks in sequence before concluding the fix is complete:

1. Ping the gateway — should reply in under 10 ms.
2. Ping 1.1.1.1 — should reply, confirming WAN is up.
3. Run nslookup google.com — should return one or more IP addresses.

Then open a private or incognito browser window and load a site you have not visited recently. If all three commands pass and the page loads fully, the fix is confirmed.

Common Misdiagnoses

Blaming the WiFi password — if your device shows connected status at all, authentication already succeeded. A wrong password prevents the connection from forming entirely; it does not produce connected status with no internet.

Reinstalling drivers — if Windows or macOS shows a signal-strength indicator and connected status, the WiFi driver is working correctly. Driver failures prevent association with the network, not data passing through an established connection. Skip the driver reinstall for this symptom.

"It worked yesterday so it cannot be the router" — routers develop WAN dropout issues gradually from overheating, firmware bugs, or upstream line changes made by the ISP. Always restart the router first regardless of when it last worked normally.

Carrier-Grade NAT (CGNAT) — if your router's WAN IP falls in the 100.64 through 100.127 range, your ISP is using CGNAT. This is normal and does not prevent internet access. General browsing and streaming work fine under CGNAT; only inbound port forwarding fails without a static IP upgrade from your ISP.

VPN client interference — an active VPN can produce exactly this symptom if the VPN server is unreachable, if the tunnel is blocked by the local network, or if the VPN client has left stale routes in the routing table. Disconnect the VPN completely, test connectivity, then reconnect to isolate whether the VPN is the cause.

2026 Update: IPv6, Encrypted DNS, and DNSSEC

IPv6-only WAN — some ISPs, particularly those using home gateway devices on mobile-derived infrastructure, now provision IPv6 WAN addresses only. If your router's WAN status page shows an IPv6 address but no IPv4, and your internal devices only have RFC 1918 IPv4 addresses, IPv6-capable destinations will load while IPv4-only sites fail intermittently. Check your router's WAN configuration for IPv6 passthrough or prefix delegation settings and verify the ISP has provisioned your account for dual-stack if needed.

Encrypted DNS failures — Firefox, Chrome, and Android 9 and later use DNS over HTTPS or DNS over TLS by default. Some corporate and hotel networks block outbound port 853 (DoT) or restrict HTTPS to non-approved resolver addresses. When encrypted DNS is blocked, the browser or OS may fall back to a broken system resolver and the symptom is DNS failure that disappears when Private DNS or DoH is disabled. To test on Android: Settings > Network and internet > Advanced > Private DNS > set to Off temporarily. In Firefox: Settings > Privacy and Security > DNS over HTTPS > Off.

DNSSEC validation failures — if a domain has a broken DNSSEC signature chain, a validating resolver returns SERVFAIL rather than the actual records. The domain loads fine from non-validating resolvers but fails on resolvers with strict validation enabled. This is indistinguishable from general DNS failure unless you compare resolvers. Use our DNS Lookup tool to query the same domain from multiple resolvers — if some return records and others return SERVFAIL, DNSSEC misconfiguration is almost certainly the issue and the domain owner needs to fix their zone signing.