“The Internet is down” can mean almost anything.

One website may be unavailable. One laptop may have disconnected from Wi-Fi. A whole virtual local area network (VLAN) may have lost Dynamic Host Configuration Protocol (DHCP). Domain Name System (DNS) resolution may be failing while IP connectivity works perfectly. A router may have lost its upstream route. An Internet service provider (ISP) may actually be having an outage.

Those are different failures, even though a user may describe every one of them with the same sentence.

Good troubleshooting is less about memorizing commands and more about reducing uncertainty. Start close to the affected device. Prove what works. Move outward one boundary at a time. Stop when the evidence changes.

2. “The Internet Is Down” Is Not a Diagnosis

A technician's first job is not to fix the Internet. It is to make the complaint smaller.

Before changing settings, ask what the user actually tried:

  • Which device is affected?
  • Is the connection wired or wireless?
  • Does the problem affect one application, one website, or everything?
  • Can other devices on the same network reach the Internet?
  • Can devices on another wireless network, VLAN, or subnet reach it?
  • Did anything change just before the problem began?
  • Is the failure constant or intermittent?

The answers determine where to start.

If one browser cannot load one site but other sites work, rebuilding the network stack is an ambitious response to a very small problem.

If every device in the building lost connectivity at the same time, reinstalling one laptop's network adapter is equally ambitious in the opposite direction.

What you observe Where to look first
One application or website fails Application, service, DNS record, proxy, certificate, or remote provider
One device fails Local link, adapter, IP configuration, firewall, VPN, proxy, or route
One VLAN, wireless network, or subnet fails Access point, switch port, VLAN path, DHCP, gateway, or policy for that segment
Local gateway works but remote IP connectivity fails Router, upstream route, firewall, ISP, or remote path
Remote IP connectivity works but names fail DNS client configuration, DNS server reachability, or DNS records
Everything at the site fails Edge router, modem, firewall, WAN circuit, ISP, or wider provider outage

A useful rule is: do not troubleshoot a larger system than the evidence requires.

3. Start by Shrinking the Problem

Try to find one thing that works and one closely related thing that does not.

For example:

  • This laptop cannot browse, but the phone beside it can.
  • Devices on the trusted VLAN work, but the guest VLAN does not.
  • The laptop can reach its gateway, but not a known remote IP address.
  • A remote IP address responds, but example.com does not resolve.
  • DNS resolves the name, but the HTTPS connection fails.

Each comparison removes entire categories of possible causes.

This is also why immediately rebooting every device in sight is not a troubleshooting method. A reboot may restore service, which can be useful, but it can also erase temporary state and make it harder to learn what failed. In a business environment, collect enough evidence to understand the scope before changing several things at once.

One change at a time is slower for thirty seconds and faster for the next hour.

Start with the connection closest to the device.

For Ethernet, check whether the cable is connected, whether the network adapter reports a link, and whether the switch port is up. If you have an authorized alternate cable or switch port, changing one component can help separate a cable problem from an adapter or switch problem.

For Wi-Fi, confirm that the device is associated with the intended network. Check for airplane mode, an accidentally disabled adapter, weak signal, or a connection to the wrong service set identifier (SSID).

Do not let a Wi-Fi icon prove more than it actually proves. Association with an access point does not guarantee that DHCP, the default gateway, DNS, the WAN path, and the destination application are all working.

Likewise, a disconnected cable is difficult to repair with DNS settings.

Microsoft's current TCP/IP troubleshooting guidance starts by checking adapter and link state before moving deeper into the protocol stack. That order is useful because higher-layer testing depends on the lower path being available first.

5. Read the IP Configuration

On Windows, start with the configuration the device is actually using:

ipconfig /all

Microsoft documents ipconfig as the command for displaying current TCP/IP configuration, including IPv4 and IPv6 addresses, subnet information, default gateways, DHCP details, and DNS servers.

Do not scan the output for one magical bad number. Ask whether the values make sense for this network.

Look for:

  • The active adapter
  • IPv4 and/or IPv6 addresses
  • Subnet mask or prefix information
  • Default gateway
  • DHCP status and DHCP server when applicable
  • DNS servers
  • Whether several active adapters, VPNs, or virtual interfaces could affect routing

An IPv4 address in 169.254.0.0/16 deserves attention on a Windows client that was expected to receive normal DHCP configuration. Microsoft describes Automatic Private IP Addressing (APIPA) as self-configuration used when a DHCP server is unavailable. An APIPA address can support limited local-link communication, but it normally will not provide the expected routed access to other subnets or the Internet.

That does not mean every unfamiliar address is wrong. Modern networks may use IPv4, IPv6, or both. Compare the device with a working peer on the same segment and with the intended network design.

If the subnet mask or prefix makes it unclear whether the host and gateway should be local to each other, the Cert Happens IPv4 subnet calculator can verify the boundary. Work out what you expect first, then use the calculator to check yourself.

If DHCP is clearly the failing boundary, ipconfig /renew can request a new lease. Use it because the evidence points toward DHCP, not because renewing addresses is a traditional network rain dance.

6. Test the Default Gateway

The default gateway is usually the first routed boundary between the device and destinations outside its local subnet.

From the ipconfig output, identify the gateway used by the affected adapter and test it:

ping <default-gateway>

A successful reply is useful evidence that the device can send traffic over the local network to that gateway and receive a response.

If the gateway test fails, stay local for a moment. Possible causes include:

  • Wrong IP address, subnet mask, prefix, or gateway
  • Wi-Fi or Ethernet link problems
  • VLAN mismatch
  • Switch or access-point problems
  • Local firewall behavior
  • Gateway interface problems
  • Internet Control Message Protocol (ICMP) being filtered

The last point matters. A failed ping does not automatically prove that the device is unreachable. Ping uses ICMP, and ICMP can be blocked or deprioritized. Use multiple pieces of evidence before declaring the gateway dead.

If several devices on the same segment also cannot reach the gateway, the problem has already become larger than one laptop.

7. Separate Reachability From DNS

One of the most useful troubleshooting splits is IP reachability versus name resolution.

If the gateway works, test a remote IP address that your organization, lab, or provider expects to be reachable:

ping <known-remote-IP>

Again, ICMP filtering means failure is not conclusive. The value is in comparison.

If a known remote IP address is reachable but a hostname does not work, the Internet may not be “down” at all. The problem may be DNS.

If neither a remote IP address nor a hostname works, DNS is less likely to be the first failing boundary. Investigate routing, firewall policy, the WAN path, or upstream connectivity before repeatedly flushing DNS caches and hoping the packets become more cooperative.

This distinction saves time because DNS translates names. It does not create the underlying IP route.

8. Test DNS on Purpose

Use nslookup to ask a DNS question directly:

nslookup example.com

Microsoft documents nslookup as a diagnostic tool for DNS infrastructure. In noninteractive mode, it queries the configured DNS server unless you specify another server.

Compare the result with what you already know:

  • Does the client have DNS servers configured?
  • Can it reach those servers?
  • Does nslookup return an address for the name?
  • Does the returned address look plausible for the destination?
  • Does one name fail while other names resolve?
  • Do other devices using the same DNS server have the same problem?

Microsoft's DNS-client troubleshooting guidance explicitly separates network connectivity to the DNS server from DNS query testing. That is an important distinction. A perfectly configured DNS server is not useful to a client that cannot reach it.

If nslookup succeeds but an application still cannot use the name, the problem may involve the client's resolver cache, application behavior, a proxy, a VPN, or another layer above the basic DNS query.

Windows provides ipconfig /displaydns to inspect the client resolver cache and ipconfig /flushdns to clear it. Flushing the cache can be appropriate when the evidence suggests stale or negative cached data. Doing it before looking at the cache destroys the evidence you were about to inspect.

9. Find the Next Boundary With Tracert

If local connectivity works but remote connectivity does not, tracert can help show how far the path gets:

tracert /d <known-remote-IP>

The /d option tells Windows not to spend time resolving every intermediate IP address to a hostname.

Microsoft explains that tracert discovers the path by sending probes with increasing Time to Live (TTL) values and observing ICMP Time Exceeded responses from intermediate routers.

Use the output as a boundary-finding tool:

  • Does the first hop look like the expected gateway?
  • Do probes leave the local network?
  • Does the trace consistently stop near the same boundary?
  • Do working devices follow a different early path?

Do not treat every row of asterisks as a failed router. Microsoft notes that some routers do not return the ICMP messages tracert expects, so they can appear invisible even while forwarding other traffic normally.

Traceroute is evidence about a path, not a live diagram of every forwarding decision on the Internet.

If the computer has multiple active adapters, VPN software, or unusual routes, this is also a good time to inspect the local routing table:

route print

Windows uses the routing table to decide which interface and next hop should carry traffic toward a destination. A technically valid route through the wrong VPN or adapter can produce a very confusing version of “the Internet is down.”

10. Move Up to the Application

Suppose the device has a sensible IP configuration, reaches its gateway, resolves DNS, and can reach remote networks. A browser or application can still fail.

Now the question is no longer “Does the network work?” It becomes “Can this application reach this service the way it expects?”

For HTTPS, Windows includes curl, which can be used to test an HTTP endpoint without relying on the browser interface:

curl.exe -I https://example.com

Microsoft documents curl as included with Windows for transferring data using protocols including HTTP and HTTPS. Calling curl.exe explicitly also avoids the older Windows PowerShell 5.1 alias that uses the name curl for a different command.

At this layer, investigate things such as:

  • Is the remote service actually available?
  • Does DNS return the expected destination?
  • Is a proxy configured?
  • Is a VPN changing the route?
  • Is a firewall blocking the application's protocol or port?
  • Is Transport Layer Security (TLS) failing because of certificates, inspection, or incorrect system time?
  • Is a captive portal waiting for browser authentication?
  • Does the application require a service that is separate from the main website?

If you know the service but not the usual protocol or port, check the Cert Happens Ports and Protocols reference. An open network path does not guarantee that the required application service is listening or allowed.

11. Know When the Problem Is Upstream

Troubleshooting should eventually tell you when to stop changing the local device.

If multiple clients have valid local configuration, can reach the local gateway, and then fail at the same upstream boundary, the next useful question may be about the router, firewall, modem, WAN circuit, ISP, cloud provider, or remote service.

At that point, collect evidence before escalating:

  • Time the problem started
  • Devices and networks affected
  • What still works
  • Gateway test results
  • DNS behavior
  • Trace results
  • Relevant logs or interface status
  • Recent changes

Provider status pages can be useful, but check them after you know what service is actually failing. “There is no outage reported” is not proof that your circuit is healthy, just as one user's browser error is not proof of a nationwide outage.

A good escalation is specific:

Multiple devices on VLAN 20 have valid DHCP leases and can reach gateway 192.168.20.1. They cannot reach known external destinations. Devices on VLAN 10 are unaffected. The failure began at approximately 09:20 after no known local change.

That gives the next technician somewhere to start.

“The Internet is broken” gives them somewhere to sigh.

12. Ping Is Evidence, Not a Verdict

Ping is useful because it is simple. That simplicity also makes it easy to ask it to prove too much.

A successful ping can show that ICMP echo traffic made a round trip between two endpoints. It does not prove that:

  • DNS works
  • HTTPS works
  • The required TCP or UDP port is open
  • The application is healthy
  • Every packet follows the same path
  • There is no intermittent loss
  • Authentication succeeds
  • A proxy or VPN is configured correctly

A failed ping does not prove the opposite either, because ICMP may be filtered.

Use ping to answer a small question: Can I get an ICMP response from this boundary?

Then ask the next question with the next tool.

The same principle applies to every diagnostic command. ipconfig, nslookup, tracert, route print, curl, and Wireshark each reveal a different part of the path. None of them contains an “explain the entire outage” button. Rude, but technically reasonable.

13. A Repeatable Troubleshooting Sequence

When someone reports that the Internet is down, work through this sequence and stop when the evidence identifies a smaller problem.

  1. Define the scope. One application, one device, one network segment, one site, or everyone?
  2. Check the local link. Ethernet connected? Correct Wi-Fi? Adapter enabled? Expected switch or access point?
  3. Read the configuration. IP address, prefix or mask, gateway, DHCP, DNS, active adapters, VPNs.
  4. Test the nearest routed boundary. Can the device reach its default gateway?
  5. Test remote reachability. Can it reach a known remote IP destination?
  6. Test DNS separately. Can the configured resolver answer for the name you need?
  7. Inspect the path. Where does tracert stop providing useful evidence? Is the local route sensible?
  8. Test the application layer. Can the actual protocol and service connect?
  9. Compare with a working peer. Same segment, same DNS, same route, same result?
  10. Escalate with evidence. State what works, what fails, where the boundary appears to be, and what changed.

Notice what is missing from the sequence: randomly changing five settings at once.

The goal is not to run every command. The goal is to identify the first boundary that behaves differently from what you expect.

14. Practice Without Waiting for an Outage

Troubleshooting becomes much easier when the first time you use a tool is not during an actual outage.

A small home lab gives you a safe place to create controlled failures:

  • Disable a DHCP service and observe the client's configuration.
  • Configure an incorrect default gateway, then compare the symptoms.
  • Point a test client at an invalid DNS server while leaving IP routing intact.
  • Block one application port while allowing other traffic.
  • Put a device in the wrong VLAN and compare its addressing and gateway reachability.
  • Capture a short Wireshark trace before and after the failure.

Change one thing, predict what should break, test it, restore it, and document what the tools showed.

That last step matters. Troubleshooting skill is not just getting the green light back. It is being able to explain which boundary failed and which evidence proved it.

If packet-level evidence would help, continue with Wireshark for Beginners. If the problem involves segmentation, Why Use VLANs at Home? explains how VLANs, subnets, and firewall policy fit together.

15. Official References

Why Use VLANs at Home? Understand how VLANs, subnets, and firewall policy change which devices can communicate with each other. Wireshark for Beginners: What to Look for in Your First Packet Capture Capture a small amount of traffic and use packet evidence when ordinary connectivity tests are not enough. How to Build IT Experience With a Home Lab Without Buying a Rack of Hardware Build a safe environment where you can create, break, troubleshoot, and document small networks. Free Tools and Resources Worth Knowing as an IT or Cybersecurity Student Find useful networking, security, learning, and reference tools without turning your browser into a bookmark landfill.
Network+ resources Study networking concepts, operations, troubleshooting, security, and practical network decisions. Ports and protocols Check common application protocols and ports when basic network reachability works but a service does not. IPv4 subnet calculator Verify network, broadcast, host range, and subnet boundaries when the local IP configuration looks suspicious. IPv6 addressing reference Review IPv6 address types and behavior when the network uses IPv6 alongside or instead of IPv4.