No Internet Access and Unidentified Network in Windows

The globe icon with a slash, the “No internet” label, and the “Unidentified network” name all come from the same place: Windows running a test and reporting the result. The test is not a measurement of whether packets can leave the machine. It is a check of two specific things, and when either check fails the icon changes regardless of whether the connection would otherwise work. Understanding what is being tested separates a real fault from a cosmetic one.

The Network Connectivity Status Indicator (NCSI) requests a small text file from a Microsoft address and performs a DNS lookup of a Microsoft name. If the file arrives with the expected content and the name resolves, Windows marks the connection as having internet access. If either step fails, the connection is marked as having no internet access even when the adapter has a valid address, a working gateway, and can reach other hosts. The reverse also happens: a captive portal answers the probe with a redirect, and Windows reports that sign-in is needed and offers to open the portal page in a browser.

“Unidentified network” is a separate verdict. Windows assigns a network profile (Public or Private) based on the gateway and network details it receives. When no default gateway is present, or the gateway does not respond in the expected way, the profile cannot be classified and the network is labelled unidentified. That label is usually accurate about the gateway and says nothing about DNS or the wider internet.

Reading the verdict before changing anything

Start with the adapter state. Open Command Prompt and run:

ipconfig /all

The output lists each adapter with its IPv4 address, subnet mask, default gateway, and DNS servers. Read it as three separate facts.

An address in the 169.254.x.x range means the adapter asked for a lease over DHCP and received nothing. The machine assigned itself a link-local address as a fallback. There is no gateway in this case, which explains both the unidentified network label and the no internet verdict. The fault is at the DHCP layer: the router’s DHCP service, the cable, the wireless association, or a static configuration left on the adapter.

A valid address with a gateway listed but no response from that gateway points to the local link or the router itself. A valid address, a responsive gateway, and a failure to resolve names points to DNS. A valid address, a responsive gateway, working DNS, and a failed probe points to filtering between the machine and the Microsoft address.

Tracing the fault one layer at a time

Each test below answers one question. Run them in order; the first failure identifies the layer and the later tests become unnecessary.

ping <default gateway address>

A reply confirms the machine can reach the router. Request timed out or Destination host unreachable means the local link is not carrying traffic: check the cable, the wireless association, or whether the router is powered and serving that interface.

ping 8.8.8.8

A reply to a public address confirms routing past the router. Failure here with a working gateway means the router is not forwarding, the upstream link is down, or the carrier has suspended the connection. This is the point where the equipment stops being yours to repair.

nslookup www.msftconnecttest.com

A resolved address confirms DNS. A timeout or a can’t-find reply means name resolution is failing while raw IP traffic may still work. Test with a public resolver to separate a dead local resolver from a dead uplink:

nslookup www.msftconnecttest.com 1.1.1.1

If the public resolver answers and the configured one does not, the DNS server address handed out by DHCP is wrong or the local resolver is down.

curl -v http://www.msftconnecttest.com/connecttest.txt

This requests the same file NCSI uses. A body of “Microsoft Connect Test” confirms the probe path works and the icon should be green. A timeout or a redirect to a sign-in page explains a no internet verdict on an otherwise working connection. The redirect case is a captive portal; complete the sign-in in a browser. The timeout case usually means a proxy, firewall, or content filter is blocking that address.

Which layer owns the fault

Repairs, least destructive first

Release and renew the lease. This discards the current address and asks the DHCP server for a new one; it destroys nothing on disk.

ipconfig /release

ipconfig /renew

Flush the DNS resolver cache. This clears cached name mappings only.

ipconfig /flushdns

Reset the Winsock catalog and the TCP/IP stack. These restore default network configuration and remove any per-application Winsock entries. They do not touch user files, but a static IP configuration on the adapters may be lost and need re-entering.

netsh winsock reset

netsh int ip reset

A restart is required after the Winsock reset. If the adapter still holds a link-local address after renewal, confirm the adapter is set to obtain an address automatically rather than carrying a stale static entry. That setting lives in the adapter’s IPv4 properties; there is no single command that inspects it reliably across Windows versions, so check it in the interface.

If the probe alone fails while every other test passes, inspect the proxy configuration. A proxy set for the user (the one shown in Settings and used by browsers) and the proxy used by system services (WinHTTP) are separate settings, and either can be the one in the way. The WinHTTP setting is shown with:

netsh winhttp show proxy

A proxy listed here that no longer exists blocks services that use WinHTTP. Clearing it restores direct access:

netsh winhttp reset proxy

This removes the system proxy configuration. Any legitimate proxy the network requires must be re-entered afterwards.

What people get wrong about this

The natural reading of the globe icon is that the internet is down. That reading is wrong often enough to matter, and it is a reasonable mistake because the icon is presented as a status of the connection rather than a status of one HTTP request. A machine behind a corporate proxy, a content filter, or a firewall that blocks the Microsoft test address will show no internet access while browsing works normally. The user then resets the network stack, reinstalls the adapter, and changes DNS servers, none of which touch the actual cause. The correct first move is the curl test above: if the file arrives, the connection is fine and the icon is reporting a blocked probe.

The second common error is treating “Unidentified network” as a DNS problem. It is almost always the absence of a default gateway, which is a DHCP or link-layer issue. Changing DNS servers on an unidentified network changes nothing, because the machine has no route to send those queries through.

The third is assuming a repair is available when the fault is upstream. If the router has a valid WAN address but cannot reach a public address, or the carrier has suspended the line, no setting on the Windows machine will restore service. The router’s status page and the carrier’s own support channel are the correct next steps, and the machine’s configuration should be left alone.

When the fault is not on the machine

A connection that fails at the ping to 8.8.8.8 while the gateway responds is failing beyond the router. Check the router’s administrative page for WAN status, line sync, and any account notice. If the router reports no upstream connection, the fault belongs to the carrier. If the router reports a connection but no traffic passes, the ISP’s routing or the account state is the likely cause. In both cases the Windows machine is configured correctly and further changes to it will not help.

A connection that works for every test except the NCSI probe, on a network the reader does not administer, is a policy decision made by whoever runs that network. The probe address is blocked deliberately in some environments. The connection is usable; the icon is not.