Six Windows networking commands worth knowing

Most Windows network problems do not start with a dashboard. They start with a user saying the internet is slow, a website is unreachable, DNS looks wrong, or “it works on Wi-Fi but not on Ethernet.”

That is where the old command-line tools still earn their place. They are not glamorous, and they will not replace proper monitoring, but they are fast, built in, and good enough to narrow a vague complaint into a real troubleshooting path.

A recent How-To Geek piece highlighted six commands the author uses regularly from Windows, PowerShell, and WSL. The useful angle is not memorizing every switch. It is knowing what each command is good for and what it cannot prove.

Start with `ipconfig`

ipconfig is usually the first stop because it answers the basic question: what network configuration does this machine think it has?

Used without options, it shows IPv4 and IPv6 addresses, subnet mask, and default gateway for active adapters. With ipconfig /all, it becomes more useful for admins because it also exposes DNS servers, DHCP status, adapter names, and lease information.

Practical uses:

confirm whether the device has a valid IP address
check whether it is using the expected gateway
verify DNS server assignments
spot VPN, virtual adapter, or Wi-Fi/Ethernet confusion

The DNS switches are also worth remembering. ipconfig /flushdns clears the local resolver cache, while ipconfig /displaydns shows what Windows has cached. That does not fix every DNS problem, but it helps separate “Windows cached something stale” from “the resolver or record is actually wrong.”

Use `ping`, but do not overtrust it

ping is the classic connectivity test. Microsoft describes it as a way to verify IP-level connectivity using ICMP echo requests and replies. It can quickly tell you whether a host responds, what round-trip time looks like, and whether packet loss appears obvious.

But there is an important caveat: a failed ping does not always mean the target is down. Firewalls, routers, cloud providers, and security policies often block ICMP. A web server can refuse ping and still serve HTTPS perfectly.

A good troubleshooting pattern is:

ping the local gateway
ping a known public IP address
ping a hostname

If the IP works but the hostname does not, the problem may be DNS. If the gateway fails, the problem is probably local network access. If everything works except one service, ping has done its job: it narrowed the investigation.

Use `tracert` when the path matters

tracert shows the route packets appear to take toward a destination by sending probes with increasing time-to-live values. It is useful when the question changes from “is it reachable?” to “where does the path seem to slow down or disappear?”

This matters when a service works from one location but not another, or when latency suddenly appears between networks.

The catch is that traceroute-style tools are imperfect. Some routers do not reply, some paths are asymmetric, and modern networks can route traffic differently between attempts. A line of asterisks is a clue, not a verdict.

Still, tracert is valuable because it gives you something concrete to compare: local network, ISP hops, regional exchange points, and destination-side behavior.

Use WSL tools when they help

If you live in WSL, Linux versions of these tools are convenient. The Linux ping behaves differently from Windows by default: it keeps running until stopped, while Windows sends four echo requests unless told otherwise. The Linux side also has tools such as tracepath and mtr.

mtr is especially useful because it combines continuous ping-style latency with route visibility. It is not built into Windows by default, but inside WSL it can be a practical bridge between Windows workstations and Linux-style diagnostics.

The important point is not that one side is better. It is that Windows and WSL can complement each other. Sometimes the native Windows command sees the network more directly. Sometimes Linux tooling gives you a better live view.

Use `netstat` to see what is actually connected

netstat displays active TCP connections, listening ports, routing information, and protocol statistics depending on the options used. For security and troubleshooting, the useful question is simple: what is this machine talking to, and what is listening?

A few practical examples:

netstat -ano shows addresses, ports, and process IDs
netstat -a shows active connections and listening ports
netstat -r shows the routing table, similar to route print

This is not a full security tool. But if a machine is behaving strangely, netstat can quickly reveal unexpected listening services, noisy outbound sessions, or a process ID worth checking in Task Manager.

Use `route print` when traffic goes the wrong way

Most home users have one gateway and one obvious path to the internet. In workplaces, labs, VPN-heavy environments, and machines with virtual adapters, routing gets messier.

route print shows the routing table Windows is using. That becomes useful when a VPN captures traffic it should not, a lab network overlaps with another subnet, or a VM/WSL/Hyper-V adapter changes the path unexpectedly.

If DNS looks fine and the destination is reachable from another network, the route table can explain why this specific machine is sending packets somewhere unexpected.

The practical troubleshooting order

For most everyday Windows networking problems, a simple order works well:

1. ipconfig /all to inspect adapter, DNS, gateway, and DHCP details. 2. ping the gateway, a public IP, and a hostname. 3. tracert the destination if reachability or latency is unclear. 4. netstat -ano if suspicious connections or listening ports are part of the problem. 5. route print if VPNs, virtual adapters, or multiple networks may be involved. 6. WSL tools like mtr when you need a live route-and-latency view.

Why this still matters

These commands are old because the problems are old: DNS confusion, wrong gateways, blocked paths, overloaded links, unexpected listeners, and routing mistakes.

The modern admin advantage is not knowing every switch by memory. It is knowing which question to ask first. These tools help turn “the network is broken” into a smaller, testable problem.

CGH_TECH