Wi-Fi Connected but No Internet in Windows 11: Diagnose DHCP, DNS, Gateway, Adapter, and Router Problems

When Windows shows that the PC is connected to a Wi-Fi network, the wireless adapter has associated with an access point and the local link exists. That alone does not prove that the PC received a usable IP configuration, can reach its default gateway, can route traffic beyond the local network, can resolve DNS names, or can reach a particular website or service. Microsoft explicitly distinguishes the “No Internet” state from being disconnected from Wi-Fi.

Treat the symptom as a chain. First establish whether the failure affects only this PC or the whole network. Then inspect the Windows IP configuration, prove local gateway reachability, test broader IP connectivity, and only then isolate name resolution. This ordering prevents a browser failure from being misdiagnosed as DNS before basic network reachability has been established.

Connect another phone, laptop, or other device to the same Wi-Fi network and test internet access. Microsoft recommends this split because a second device that works on the same network makes a PC-specific problem more likely, while several devices losing internet access at the same time shifts attention toward the router, modem or upstream ISP connection.

Do not over-interpret the result. A second device may use a different Wi-Fi band, DNS path, VPN, or cached content, and some routers isolate clients or apply device-specific policy. Still, this is a high-value early branch because it tells you whether to spend the next steps primarily inside Windows or on the shared network path.

Open Command Prompt and run `ipconfig /all`. Microsoft documents that `ipconfig` displays IPv4 and IPv6 addresses, subnet information, and the default gateway, while `/all` exposes the fuller TCP/IP configuration. On a DHCP-managed home or office network, inspect the active Wi-Fi adapter for an address, default gateway, DHCP state, and DNS servers instead of assuming a particular private subnet or router address.

A 169.254.x.x IPv4 address is useful evidence when the network normally uses DHCP: Microsoft notes that this state can mean Windows did not obtain an IPv4 address from the router and is using automatic private addressing instead. That points toward the DHCP path, but it is not proof that the router itself is broken. The adapter, VLAN or access-point path, DHCP service, static/manual settings, or other local configuration can produce similar symptoms.

If `ipconfig /all` shows a default gateway for the active Wi-Fi adapter, test reachability to that exact address rather than using a guessed router IP. A successful response is evidence that the PC can at least reach the local gateway over the current path. A failure means the problem is still local enough that changing public DNS servers is unlikely to fix the root cause.

If the gateway is reachable, test a known external IP address that you have a legitimate reason to use in your environment, or use another supported diagnostic path from your router or organization. The goal is not to prescribe one universal public IP target. It is to separate “the PC cannot leave the LAN” from “IP routing works but name-based access is failing.” Some networks or endpoints intentionally block ICMP, so a failed ping is evidence to combine with other checks rather than absolute proof of an outage.

If the PC has a valid address and gateway and can reach destinations by IP but normal hostnames fail, DNS becomes a stronger branch. Microsoft recommends checking that DNS servers are actually configured and using the listed server addresses for troubleshooting rather than assuming a hard-coded public resolver. Windows can obtain DNS settings automatically through DHCP or use manually configured values.

`ipconfig /flushdns` clears the local DNS resolver cache; Microsoft documents it specifically for troubleshooting name-resolution problems. It does not repair a broken Wi-Fi link, create a missing default gateway, or restore an unreachable DNS server. Likewise, changing to a different DNS service should be a targeted test after the existing resolver path is implicated, not a default fix for every “no internet” symptom.

For an adapter that is configured to obtain addressing automatically, Microsoft documents `ipconfig /release` and `ipconfig /renew` as the commands that discard and renew DHCP-assigned configuration. Use them when the evidence points to stale or failed DHCP state; they temporarily remove the current automatic IPv4 configuration while the renewal occurs, so do not run them blindly on a manually addressed network.

On hotel, campus, café, or other managed Wi-Fi, a captive portal can leave the radio associated while web access still requires sign-in or policy acceptance. Also inspect Windows proxy and VPN settings if the problem is isolated to this PC. Microsoft documents proxy traffic as an intermediary path and VPNs as a separate configured network path; an incorrect or unreachable intermediary can therefore affect internet access even while the underlying Wi-Fi link remains connected.

If the problem began immediately after a Windows, OEM, or wireless-driver change and the same network works for other devices, the adapter/driver branch becomes more credible. Check Device Manager for the exact Wi-Fi adapter and its status, then prefer the PC or adapter manufacturer’s supported package. Microsoft also documents uninstalling and reinstalling a network adapter driver when earlier connection steps fail, with the warning to obtain a backup driver first if the PC cannot get online.

If a previous driver version was known to work and Windows still retains it, use the existing Core Tech Tips Windows 11 driver-rollback procedure rather than treating Wi-Fi as a special exception. Do not use generic driver-updater utilities, force unrelated INF packages, or disable driver-signature protections to make an older package install.

Work from least disruptive to most disruptive: reconnect Wi-Fi, compare another device, inspect `ipconfig /all`, test the actual gateway, separate IP reachability from DNS, renew DHCP only when appropriate, inspect proxy/VPN or captive-portal state, and then investigate the adapter and driver. Restarting the router can be reasonable when several devices are affected, but preserve any ISP- or organization-specific configuration and avoid a factory reset unless the device owner or provider explicitly requires it.

Microsoft describes Windows Network reset as a last-step option because it removes installed network adapters and their settings, reinstalls the adapters after restart, and can require VPN clients or Hyper-V virtual switches to be set up again. Use it only after narrower evidence-led steps fail. After any fix, verify the actual outcome: confirm normal addressing, gateway reachability, DNS resolution, and the applications that originally failed instead of stopping when the Wi-Fi icon merely changes.