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 \u201cit works on Wi-Fi but not on Ethernet.\u201d<\/p>\n
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.<\/p>\n
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.<\/p>\n
ipconfig<\/code><\/h2>\nipconfig<\/code> is usually the first stop because it answers the basic question: what network configuration does this machine think it has?<\/p>\nUsed without options, it shows IPv4 and IPv6 addresses, subnet mask, and default gateway for active adapters. With ipconfig \/all<\/code>, it becomes more useful for admins because it also exposes DNS servers, DHCP status, adapter names, and lease information.<\/p>\nPractical uses:<\/p>\n
\n- confirm whether the device has a valid IP address<\/li>\n
- check whether it is using the expected gateway<\/li>\n
- verify DNS server assignments<\/li>\n
- spot VPN, virtual adapter, or Wi-Fi\/Ethernet confusion<\/li>\n<\/ul>\n
The DNS switches are also worth remembering. ipconfig \/flushdns<\/code> clears the local resolver cache, while ipconfig \/displaydns<\/code> shows what Windows has cached. That does not fix every DNS problem, but it helps separate \u201cWindows cached something stale\u201d from \u201cthe resolver or record is actually wrong.\u201d<\/p>\nUse ping<\/code>, but do not overtrust it<\/h2>\nping<\/code> 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.<\/p>\nBut 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.<\/p>\n
A good troubleshooting pattern is:<\/p>\n
\n- ping the local gateway<\/li>\n
- ping a known public IP address<\/li>\n
- ping a hostname<\/li>\n<\/ul>\n
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.<\/p>\n
Use tracert<\/code> when the path matters<\/h2>\ntracert<\/code> 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 \u201cis it reachable?\u201d to \u201cwhere does the path seem to slow down or disappear?\u201d<\/p>\nThis matters when a service works from one location but not another, or when latency suddenly appears between networks.<\/p>\n
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.<\/p>\n
Still, tracert<\/code> is valuable because it gives you something concrete to compare: local network, ISP hops, regional exchange points, and destination-side behavior.<\/p>\nUse WSL tools when they help<\/h2>\n
If you live in WSL, Linux versions of these tools are convenient. The Linux ping<\/code> 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<\/code> and mtr<\/code>.<\/p>\nmtr<\/code> 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.<\/p>\nThe 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.<\/p>\n
Use netstat<\/code> to see what is actually connected<\/h2>\nnetstat<\/code> 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?<\/p>\nA few practical examples:<\/p>\n
\nnetstat -ano<\/code> shows addresses, ports, and process IDs<\/li>\nnetstat -a<\/code> shows active connections and listening ports<\/li>\nnetstat -r<\/code> shows the routing table, similar to route print<\/code><\/li>\n<\/ul>\nThis is not a full security tool. But if a machine is behaving strangely, netstat<\/code> can quickly reveal unexpected listening services, noisy outbound sessions, or a process ID worth checking in Task Manager.<\/p>\nUse route print<\/code> when traffic goes the wrong way<\/h2>\nMost 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.<\/p>\n
route print<\/code> 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.<\/p>\nIf 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.<\/p>\n
The practical troubleshooting order<\/h2>\n
For most everyday Windows networking problems, a simple order works well:<\/p>\n
1. ipconfig \/all<\/code> to inspect adapter, DNS, gateway, and DHCP details. 2. ping<\/code> the gateway, a public IP, and a hostname. 3. tracert<\/code> the destination if reachability or latency is unclear. 4. netstat -ano<\/code> if suspicious connections or listening ports are part of the problem. 5. route print<\/code> if VPNs, virtual adapters, or multiple networks may be involved. 6. WSL tools like mtr<\/code> when you need a live route-and-latency view.<\/p>\nWhy this still matters<\/h2>\n
These commands are old because the problems are old: DNS confusion, wrong gateways, blocked paths, overloaded links, unexpected listeners, and routing mistakes.<\/p>\n
The modern admin advantage is not knowing every switch by memory. It is knowing which question to ask first. These tools help turn \u201cthe network is broken\u201d into a smaller, testable problem.<\/p>\n
Sources<\/h2>\n\n- How-To Geek: I use these 6 Windows networking commands every single day<\/a><\/li>\n
- Microsoft Learn: ping<\/a><\/li>\n
- Microsoft Learn: tracert<\/a><\/li>\n
- Microsoft Learn: ipconfig<\/a><\/li>\n
- Microsoft Learn: netstat<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
A practical guide to six Windows networking commands that help diagnose DNS, connectivity, routing, and suspicious connection problems without extra tools.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[40],"tags":[111,135,22,136,35,137],"class_list":["post-130","post","type-post","status-publish","format-standard","hentry","category-windows","tag-networking","tag-powershell","tag-sysadmin","tag-troubleshooting","tag-windows","tag-wsl"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/cgh.mx\/index.php?rest_route=\/wp\/v2\/posts\/130","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cgh.mx\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cgh.mx\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cgh.mx\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cgh.mx\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=130"}],"version-history":[{"count":1,"href":"https:\/\/cgh.mx\/index.php?rest_route=\/wp\/v2\/posts\/130\/revisions"}],"predecessor-version":[{"id":132,"href":"https:\/\/cgh.mx\/index.php?rest_route=\/wp\/v2\/posts\/130\/revisions\/132"}],"wp:attachment":[{"href":"https:\/\/cgh.mx\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=130"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cgh.mx\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=130"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cgh.mx\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=130"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}