You’re on Wi‑Fi. Signal bars look smug. Ethernet lights are blinking like a Christmas tree. Yet Windows insists: Connected, no internet. Teams won’t sign in, the browser spins, and your colleagues develop sudden opinions about “just reinstalling Windows.”
Don’t. “Reset network” is a blunt instrument that deletes VPN profiles, custom DNS, 802.1X certs, and whatever else your workplace spent years making brittle. You want the scalpel: isolate whether this is real connectivity loss or a Windows detection problem, then fix the specific layer that’s lying.
Fast diagnosis playbook (first 3 minutes)
This is the order I use when someone pings “internet down” and I need the truth fast. We’re hunting the bottleneck: link, IP, route, DNS, policy, or Windows’ own connectivity detection.
1) Is the network actually down, or is Windows just complaining?
- Open a browser to a known HTTPS site. If it loads, your internet works; Windows’ status might be wrong (often NCSI/proxy/VPN). Move to the NCSI/proxy checks.
- Try an IP ping (like a public DNS IP). If IP works but names don’t, it’s DNS.
2) Confirm you have an IP, gateway, and sane routes
- Check IP config: do you have a non-APIPA address (not 169.254.x.x), a default gateway, and DNS servers?
- Check route table: is there a default route (0.0.0.0/0) to the right interface?
3) Decide which layer is broken
- No IP / APIPA: DHCP or L2 issue.
- IP but no default route: gateway/route problem, often VPN metric, ICS, or adapter confusion.
- IP + route but DNS fails: DNS server unreachable, DoH/NRPT/policy, or captive portal interception.
- Everything works except Windows status: NCSI blocked/modified by proxy, firewall, or hardening.
Do not “reset everything” until you can say which one of these is failing. Otherwise you’re just adding entropy. Entropy always wins; it has better funding.
What “Connected, No Internet” actually means
Windows shows “Connected, no internet” when it believes your network path to the public internet is broken. That belief is partly based on NCSI (Network Connectivity Status Indicator), a component that performs connectivity checks.
Two key points that save hours:
- The message can be wrong. You can have working internet while Windows claims you don’t (common with proxies, VPNs, strict firewalls, and some DNS filtering).
- The message can be right for the wrong reason. For example, your local network works fine, but DNS is broken—Windows labels it “no internet,” and many apps then behave as if you’re offline.
Under the hood, Windows cares about several layers:
- Layer 1–2: link status (Wi‑Fi association, Ethernet link).
- Layer 3: IP address, subnet, default gateway, and routing.
- Layer 4–7: DNS reachability, HTTP/HTTPS access (including captive portal detection), proxy behavior.
- Policy and security: firewall rules, VPN kill switches, enterprise endpoint security, and “helpful” tuning.
One quote worth keeping in your pocket when you’re tempted to shotgun fixes: “Hope is not a strategy.”
— Gene Kranz
Joke #1: Windows networking is like a committee meeting—everyone has an opinion, and none of them talk to each other.
Interesting facts and historical context (why this keeps happening)
These are short, concrete facts that make the “connected, no internet” problem less mystical and more predictable:
- NCSI arrived with Vista-era networking changes. Windows began actively probing for internet connectivity instead of just trusting link status.
- “No Internet, secured” is mostly Wi‑Fi security, not internet security. The “secured” label refers to the Wi‑Fi link encryption (WPA2/WPA3), not whether the internet path is usable.
- Captive portals intentionally break normal behavior. Many hotel/guest networks intercept DNS/HTTP until you accept terms; modern HTTPS makes that messier.
- APIPA (169.254.0.0/16) is Windows’ “I failed DHCP” fallback. It keeps local-link communication possible but usually means no gateway, no internet.
- WPAD auto-proxy discovery has been a corporate staple—and a recurring headache. Misconfigured WPAD can break browsing while pings still work.
- VPN “kill switches” are designed to cause outages. Their job is to block traffic if the tunnel is down, and they often look exactly like “no internet.”
- Windows maintains per-interface metrics for route preference. A “faster” interface or VPN can steal the default route even when it shouldn’t.
- DNS caching is both a performance feature and a failure amplifier. Bad answers can persist until TTL expiry or cache flush.
- IPv6 is frequently blamed, often incorrectly. Broken IPv6 on a network can hurt, but disabling it is a crude workaround that can break modern enterprise setups.
Practical tasks with commands: what to run, what it means, what to do next
These tasks are designed to be runnable on a Windows machine, but I’m presenting them in a terminal-style transcript so you can copy the commands exactly. Each task includes: command, example output, what it means, and the decision you make next.
Task 1: Check IP, gateway, and DNS in one shot
cr0x@server:~$ ipconfig /all
Windows IP Configuration
Ethernet adapter Ethernet:
Connection-specific DNS Suffix . : corp.example
Description . . . . . . . . . . . : Intel(R) Ethernet Connection
Physical Address. . . . . . . . . : 00-11-22-33-44-55
DHCP Enabled. . . . . . . . . . . : Yes
IPv4 Address. . . . . . . . . . . : 10.24.18.73(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.252.0
Default Gateway . . . . . . . . . : 10.24.16.1
DHCP Server . . . . . . . . . . . : 10.24.16.10
DNS Servers . . . . . . . . . . . : 10.24.0.53
10.24.0.54What it means: You have a real IPv4 address, a gateway, and DNS servers. If internet is still “down,” the problem is likely routing, DNS reachability, proxy/VPN, firewall, or NCSI.
Decision: If you see 169.254.x.x or no default gateway, jump to DHCP/L2 fixes. If DNS servers are blank or weird (like an old static IP), fix that first.
Task 2: Detect APIPA (DHCP failure) quickly
cr0x@server:~$ ipconfig
Windows IP Configuration
Ethernet adapter Ethernet:
IPv4 Address. . . . . . . . . . . : 169.254.77.12
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :What it means: DHCP didn’t hand you an address. You’re self-assigning. This is not an “internet problem”; it’s an “I never got on the network” problem.
Decision: Check cable/Wi‑Fi auth/VLAN, then renew DHCP. If this is corporate, suspect 802.1X or a switch port profile.
Task 3: Renew DHCP lease (without resetting the world)
cr0x@server:~$ ipconfig /release
Windows IP Configuration
No operation can be performed on Ethernet while it has its media disconnected.What it means: Windows thinks the interface is disconnected (or the cable is out, or Wi‑Fi is off). That’s your first failure mode: link.
Decision: Fix physical link / Wi‑Fi association before you do anything clever.
cr0x@server:~$ ipconfig /renew
Windows IP Configuration
Ethernet adapter Ethernet:
Connection-specific DNS Suffix . : corp.example
IPv4 Address. . . . . . . . . . . : 10.24.18.73
Subnet Mask . . . . . . . . . . . : 255.255.252.0
Default Gateway . . . . . . . . . : 10.24.16.1What it means: DHCP succeeded. You’re back in business at L3.
Decision: If internet still fails, move on to routing/DNS/proxy checks.
Task 4: Ping the default gateway (is your local network alive?)
cr0x@server:~$ ping 10.24.16.1
Pinging 10.24.16.1 with 32 bytes of data:
Reply from 10.24.16.1: bytes=32 time=1ms TTL=64
Reply from 10.24.16.1: bytes=32 time=1ms TTL=64
Ping statistics for 10.24.16.1:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss)What it means: Your host can reach the gateway. L2/L3 on the local segment looks good.
Decision: If gateway ping fails, investigate Wi‑Fi isolation, VLAN mismatch, bad switch port, or local firewall rules blocking ICMP (less common on gateways, but possible).
Task 5: Ping an external IP (bypass DNS)
cr0x@server:~$ ping 1.1.1.1
Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=18ms TTL=56
Ping statistics for 1.1.1.1:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss)What it means: Routing to the internet works at least for ICMP. If websites fail, it’s likely DNS, proxy, TLS interception, or firewall.
Decision: Immediately test DNS resolution and HTTPS connectivity next.
Task 6: DNS resolution test (simple and decisive)
cr0x@server:~$ nslookup example.com
Server: dns1.corp.example
Address: 10.24.0.53
Non-authoritative answer:
Name: example.com
Addresses: 93.184.216.34What it means: DNS is responding and returning sensible data.
Decision: If DNS is good but browsing fails, suspect proxy/VPN/firewall or certificate issues. If nslookup times out, suspect DNS reachability or policy.
cr0x@server:~$ nslookup example.com 8.8.8.8
Server: dns.google
Address: 8.8.8.8
DNS request timed out.
timeout was 2 seconds.What it means: Your network may block public DNS (common in enterprises and some ISPs), or you can’t reach that resolver due to routing/VPN rules.
Decision: Don’t “fix” by hardcoding public DNS on a corporate network unless you enjoy support tickets. Instead, fix access to the intended DNS servers.
Task 7: Check the route table for a default route
cr0x@server:~$ route print
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.24.16.1 10.24.18.73 25
10.24.16.0 255.255.252.0 On-link 10.24.18.73 281What it means: You have a default route via your gateway. Good.
Decision: If the 0.0.0.0 route is missing or points to a VPN interface unexpectedly, you’ve found your culprit.
Task 8: Verify which interface Windows prefers (metrics matter)
cr0x@server:~$ netsh interface ipv4 show interfaces
Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
12 5 1400 connected CorpVPN
10 25 1500 connected EthernetWhat it means: Lower metric wins. Here, the VPN is preferred and may be stealing default routing.
Decision: If the VPN is down/half-up or blocked, disconnect it or fix split tunneling policy. If this is intentional, stop here and escalate to whoever owns the VPN config.
Task 9: Check WinHTTP proxy settings (the invisible kind)
cr0x@server:~$ netsh winhttp show proxy
Current WinHTTP proxy settings:
Proxy Server(s) : 127.0.0.1:8080
Bypass List : (none)What it means: System services (including some Microsoft components) may be trying to reach the internet via a local proxy that might not exist anymore.
Decision: If you didn’t explicitly configure this (or your security agent removed its local proxy), reset WinHTTP proxy to direct.
cr0x@server:~$ netsh winhttp reset proxy
Current WinHTTP proxy settings:
Direct access (no proxy server).What it means: System-level HTTP now goes out directly.
Decision: Re-test NCSI and Microsoft sign-in issues. If corporate policy requires a proxy, don’t “fix” by bypassing—get the correct proxy config.
Task 10: Check user-level proxy (Settings/Internet Options equivalent)
cr0x@server:~$ reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
ProxyEnable REG_DWORD 0x1What it means: User proxy is enabled.
Decision: If you’re not on a network that needs it, disable it. If you are, confirm the proxy server value and bypass list are correct.
Task 11: Test HTTP reachability without a browser (proxy/captive portal clues)
cr0x@server:~$ powershell -NoProfile -Command "Invoke-WebRequest -UseBasicParsing -Uri http://www.msftconnecttest.com/connecttest.txt | Select-Object -ExpandProperty StatusCode"
200What it means: You can reach the HTTP endpoint that Windows often uses for connectivity detection.
Decision: If this returns 200 but Windows still says “no internet,” suspect HTTPS probe issues, DNS manipulation, or NCSI settings/policy.
cr0x@server:~$ powershell -NoProfile -Command "Invoke-WebRequest -UseBasicParsing -Uri http://www.msftconnecttest.com/connecttest.txt | Select-Object -ExpandProperty Content"
Microsoft Connect TestWhat it means: The response content is correct. Captive portals often return an HTML login page instead.
Decision: If you get HTML or redirects, you’re behind a captive portal. Go authenticate (or ask your network team why a “corporate” SSID has one).
Task 12: Flush DNS cache (fix stale/bad answers)
cr0x@server:~$ ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.What it means: Any cached DNS answers are cleared.
Decision: If name resolution suddenly works, your issue was stale cache or a temporary DNS poisoning event (benign misconfig or captive portal). If it changes nothing, keep digging.
Task 13: Reset Winsock (targeted “TCP/IP plumbing” fix)
cr0x@server:~$ netsh winsock show catalog
Catalog entry #0000000001
------------------------------------------------------------
Entry Type: Provider
Description: MSAFD Tcpip [TCP/IP]
...output truncated...What it means: You’re inspecting the Winsock catalog (where LSPs used to hook traffic). Security software sometimes wedges this.
Decision: If you suspect a broken network stack after uninstalling VPN/AV, do a Winsock reset. Expect a reboot.
cr0x@server:~$ netsh winsock reset
Successfully reset the Winsock Catalog.
You must restart the computer in order to complete the reset.What it means: Winsock is reset to defaults.
Decision: Reboot, then re-test. If your corporate endpoint agent depends on an LSP-like component, coordinate with IT before doing this on managed machines.
Task 14: Reset TCP/IP stack (still not “reset everything”)
cr0x@server:~$ netsh int ip reset
Resetting Global, OK!
Resetting Interface, OK!
Resetting Neighbor, OK!
Resetting Path, OK!
Restart the computer to complete this action.What it means: You’ve reset key TCP/IP parameters to defaults.
Decision: This is a good late-stage fix for corruption/misconfig. If you rely on static IPs or custom routes, document them first.
Task 15: Check whether a VPN created persistent routes
cr0x@server:~$ route print -4
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.10.0.1 10.10.0.55 1
10.10.0.0 255.255.0.0 On-link 10.10.0.55 261What it means: Default route points to a 10.10.0.1 gateway (likely a VPN virtual adapter). If the VPN is disconnected but the route remains, you’ll have “no internet” fast.
Decision: Disconnect/reconnect the VPN cleanly, or remove the persistent route if you’re sure it’s wrong. On managed endpoints, escalate; don’t fight your VPN client with a shovel.
Task 16: Check Windows Firewall profile and state
cr0x@server:~$ netsh advfirewall show allprofiles state
Domain Profile Settings:
State ON
Private Profile Settings:
State ON
Public Profile Settings:
State ONWhat it means: Firewall is on (that’s normal). This alone doesn’t explain “no internet,” but rules can.
Decision: If a security product recently changed firewall rules, test by temporarily disabling only if allowed. Prefer reviewing rules or security logs; blind disabling is how you earn a follow-up incident.
Task 17: Check for name resolution policy / NRPT (common with VPN split DNS)
cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptPolicy | Format-Table -AutoSize"
Namespace NameServers DirectAccessDNS
--------- ----------- ---------------
.corp.example {10.24.0.53} FalseWhat it means: Queries for certain namespaces are forced to specific DNS servers. Great when correct; disastrous when the VPN isn’t actually routing to those servers.
Decision: If NRPT points to unreachable DNS, you get “some sites work, some don’t.” Fix the VPN routing or update policy; don’t just rip out NRPT unless you own the policy.
Task 18: Validate which DNS servers are actually in use per interface
cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize"
InterfaceAlias ServerAddresses
-------------- ---------------
Ethernet {10.24.0.53, 10.24.0.54}
CorpVPN {10.99.0.10}What it means: Different adapters can have different DNS servers. Windows might choose the “wrong” DNS for general queries depending on metrics and policies.
Decision: If the VPN DNS is unreachable (tunnel down) but preferred, you’ll experience name failures. Fix metric/preference or fix the tunnel.
Captive portals and corporate Wi‑Fi weirdness
Captive portals are the classic “Connected, no internet” producer because they sit between you and the internet and say, “Sure, you can connect… after you click this checkbox written by a lawyer.” Windows tries to detect this and pop a sign-in page, but modern networks and security tools can block the mechanism.
How to recognize a captive portal (without guessing)
- DNS works, but HTTP returns unexpected content. Your connect test returns HTML rather than the expected plain text.
- HTTPS sites fail with certificate warnings or never load. Portals can’t easily intercept modern HTTPS without doing nasty things.
- Only some apps fail. Apps that use strict TLS pinning will refuse intercepted traffic.
What to do
- Use a plain HTTP URL (yes, on purpose) just to trigger the portal and authenticate. After that, go back to HTTPS like a civilized person.
- Disable VPN temporarily if the portal needs your traffic un-tunneled. Many VPNs block captive portal flows by design.
- Don’t hardcode public DNS to “fix” a portal. Some portals rely on DNS interception; you’ll just make it weirder.
VPNs, proxies, and “security” features that cut your legs off
A lot of “no internet” situations aren’t outages. They’re policy. Policy that’s half-applied, stale, or configured for a network you’re not on anymore.
VPN failure modes that look like “no internet”
- Default route hijack: VPN becomes the preferred route but the tunnel isn’t actually passing traffic.
- Split tunnel DNS mismatch: DNS queries go to VPN DNS, but the VPN doesn’t route to it (or the DNS server blocks you).
- Kill switch engaged: VPN client blocks all traffic when disconnected. That’s not a bug; it’s a feature with sharp edges.
- Stale NRPT policy: Domain suffix lookups forced to unreachable servers, breaking internal apps and sometimes Windows sign-in.
Proxy failure modes that look like “no internet”
- WinHTTP proxy left behind after uninstalling a security tool, so system services can’t reach the web.
- User proxy enabled with the wrong PAC file or dead proxy hostname.
- Auto-detect settings (WPAD) discover a proxy on one network, then keep trying it on another where it doesn’t exist.
Joke #2: A proxy server is like that coworker who insists on being CC’d—until they go on vacation and your email stops working.
Drivers, power saving, and the quiet violence of “optimization”
If you’re on a laptop, there’s a non-zero chance Windows is doing “power management” to your network adapter. Vendors also ship drivers that behave perfectly in a lab and oddly in the real world, especially across sleep/wake cycles.
Failure patterns that scream “driver/power”
- Internet dies after waking from sleep, but a reboot fixes it.
- Ethernet shows connected, but no traffic flows until you disable/enable the adapter.
- Wi‑Fi connects, then drops to “no internet” while signal is strong.
What to do (and what to avoid)
- Prefer rolling back to a known-good driver if the issue started after an update. New isn’t always better; sometimes it’s just newer.
- Avoid disabling IPv6 as a first-line fix. It can mask the symptom while breaking enterprise services, modern DNS behavior, and future troubleshooting.
- Check adapter power settings if the issue is sleep-related. If your corporate image enforces these via policy, fix it centrally.
Three corporate mini-stories from the trenches
1) The incident caused by a wrong assumption: “If DHCP works, internet works”
A mid-size company had a recurring complaint: every few days, a random floor would report “Connected, no internet.” The helpdesk script was predictable: restart the access point, have users reboot, and move on. It “worked,” which is another way of saying nobody learned anything.
When SRE got dragged in, the first assumption they challenged was the classic: DHCP success implies usable network. Users did have addresses, gateways, and DNS. Gateway pings worked. External IP pings worked. DNS also answered. Yet browsers failed.
The missing piece: the corporate proxy was mandatory for web egress, and the proxy relied on a PAC file served from an internal host name. That host name resolved via DNS, but the proxy port itself was intermittently blocked by a misapplied firewall policy on one distribution switch ACL. So the network “worked,” and the internet “worked,” but the web didn’t—and Windows interpreted that as “no internet.”
The fix wasn’t a grand redesign. It was boring: align ACL policies across switches, monitor proxy port reachability, and teach support to test proxy reachability instead of just ping. The wrong assumption had turned a straightforward policy bug into months of “ghost outages.”
2) The optimization that backfired: “Let’s force public DNS for faster lookups”
An IT team got tired of internal DNS latency complaints. Someone proposed a simple optimization: push a GPO that sets clients’ DNS servers to a well-known public resolver “for performance.” It was rolled out quietly, because who needs change management for DNS, right?
Within a day, Windows laptops started reporting “Connected, no internet” in the office—while some websites loaded and internal apps didn’t. The pattern was chaotic: new hires were fine, long-timers were not, and VPN users had the worst time.
The reality: the enterprise firewall blocked outbound DNS to the internet as a policy. Clients forced to public DNS couldn’t resolve anything unless they were on a permissive network. Meanwhile, internal zones that only existed on corporate DNS stopped resolving entirely, breaking sign-in flows, printer discovery, and internal portals. Windows’ connectivity detection also failed because name resolution and HTTP reachability were inconsistent.
The rollback was painful because it had to happen fast and because “just set it back” collided with roaming users and cached configurations. The postmortem conclusion was blunt: don’t optimize a dependency by bypassing the system designed to provide it. Fix internal DNS performance and resilience instead—cache, scale, monitor—without turning clients into little renegade resolvers.
3) The boring but correct practice that saved the day: known-good baselines and two tests
A global org had a small but disciplined networking practice: every office had a documented “known-good” endpoint configuration for Ethernet and Wi‑Fi, plus two standard tests: (1) ping default gateway, (2) resolve and fetch a connectivity test file over HTTP. They weren’t glamorous. They were consistent.
One morning, a site reported “Connected, no internet” across multiple teams. People started blaming the ISP, then blaming Windows updates, then blaming the coffee machine (unfairly). The on-call engineer asked for the two tests. Gateway ping passed. HTTP fetch returned an HTML page instead of expected text.
That immediately narrowed it: captive portal or interception. The office didn’t use a captive portal. Turns out a new security appliance policy had been pushed overnight, redirecting unknown user agents to an authentication splash page. Windows’ NCSI probe was now treated as “unknown” and got redirected, so Windows declared no internet. Some browsers worked because they prompted for authentication differently; some apps failed because they expected clean HTTP responses.
The fix was a one-line allow rule for the connectivity check endpoints and a policy exception for enterprise-managed clients. The reason it was resolved quickly wasn’t genius. It was the existence of a baseline and two tests that separated “network down” from “detection broken” in minutes.
Common mistakes: symptom → root cause → fix
These are the repeat offenders. Read them like a field guide.
1) “Connected, no internet” but websites load fine
- Symptom: Browser works; Windows tray says no internet; some Microsoft apps complain.
- Root cause: NCSI probes blocked/redirected by proxy, firewall, DNS filtering, or captive portal detection failing.
- Fix: Test the connect test file via PowerShell. Check WinHTTP proxy. If corporate, request allowlisting for NCSI endpoints and proper proxy config.
2) IP address is 169.254.x.x
- Symptom: Local connection shows connected; no internet; sometimes “Unidentified network.”
- Root cause: DHCP failure (no response, blocked, wrong VLAN, 802.1X failure).
- Fix: Renew DHCP; check link; try another port/SSID; in corporate, validate switch port profile and authentication logs.
3) Ping to 1.1.1.1 works, but DNS fails
- Symptom: IP connectivity exists;
nslookuptimes out. - Root cause: DNS server unreachable, blocked outbound DNS, wrong DNS server set, VPN DNS selected with tunnel down.
- Fix: Check
ipconfig /allandGet-DnsClientServerAddress. Correct DNS to what the network expects; fix VPN routing/metrics.
4) Only internal sites fail, public internet works
- Symptom: Google loads; internal portal doesn’t; VPN sometimes involved.
- Root cause: Split DNS/NRPT misconfiguration, or internal DNS only accessible via VPN.
- Fix: Connect VPN properly; verify NRPT policies and DNS reachability; don’t “fix” by using public DNS.
5) Internet dies after sleep/hibernate
- Symptom: Works after reboot; fails after wake; disabling/enabling adapter helps.
- Root cause: Driver bug or adapter power management, sometimes compounded by VPN service state.
- Fix: Update or roll back driver; disable aggressive power saving for the adapter; ensure VPN client handles resume.
6) “No internet” appears only when VPN is installed (even disconnected)
- Symptom: Removing VPN “fixes it”; otherwise routing is weird.
- Root cause: Persistent routes, filter drivers, or a kill switch still active.
- Fix: Inspect route table and interface metrics; repair or reinstall VPN client cleanly; escalate if kill switch policy is enforced.
7) Ethernet says connected, but there’s no traffic
- Symptom: Link lights on; gateway ping fails; DHCP may or may not work.
- Root cause: Wrong VLAN on switch port, port security, 802.1X failure, or driver negotiation issues.
- Fix: Try another port/cable; in corporate, validate switchport auth and VLAN assignment; consider forcing speed/duplex only as a last resort.
8) Fixing it by disabling IPv6 “works” but keeps coming back
- Symptom: Disabling IPv6 gives temporary relief.
- Root cause: Broken IPv6 routing/DNS on the network, or RA misconfig. Disabling IPv6 just forces IPv4 and hides the real problem.
- Fix: Fix the network’s IPv6 configuration (router advertisements, DNS AAAA handling, firewall). On a single endpoint, prefer correcting DNS/gateway over disabling a protocol stack.
Checklists / step-by-step plan (no nuking from orbit)
This is the plan I’d hand to a competent admin or a stubborn power user. It escalates carefully.
Checklist A: Verify the basics (2–5 minutes)
- Confirm you’re connected to the intended SSID or Ethernet port (not a guest VLAN).
- Run
ipconfig /all. Record: IPv4 address, default gateway, DNS servers. - Ping the default gateway.
- Ping a public IP (example: 1.1.1.1).
- Run
nslookup example.com.
Decision point:
- If DHCP is failing (APIPA), stop and fix DHCP/L2/802.1X.
- If IP works but DNS fails, fix DNS or VPN DNS selection.
- If DNS works but web fails, check proxy/VPN/firewall/captive portal.
Checklist B: Catch the usual culprits (5–10 minutes)
- Check WinHTTP proxy:
netsh winhttp show proxy. Reset if wrong. - Check user proxy via registry (or Settings): confirm
ProxyEnablemakes sense. - Check interface metrics:
netsh interface ipv4 show interfaces. - Inspect route table:
route printfor default route surprises. - Test Windows connectivity probe via PowerShell
Invoke-WebRequestto the connect test file.
Checklist C: Repair the stack (10–20 minutes, controlled damage)
- Flush DNS:
ipconfig /flushdns. - Release/renew:
ipconfig /releasethenipconfig /renew. - Reset Winsock:
netsh winsock reset(reboot). - Reset IP stack:
netsh int ip reset(reboot).
Decision point: If these don’t help, the issue is likely external (network policy, VPN backend, proxy, firewall, captive portal, driver bug). Don’t keep randomizing your endpoint.
Checklist D: Driver and power sanity (varies)
- If the issue started after a driver update, roll back the network adapter driver.
- If it’s sleep-related, adjust adapter power management settings.
- If using a USB Ethernet dongle/dock, test a different port or direct Ethernet; docks can be tiny routers with feelings.
FAQ
1) Why does Windows say “No internet” when I can browse?
Because Windows is running a connectivity detection mechanism (NCSI) that can be blocked or redirected. Browsing can still work via cached DNS, different proxy behavior, or apps using different paths.
2) What’s the quickest way to tell if it’s DNS?
Ping a public IP (routing test), then run nslookup example.com (DNS test). IP works + DNS fails = DNS problem or DNS reachability problem.
3) Is “Reset network” a good fix?
Sometimes. But it’s destructive: it removes saved networks, VPN adapters/profiles, custom DNS/routes, and can break enterprise authentication. Use targeted resets (winsock, int ip) first.
4) Should I disable IPv6?
Not as a first move. Broken IPv6 on a network can cause real issues, but disabling IPv6 on the client often hides the underlying misconfiguration and can break corporate and modern Windows features.
5) Why does the problem happen only on corporate Wi‑Fi, not at home?
Corporate networks commonly enforce proxies, block public DNS, require 802.1X, and apply endpoint posture checks. A home network is basically a friendly anarchy by comparison.
6) Why do Microsoft apps (Store, OneDrive, Teams) fail while the browser works?
System components often use WinHTTP proxy settings and different TLS/proxy paths than your browser. A wrong WinHTTP proxy setting can break them while Chrome/Edge continues via its own settings.
7) I’m on a VPN. Why do I lose internet when the VPN drops?
That’s usually a kill switch or routing policy: when the tunnel dies, the client blocks traffic to prevent leaks. The fix is adjusting VPN policy, not “fixing Windows.”
8) How do I know if a captive portal is the issue?
Fetch a known plain HTTP file and inspect the content. If you get an HTML login page or redirects instead of expected text, you’re behind a portal.
9) Why does restarting sometimes “fix” it?
Rebooting clears transient state: stale routes, stuck VPN services, bad driver state after sleep, and cached DNS. It’s not a cure; it’s a state reset that can hide the real cause.
10) When should I escalate to IT/networking instead of continuing?
If you have a valid IP, can reach your gateway, but proxy/VPN policies or firewall behavior appear to be the blocker—especially on managed devices. Endpoint flailing won’t fix a central policy.
Conclusion: next steps that won’t ruin your day
“Connected, no internet” is either (a) you truly can’t reach the internet, or (b) Windows can’t prove you can. The fix is to stop treating it like a mystical OS curse and start treating it like a layered system.
Do this next, in order:
- Run
ipconfig /alland confirm: real IP, default gateway, DNS servers. - Ping gateway, then ping a public IP, then
nslookupa domain. - If web/app behavior is inconsistent, check proxies (WinHTTP + user proxy) and VPN route/metric behavior.
- If you suspect stack corruption, use
netsh winsock resetandnetsh int ip reset—and reboot—before you “reset network.” - If it’s corporate and the evidence points to policy (proxy blocks, DNS restrictions, VPN kill switch), escalate with data: command outputs and a precise failure layer.
The goal isn’t to make the icon happy. The goal is to restore reliable connectivity without deleting half your configuration and hoping the universe approves.