Essential Windows CMD Commands to Diagnose Network and Router Issues

 Most people diagnose network problems by restarting things until something works. It occasionally succeeds, teaches you nothing, and takes far longer than asking the machine what is wrong.

Windows ships with a complete diagnostic toolkit that has existed for decades, costs nothing, and requires no installation. A handful of commands will tell you within two minutes whether the fault is your device, your cable, your router, your DNS, or your provider.

This guide covers the Windows CMD network commands that matter, what each output actually means, and the order to run them in.

Open the Command Prompt Correctly

Several commands require administrator rights and fail silently or partially without them.

Press the Windows key, type cmd, then press Ctrl+Shift+Enter. That opens an elevated prompt. The window title will say Administrator.

Commands that need elevation include ipconfig /release, ipconfig /renew, ipconfig /flushdns, netsh commands, and route add.

ipconfig: Your Network Identity

ipconfig commands are always the first step, because they tell you whether your device has a valid network configuration at all.

ipconfig

This gives you three numbers that matter:

• IPv4 Address — your device's address on the local network.
• Subnet Mask — defines which addresses are local and which are remote.
• Default Gateway — your router.

For complete detail:

ipconfig /all

This adds the physical MAC address, DHCP server address, DNS server addresses, and lease times.

Reading the IP address is the fastest diagnosis you will ever do

Look at what you were given:

1. A normal private address (192.168.x.x, 10.x.x.x, or 172.16–31.x.x) means DHCP worked. Your device and router are communicating.
2. An address starting 169.254 is APIPA. This is the single most informative result in networking. It means your device asked for an address and received no answer. The cause is a dead cable, a switch port that is down, a failed DHCP service, or a router that is not responding.
3. No IPv4 address at all means the adapter is disabled or has no link.

That 169.254 address saves enormous time. It tells you immediately to stop investigating DNS, the browser, or the website, and look at the physical connection and the router instead.

The renewal sequence

ipconfig /release
ipconfig /renew

The first drops your current lease, the second requests a new one. This resolves a surprising number of problems, particularly after a router restart or an IP conflict.

If you run these over a remote desktop session you will disconnect yourself. Run them locally only.

Clearing the DNS cache

ipconfig /flushdns

Windows caches name lookups. If a site changed servers, or a previous lookup failed and was cached, your machine may keep using stale information. This command is the correct fix for "the site works on my phone but not my laptop."

To see what is cached:

ipconfig /displaydns

ping: Is the Destination Reachable?

Ping sends a small ICMP echo request and measures the reply. It answers one question: can packets get there and back.

ping 8.8.8.8

Three numbers in the output matter:

• Time — round-trip latency in milliseconds. Under 30ms is excellent locally. Over 150ms to a distant server is normal.
• Lost packets — anything above zero on a stable connection indicates a problem.
• TTL — a rough indication of how many routers the reply crossed.

Useful variations:

ping -t 8.8.8.8

Runs continuously until you press Ctrl+C. This is how you catch intermittent faults that a four-packet test will miss entirely. Leave it running while you wiggle a cable or move a laptop around a building.

ping -n 20 192.168.1.1

Sends exactly twenty packets for a more reliable sample than the default four.

The ping sequence that isolates any fault

Run these four in order. The first one that fails identifies the layer of the problem.

1. ping 127.0.0.1 — the loopback address. Tests your own TCP/IP stack. Failure here means a software problem on your machine, not a network problem.
2. ping <your own IP> — tests your network adapter.
3. ping <default gateway> — tests the path to your router. Failure here means cable, switch, or router.
4. ping 8.8.8.8 — tests internet connectivity by IP. Success here with a failing website means DNS is your problem.

This four-step ladder is the single most useful diagnostic routine in this article. It narrows any connectivity fault to one segment in under a minute.

An important caveat about ping

Many servers and firewalls deliberately block ICMP. A failed ping does not always mean unreachable. Test against a known reliable target such as a major public DNS server before concluding anything.

tracert: Where Exactly Does It Break?

Ping tells you whether the path works. Tracert tells you where it stops working.

tracert google.com

Each line is one router hop along the path, with three latency measurements.

How to read it:

• A steady increase in latency across hops is normal.
• Consistent timeouts at one hop but successful hops afterwards mean that router simply does not reply to these probes. This is common and not a fault.
• Timeouts from one hop onward, all the way to the end, identify where the path genuinely breaks.
• A sudden large latency jump that persists through all later hops indicates a congested or distant link at that point.

The first hop is always your own router. If hop one fails, stop looking at the internet and look at your local network.

For a more thorough analysis:

pathping google.com

This combines both tools, sending many packets over several minutes to calculate packet loss at each individual hop. It takes far longer but is much more conclusive for intermittent problems.

nslookup: Testing DNS Directly

nslookup DNS testing separates name resolution from connectivity, and that distinction resolves a large share of real faults.

nslookup google.com

If this returns an IP address, DNS is working. If it times out or returns an error while ping 8.8.8.8 succeeds, your DNS configuration is the problem.

To test a specific DNS server:

nslookup google.com 8.8.8.8

This bypasses your configured server entirely. If the lookup succeeds against 8.8.8.8 but fails against your default, your router's DNS or your provider's DNS is at fault.

netstat: What Is My Machine Actually Connected To?

netstat ports information reveals active connections and listening services.

netstat -ano

The columns show local address, remote address, connection state, and process ID.

To identify which program owns a connection, take the PID from the last column and match it in Task Manager's Details tab.

Useful variations:

netstat -an | find "LISTENING"

Shows every port your machine is listening on — valuable for security checks and for confirming a service actually started.

netstat -e

Displays interface statistics including errors and discards. Non-zero error counts point at physical problems such as a damaged cable or a duplex mismatch.

arp: The Local Address Table

The arp table maps IP addresses to MAC addresses on your local network.

arp -a

Two practical uses:

1. Detecting an IP conflict. If two entries share one MAC, or an address behaves unpredictably, this table often shows why.
2. Confirming your gateway. The MAC listed against your gateway IP should match your router. If it changes unexpectedly, investigate.

To clear the table:

arp -d *

Requires administrator rights, and forces fresh resolution.

route print: Your Local Routing Table

route print

Look for the line with destination 0.0.0.0 and mask 0.0.0.0. That is your default route, and the gateway column should show your router.

If there are two default routes — common when a VPN is active or when both Wi-Fi and Ethernet are connected — traffic may take an unexpected path. The metric column decides which wins.

getmac and netsh: Two More Worth Knowing

getmac /v

Lists the MAC address of every adapter with its connection name.

netsh wlan show profiles

Lists every saved wireless network on the machine.

netsh interface ip show config

Displays IP configuration including whether addresses are assigned by DHCP or statically.

netsh winsock reset

Resets the network stack to defaults. This is a genuine last resort for a machine with persistent, unexplainable network faults. It requires a restart afterwards.

The Order to Run Them In

When a user reports "the internet is not working," run these in sequence:

1. ipconfig — do I have a valid address? A 169.254 address ends the investigation here.
2. ping 127.0.0.1 — is my TCP/IP stack functioning?
3. ping <gateway> — can I reach my router?
4. ping 8.8.8.8 — can I reach the internet by IP?
5. nslookup google.com — is DNS resolving?
6. tracert 8.8.8.8 — where exactly does the path fail?

Each step eliminates a layer. By step six you either have your answer or you have proven the fault lies outside your network, which is itself a useful conclusion when contacting your provider.

Common Mistakes When Using These Tools

1. Running commands without administrator rights and getting incomplete results.
2. Testing only a website name and concluding the internet is down when DNS is the real fault.
3. Trusting a four-packet ping on an intermittent problem.
4. Assuming timeouts in tracert mean failure when intermediate routers simply do not reply.
5. Running ipconfig /release over a remote session and disconnecting yourself.
6. Skipping ipconfig entirely and starting with complex tools.
7. Ignoring the loopback test, then spending an hour on a network fault that was a software problem.

Conclusion

These tools have not changed meaningfully in twenty years because they work. The skill is not memorizing switches; it is knowing which question to ask next.

Start today with the four-step ping ladder: loopback, your own address, your gateway, then 8.8.8.8. Run it once now while everything is working so you know what a healthy result looks like. Recognising normal output is what makes abnormal output obvious, and that single habit turns these Windows CMD network commands from a list you half-remember into a diagnostic routine you can run without thinking.