Websites do not load but Windows says you are connected

The network icon says you are connected, maybe with a small globe and “No internet”, maybe without. The browser shows “This site can’t be reached”, DNS_PROBE_FINISHED_NXDOMAIN or “Hmm, we can’t reach this page”. Restarting things at random sometimes helps, but it does not tell you what was wrong, and the same problem returns.

A connection works in layers: the adapter needs an address, the router must answer, the internet must be reachable, names must resolve, and a proxy or a hotel login page can still stand in the way. This guide tests each layer in order with built-in PowerShell commands, so the first layer that fails tells you where the problem is. The outcome is a specific answer, such as “the internet works, but the router’s DNS has stopped”, and the fix that matches it.

Every diagnostic command here runs as a standard user and changes nothing. The few fixes that change settings are marked. The commands were checked in PowerShell 7.6 on Windows 11; Steps 2 and 6 need PowerShell 7; in Windows PowerShell 5.1 use Test-Connection -ComputerName 192.168.1.1 -Count 4 for Step 2. Example output uses typical home-network addresses; yours will differ.

Step 1: Which adapter is in use, and does it have an address?

Get-NetIPConfiguration |
  Where-Object { $_.IPv4DefaultGateway -or $_.IPv6DefaultGateway } |
  Select-Object InterfaceAlias,
    @{ Name = 'IPv4'; Expression = { $_.IPv4Address.IPAddress } },
    @{ Name = 'Gateway'; Expression = { $_.IPv4DefaultGateway.NextHop } },
    @{ Name = 'DNS'; Expression = { $_.DNSServer.ServerAddresses -join ', ' } } |
  Format-List

InterfaceAlias : Wi-Fi
IPv4           : 192.168.1.42
Gateway        : 192.168.1.1
DNS            : 192.168.1.1

Read it like this:

• No output at all: no adapter has a default gateway. Either nothing is connected, or the adapter did not get a configuration. Run Get-NetIPConfiguration without the filter to see every adapter.
• An address starting with 169.254.: Windows gave itself a link-local address because no DHCP server answered. The problem is between you and the router: Wi-Fi association, a cable, or the router’s DHCP service.
• A gateway and DNS servers listed: this layer works. Note the gateway and the DNS servers; the next steps use them.

If you have several adapters (Wi-Fi and Ethernet, a VPN, Hyper-V or WSL virtual switches), check which one Windows actually uses to reach the internet:

Find-NetRoute -RemoteIPAddress 1.1.1.1 | Select-Object -Last 1 InterfaceAlias, NextHop

InterfaceAlias NextHop
-------------- -------
Wi-Fi          192.168.1.1

If that names a VPN adapter, the VPN carries your traffic, and the rest of these tests describe the VPN path, not your local connection. Virtual adapters named vEthernet (...) belong to Hyper-V and WSL and are normal.

Step 2: Does the router answer?

Test-Connection -TargetName 192.168.1.1 -Count 4

   Destination: 192.168.1.1

Ping Source           Address                   Latency BufferSize Status
                                                   (ms)        (B)
---- ------           -------                   ------- ---------- ------
   1 LAPTOP           192.168.1.1                     2         32 Success
   2 LAPTOP           192.168.1.1                     1         32 Success

Use the gateway from Step 1. Success with a few milliseconds means the local network works. TimedOut on every attempt points at the local link (Wi-Fi signal, cable, the router itself), unless the router is configured to ignore ping. Many routers answer on their web interface even when they ignore ping, so test that before blaming the router:

Test-NetConnection -ComputerName 192.168.1.1 -Port 80

TcpTestSucceeded : True means the router is there.

Step 3: Is the internet reachable without DNS?

This is the most useful single test, because it separates “the internet is down” from “names do not resolve”. Connect to two well-known public servers by IP address, so no name lookup is involved:

Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Test-NetConnection -ComputerName 9.9.9.9 -Port 443

ComputerName     : 1.1.1.1
RemoteAddress    : 1.1.1.1
RemotePort       : 443
InterfaceAlias   : Wi-Fi
SourceAddress    : 192.168.1.42
TcpTestSucceeded : True

1.1.1.1 is Cloudflare’s public resolver and 9.9.9.9 is Quad9’s; both accept connections on port 443. TcpTestSucceeded : True for either one means your connection reaches the internet. A failure prints warnings such as TCP connect to (1.1.1.1 : 443) failed and Ping to 1.1.1.1 failed with status: TimedOut.

• Both fail, while the router answered in Step 2: the problem is beyond your computer: the router’s internet connection, the modem, the line or the provider. Check the router’s status page or lights, and the provider’s outage page from your phone.
• One works: the internet works. A single unreachable server is not an outage.

Step 4: Do your DNS servers answer?

DNS turns names into addresses. Ask Windows’ resolver first, then ask each configured DNS server directly, then a public resolver as a control:

Resolve-DnsName -Name www.msftconnecttest.com -Type A -DnsOnly
Resolve-DnsName -Name www.msftconnecttest.com -Type A -DnsOnly -Server 192.168.1.1 -QuickTimeout
Resolve-DnsName -Name www.msftconnecttest.com -Type A -DnsOnly -Server 1.1.1.1

-DnsOnly asks the DNS servers rather than the hosts file and other name sources; -Server sends the question to one server; -QuickTimeout gives up sooner. A working answer ends in one or more A records with an IP4Address, often after a chain of CNAME aliases (the names and addresses vary by location):

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
www.msftconnecttest.com        CNAME  325   Answer     www.msftconnecttest.com.edgesuite.net
www.msftconnecttest.com.edgesu CNAME  325   Answer     a39.d.akamai.net
ite.net

Name       : a39.d.akamai.net
QueryType  : A
TTL        : 3
Section    : Answer
IP4Address : 203.0.113.153

The errors are specific:

Now combine with Step 3:

• Internet by IP works, your DNS server times out, the public resolver answers: the DNS server is the problem. When it is the router’s own address, its DNS service has often hung; restarting the router usually fixes it.
• Internet by IP works, every DNS server fails including the public one: something is blocking DNS traffic, such as a firewall, security software or a network that only allows its own DNS server.
• Everything answers, but one particular site fails: the site, not your connection. Try it from another network (your phone on mobile data) before changing anything.

Step 5: Is a proxy configured?

A proxy setting nobody remembers (left behind by a former employer, a VPN client or unwanted software) can make browsers fail while everything above works. Read the per-user settings and the system-wide WinHTTP setting:

Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
  Select-Object ProxyEnable, ProxyServer, AutoConfigURL, AutoDetect
netsh winhttp show proxy

ProxyEnable   : 0
ProxyServer   :
AutoConfigURL :
AutoDetect    :

Current WinHTTP proxy settings:

    Direct access (no proxy server).

ProxyEnable : 1 with a ProxyServer, or an AutoConfigURL pointing at a script, means browsers send traffic through that proxy. On a company computer that is usually intended. On a home computer you did not set it up on, find out where it came from before turning it off. The same settings are under Settings > Network & internet > Proxy.

Step 6: Is a login page intercepting the web?

Hotels, trains and cafés often hold all web traffic until you accept terms on a login page (a captive portal). Microsoft runs a test page that always returns the same text, so any other answer means something is in between. This needs PowerShell 7:

$r = Invoke-WebRequest -Uri http://www.msftconnecttest.com/connecttest.txt -MaximumRedirection 0 `
  -SkipHttpErrorCheck -TimeoutSec 10 -ErrorAction SilentlyContinue
[pscustomobject]@{ Status = $r.StatusCode; Location = $r.Headers.Location; Body = "$($r.Content)" }

Status Location Body
------ -------- ----
   200          Microsoft Connect Test

200 with the body Microsoft Connect Test means web traffic reaches the internet unmodified. A 301, 302 or 307 status with a Location pointing somewhere else, or a different body, means a captive portal or filter is answering instead. Open a browser and go to any plain http:// address, such as http://example.com; the login page should appear. In Windows PowerShell 5.1, or if you prefer, just open http://www.msftconnecttest.com/connecttest.txt in a browser and see whether it shows those three words.

Reading the results together

One failed test is a clue, not a verdict. Repeat a failing test once, and check the layer below it before acting.

Fixes that match the cause

Start with the least invasive fix for the layer that failed.

Router DNS or upstream: restart the router (and modem, if separate). Wait until its lights settle, then repeat Steps 3 and 4.

No address (169.254) or a stale address: turn Wi-Fi off and on, or unplug and replug the cable. To ask the DHCP server for a new address:

Warning

ipconfig /renew briefly interrupts every connection on the adapter, which drops calls, downloads and remote sessions. If Windows answers that the operation requires elevation, run it from an elevated terminal.

ipconfig /renew

A stale cached answer after a site moved: ipconfig /flushdns empties the local DNS cache. It runs as a standard user and is harmless.

Your DNS server keeps failing: you can point the adapter at other DNS servers. This is a system-wide change that affects every program, and on company networks or with a VPN it can break internal names, so only do it on a network you manage. Record the current servers first:

Get-DnsClientServerAddress -InterfaceAlias 'Wi-Fi' -AddressFamily IPv4

Warning

Changing DNS servers needs administrator rights. In Windows 11 use Settings > Network & internet > Wi-Fi (or Ethernet) > your network > DNS server assignment > Edit. From an elevated PowerShell, Set-DnsClientServerAddress -InterfaceAlias 'Wi-Fi' -ServerAddresses 1.1.1.1, 9.9.9.9 sets them and Set-DnsClientServerAddress -InterfaceAlias 'Wi-Fi' -ResetServerAddresses returns to the servers DHCP provides.

An unexpected proxy: turn it off under Settings > Network & internet > Proxy only after confirming that neither you nor your organisation configured it.

Verify the fix

Repeat the checks that failed, in order. You are done when Step 3 succeeds, Step 4 returns A records from the resolver Windows uses, Step 6 returns 200 and Microsoft Connect Test, and the site that failed opens in the browser. If the problem comes and goes, the last result is not proof it is fixed; repeat the tests the next time it happens, before restarting anything, because a restart erases the evidence.

NetDoctor: the same order, with the reasoning written down

The checks above are what NetDoctor automates, in the same bottom-up order: adapters, the route Windows would use, addressing, gateway, configured DNS servers, a public DNS comparison, the internet by IP address, proxy configuration, HTTP and HTTPS, and captive-portal detection. Instead of six outputs to combine, it ends with one verdict, such as “The internet works, but your DNS servers are not answering”, with its confidence, the evidence it rests on, alternative explanations it could not rule out, and what you can check yourself. It handles the cases that make manual testing confusing: several adapters, VPNs that carry only part of the traffic, routers that ignore ping, and proxy scripts.

NetDoctor never changes a setting and has no “fix it” button, needs no administrator rights, and lists every destination it will contact before it sends anything (netdoctor probes). The desktop app shows the same list on screen before you press Start. NetDoctor is in development: the engine, the command line and the desktop app are implemented and tested internally, but there is no public download yet. The NetDoctor page tracks its status.