“The internet is down” describes an experience rather than a cause. An IPv4 link-local address, an unreachable gateway, a failed DNS query, and a browser error can all produce that experience. Troubleshooting becomes faster when each test answers one question and the next test follows the result.
Read the configuration before resetting it
Get-NetAdapter
Get-NetIPConfiguration
Get-DnsClientServerAddress
ipconfig /allIdentify the adapter actually carrying the connection. VPNs, virtual switches, and disconnected Ethernet ports can make the wrong interface look suspicious. Record DHCP state, address, subnet, gateway, DNS servers, and any lease information. IPv6 may still work when IPv4 does not, so specify which protocol you are testing.
Treat APIPA as an addressing clue
A 169.254.x.x address on a Windows adapter configured for automatic IPv4 addressing usually means it did not obtain a usable DHCP lease. That link-local address can support communication on the local link, but it normally provides no routed IPv4 path to the internet. Changing the DNS server will not create that missing path.
Check the physical link or Wi-Fi association, the intended VLAN, DHCP scope capacity, and any DHCP relay. Compare another client on the same segment. If many clients fail together, investigate shared infrastructure; if only one fails, compare its adapter and configuration.
After repairing the suspected cause, renew the selected adapter from an elevated terminal. Use the actual adapter name:
ipconfig /renew "Ethernet"Avoid releasing a lease over the only remote management connection. A release intentionally removes the current configuration and may prevent you from completing the repair.
Test the route separately from name resolution
Get-NetRoute -DestinationPrefix "0.0.0.0/0"
Test-NetConnection -ComputerName 192.0.2.1 -InformationLevel Detailed192.0.2.1 is a documentation placeholder: replace it with the actual gateway. An ICMP failure alone does not prove the gateway is down because policy may block ping. Follow with a TCP test to an approved, known reachable destination and port. Check whether multiple default routes or a VPN are choosing an unintended path.
Test-NetConnection -ComputerName "REPLACE_WITH_APPROVED_DESTINATION_IP" -Port 443Compare DNS answers deliberately
Resolve-DnsName example.com -DnsOnly
Resolve-DnsName example.com -Server 192.0.2.53 -DnsOnlyReplace 192.0.2.53 with a real resolver you are authorized to query. The first command uses the client’s normal resolver configuration; the second asks a specific server. A timeout, NXDOMAIN response, and unexpected address mean different things. Query an internal hostname separately if internal resources are the problem.
Domain-joined systems usually need DNS servers that can resolve the organization’s AD records. Replacing those with a public resolver may restore public browsing while breaking domain services. Compare DNS suffixes, VPN policy, and split DNS before changing anything.
Clear caches only when caching is the suspect
Get-DnsClientCache
Clear-DnsClientCacheClearing a stale record can help after the authoritative data or resolver path is fixed. It cannot repair an unavailable DNS server. Browsers may also use their own cache or encrypted DNS configuration, so a successful Resolve-DnsName result does not guarantee that the browser used the same resolver.
If addressing, routing, and DNS pass, inspect proxy settings, TLS time, firewall policy, and the application. Finish by verifying the original task, such as opening the required website or accessing a domain share. Keep the working configuration and the cause together; repeated stack resets without that evidence make future failures harder to explain.