Why does Windows say no internet when it is connected?
Windows shows "No internet" when its connectivity probe fails: it fetches http://www.msftconnecttest.com/connecttest.txt and resolves dns.msftncsi.com, and if either fails the icon changes, whatever else is working. So the message means the probe failed, which is narrower than the internet being down.
Find where the path breaks with ipconfig /all (a 169.254 address means no DHCP lease), ping <default gateway>, ping 8.8.8.8, then nslookup www.msftconnecttest.com. If all of those pass, it is a captive portal, a proxy, a stray adapter owning the default route, or a web filter blocking the two probe hostnames.
Wi-Fi or Ethernet shows connected, the globe icon or "No internet, secured" appears, and some things work while others do not. It is the most common desk ticket. The message says less than it seems to.
Windows decides whether the internet is up with the Network Connectivity Status Indicator (NCSI). It fetches http://www.msftconnecttest.com/connecttest.txt and expects the exact text "Microsoft Connect Test". It resolves dns.msftncsi.com expecting the address 131.107.255.255. If either probe fails, Windows shows "No internet" even when other traffic is flowing. The message means "the probe failed". Sometimes that is because the internet is down, and sometimes it is not. The sequence below tells the two apart.
Step 1: does the machine have an address?
Run ipconfig /all. An IPv4 address starting with 169.254 means there is no DHCP lease: the machine never got an address from the router. The fault is the cable, the switch port, the Wi-Fi association, or the DHCP server. Nothing further down the chain matters yet. Run ipconfig /release then ipconfig /renew to ask for a new lease.
Check the DNS servers in the output against what the site should have. A rogue DHCP server or a leftover static entry shows up here.
Step 2: can it reach the gateway?
ping <default gateway>. No reply means the problem is on the local network (cable, switch, Wi-Fi, VLAN), not the internet. Forget and rejoin the Wi-Fi network, or try another cable and port, before looking any further.
Step 3: is it DNS?
ping 8.8.8.8 or Test-NetConnection 8.8.8.8 -Port 443. If that works but names do not resolve, the internet path is open and the name server is the problem. Confirm with nslookup www.msftconnecttest.com and nslookup dns.msftncsi.com. If they fail, try nslookup www.msftconnecttest.com 8.8.8.8 to see whether the site's own DNS server is what is broken. ipconfig /flushdns clears a stale cache. A dead site DNS server is a ticket for whoever runs it.
Step 4: is there a captive portal?
Open a browser to a plain http site. A hotel, cafe or guest network redirects you to a login page. Until the user accepts it the probe fails while the browser looks fine. Accept the portal and the icon corrects itself within seconds.
Step 5: is a proxy or a stray adapter in the way?
Run netsh winhttp show proxy and check Settings > Network & internet > Proxy. A proxy set by a VPN client, malware, or an old policy that no longer exists breaks the probe while some apps still work. Clear it.
Check the adapters. A VPN adapter, a virtual switch left behind by Docker, VirtualBox or Hyper-V, or a second Ethernet adapter with a higher priority can capture the default route. route print shows which interface owns 0.0.0.0. Disable the extra adapter to test, and remove leftover VPN clients for good.
Step 6: reset the stack
If the machine still misbehaves after the previous checks: run netsh winsock reset, then netsh int ip reset, then reboot. This repairs the TCP/IP stack and is safe, but it clears static IP settings, so note them first. If the fault started with a driver update, reinstall the network driver from the manufacturer rather than Windows Update.
Step 7: is it the whole site?
If several machines fail at the same time, stop troubleshooting machines. Check the router or firewall's WAN status, the ISP status page, and whether a firmware update or a new filtering rule went in. One tech can burn an hour on a workstation for a fault that is at the ISP.
When the message is wrong and the internet is fine
A web filter or firewall at the client site blocks msftconnecttest.com or dns.msftncsi.com, so every machine on the site shows "No internet" while everything works. Allow-list those two hostnames on the filter.
Outlook, Teams and the Microsoft Store refuse to try when NCSI reports no internet. The registry value EnableActiveProbing under HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet switches the probe off; leave it alone, because it hides real failures.
When a machine shows "No internet" but the Moorfox agent is still checking in, the fault is the probe or DNS rather than the connection, and the remote terminal runs this whole sequence without asking the user to read screens out over the phone. When the agent is offline as well, the site view shows whether it is one machine or all of them.
Frequently asked questions
What does "No internet, secured" mean?
The machine is joined to an encrypted Wi-Fi network, and the Windows internet probe failed. The link is up; what Windows could not do is fetch its test page or resolve its test name.
Why does the internet work but Windows says it does not?
Usually a web filter or firewall at the site is blocking msftconnecttest.com or dns.msftncsi.com, or a proxy left behind by a VPN client or an old policy is in the way of the probe while browsers cope. Allow-list the two probe hostnames on the filter.
Is netsh winsock reset safe?
Yes. It rebuilds the Winsock catalogue and, with netsh int ip reset, the TCP/IP configuration. Reboot afterwards, and note any static IP settings first because they are cleared.
Why do I get a 169.254 address?
The machine asked for a DHCP lease and nothing answered, so it gave itself one. The fault is between the machine and the DHCP server: the cable, the switch port, the Wi-Fi association, or the DHCP service itself.