The site won't load, the server doesn't answer, or a game suddenly feels unplayable. The temptation is to restart everything and hope. That usually destroys useful evidence while leaving the actual fault untouched.
A small set of network troubleshooting commands can narrow the problem quickly. The key is choosing commands by symptom, not memorizing a flat glossary. ping tests reachability, dig examines name resolution, ip exposes local addressing and routes, ss shows sockets, and tcpdump proves what packets did.
This catalog is organized like a working sysadmin's cheat sheet. Each entry includes syntax, Windows, macOS, and Linux differences, output interpretation, and the point at which one tool becomes more useful than a similar one. Keep a terminal open, start with the layer that matches the symptom, and move upward only when the lower layers look healthy. For broader practical technology coverage, NeoTeo's English technology publication is another useful reference point.
Introduction to Command Line Network Diagnostics
A browser timeout can hide several faults: a missing DNS answer, an incorrect default route, a service listening only on loopback, or a firewall dropping traffic. The symptom looks similar, but each cause needs different evidence. Start with the narrowest question the failure allows you to answer.
If the hostname fails, query DNS. If the IP address fails too, inspect the local interface and route. If the gateway responds while the destination does not, examine the path. If the host responds but the application remains unavailable, check the listening socket and capture packets.
Practical rule: Run the command that can disprove your current theory, not the one you happen to remember.
The classic tools remain useful because they examine different layers. ping uses ICMP Echo Request and Echo Reply messages to check whether a host is active and measure round-trip delay in milliseconds. traceroute adds hop-by-hop visibility, while ipconfig, ifconfig, and ip expose local addressing and routing state. netstat and ss show whether a process owns the port you are testing.
Use the tools as a decision-oriented catalog rather than a flat glossary. Each command entry should give working syntax, Windows, macOS, and Linux differences, output interpretation, and the trade-off against a nearby alternative. For example, ss is generally a better current socket view than netstat, while dig offers more DNS detail than nslookup. A practical English technology reference from NeoTeo can supplement that command-line workflow.
During an incident, flags matter less than sequence: symptom, layer, evidence, then a defensible fix.
How to Choose the Right Command for the Problem
Classify the failure before typing. Four questions cover most first-pass investigations:
- Does DNS resolve? If a name fails but a known IP works, use nslookup or dig.
- Does the host have correct addressing and routing? Use ip addr, ip route, ifconfig, or ipconfig.
- Where does the path fail? Use ping for end-to-end testing, then traceroute, tracert, tracepath, or mtr.
- Is the service listening? Use ss or netstat, then confirm the owning process and firewall behavior.
A site that loads by IP but not by name points toward DNS, not general connectivity. A service that works locally but not remotely suggests a bind address, route, access-control, or firewall issue. A host that reaches the gateway but loses replies farther away needs path analysis rather than another local interface check.
Symptom to First Command Mapping
| Symptom | First command to run | What it tells you |
| A hostname doesn't resolve | nslookup name or dig name | Whether DNS returns an answer and how the response was formed |
| An interface has no usable connection | ip addr, ifconfig, or ipconfig /all | Address, mask, state, gateway, and resolver details |
| The local network seems unavailable | ping <gateway> | Whether the host can reach its first router |
| The destination is slow or unreachable | ping <destination> | End-to-end reachability, delay, and loss |
| The route may contain a failing segment | traceroute, tracert, or mtr | Hop-by-hop responses and where delay begins |
| A port appears closed | ss -tulnp or netstat -ano | Listening state, connections, and owning process information |
This order prevents a common mistake: blaming the application before proving the network path. It also keeps tests cheap. Inspect local state first, then send probes, then capture packets only when lighter commands leave competing explanations.
Ping for Reachability and Latency Testing
A destination can look unavailable when the failure is local, upstream, or limited to one service. Start with ping to separate those cases. It sends an ICMP Echo Request, waits for an Echo Reply, and reports whether the host responded and how long the round trip took. The protocol behavior and timing model are documented in RFC 1739.
Use the native syntax for each platform:
Windows: ping -n 10 -l 512 host
macOS: ping -c 10 -s 512 host
Linux: ping -c 10 -s 512 host
Windows uses -n for a finite count and -t for continuous probing. Linux and macOS use -c for the count and normally continue until interrupted. On Linux and macOS, -i sets the interval. IPv6 commonly uses ping6 on Unix-like systems, while Windows uses ping -6.
A serious baseline should use 50 to 100 probes, not a handful, because a short sample can miss intermittent loss and jitter. That guidance appears in Obkio's ping and traceroute comparison. Test more than one payload size. Small default packets may pass while larger packets reveal MTU or congestion problems.
Reading the output
Each reply normally shows the destination, payload size, elapsed time, and TTL. Look for consistency before focusing on the average. Stable times suggest a predictable path. Large swings indicate congestion, queueing, wireless interference, or another changing condition. The summary reports sent, received, lost, and minimum, maximum, and average delay.
TTL is not a direct hop counter. It can still provide a rough indication of how much packet lifetime remains. Compare values from the same target and avoid treating one TTL as proof of route length.
Run the checks in order:
ping <default-gateway>
ping <known-good-intermediate-host>
ping <destination>
A failed gateway test keeps the investigation local. If the gateway responds but the destination loses packets, switch to traceroute or mtr for path analysis. If ping succeeds while the application remains slow, test the service with ss, tcpdump, or iperf3. A failed ping does not prove that the host is down. Firewalls and network devices may filter ICMP, so interpret the result as evidence about ICMP reachability, not every service on the destination.
Traceroute, Tracepath and mtr for Path Analysis
A ping can show that a destination is slow or unreachable, but it cannot show where the path changes. Traceroute fills that gap by eliciting ICMP Time Exceeded responses from routers along the route. You can inspect intermediate hops instead of seeing only the final result. Its operational role is reflected in management specifications such as RFC 2925.
The command depends on the operating system:
Linux: traceroute host
macOS: traceroute host
Windows: tracert host
Linux: tracepath host
Linux: mtr host
Linux and macOS traceroute provide hop-by-hop output, while Windows tracert is the native equivalent. On Linux, tracepath is useful when you need path and MTU information with fewer privilege requirements than some other probes. mtr repeatedly combines ping-style measurements with traceroute-style visibility, so it is better for watching a changing path than a single traceroute run.
How to interpret a suspicious hop
A row of asterisks does not by itself identify the failing device. Routers may forward traffic normally while filtering or deprioritizing the diagnostic responses that traceroute relies on. If later hops reply and the destination works, treat that silent hop as a limitation of the test rather than proof of an outage.
Look for a pattern that continues through later hops. Delay or loss that starts at one hop and remains visible afterward is more meaningful than an isolated slow response. Compare the path with direct pings to the gateway and destination, then repeat the test from a known-good host if available.
For intermittent path issues, reuse the extended probe approach introduced for ping, then compare hop-by-hop results to direct gateway and destination pings to isolate the segment. Varying payload sizes can also expose MTU-related behavior. This comparison helps separate a local LAN fault from an ISP boundary, routing black hole, or destination-side problem. The same operational guidance applies to path testing.
mtr is often the quickest way to observe a moving problem, though its output can be noisy and still depends on how routers treat diagnostic traffic. For proof, capture packets with tcpdump at the source or destination. A route trace suggests where behavior changes. A capture shows whether packets were sent, acknowledged, retransmitted, or rejected.
Interface and Routing Commands with ip, ipconfig and ifconfig
A host can have link connectivity and still send traffic nowhere useful. Check the local interface, address, gateway, and route before investigating DNS or the remote service.
On modern Linux, start with:
ip addr show
ip route show
ip addr show reports interface state, addresses, and prefix lengths. Find adapters marked down, an unexpected subnet, or an address attached to the wrong interface. ip route show exposes the kernel's routing decisions. Verify that the default route points to the expected gateway and interface. If two default routes exist, the lower metric wins, which can send traffic through the wrong adapter.
Use the platform's available tools when working across systems:
Linux or macOS: ifconfig
Linux legacy route view: route -n
Windows: ipconfig
Windows detail: ipconfig /all
ifconfig remains useful for a quick interface check, although it may omit route details that ip displays directly. route -n gives Linux operators a numeric routing view on older installations. On Windows, ipconfig /all combines adapter, DHCP, gateway, and resolver information. The practical distinction between these command families is outlined in this network troubleshooting command reference.
Windows lease and resolver actions
Use these Windows operations when DHCP or the local DNS cache may be involved:
ipconfig /all
ipconfig /release
ipconfig /renew
ipconfig /flushdns
Run /all first and record the adapter, address, gateway, and DNS servers. After a router replacement or lease problem, /release followed by /renew requests fresh DHCP information. /flushdns clears only the local resolver cache. It cannot repair an unavailable or incorrectly configured DNS server.
macOS provides networksetup for service-level checks:
networksetup -listallnetworkservices
networksetup -getinfo "Wi-Fi"
ifconfig
A valid address does not confirm a usable route. A correct route can still meet a local firewall rule, and an active interface can use the wrong gateway. Verify addressing and routing first, then inspect ss or netstat when you need to confirm how the target service is bound.
Socket and Connection State with ss and netstat
If a service appears “open,” verify the socket rather than trusting the claim. The process might bind only to loopback, use the wrong address family, or fail to listen at all.
On Linux, begin with ss:
ss -tulnp
ss -tan
ss -s
-t selects TCP, -u selects UDP, -l lists listening sockets, -n skips name lookups, and -p shows the owning process when permissions allow it. ss -tulnp is the practical first check for listeners. Use ss -tan to inspect active TCP states, including connections that are not listening sockets. ss -s gives a compact summary when you need to spot an unusual volume of sockets before examining individual entries.
Linux operators generally prefer ss over legacy netstat because it is faster and exposes detailed socket information, as described in practical comparisons of network commands.
Prefer ss -tulnp on Linux for listening sockets and process ownership. On Windows, where ss is unavailable, use netstat -ano or netstat -abno. Use netstat -rn only when you need the routing table alongside socket state.
Why netstat still matters
netstat displays active TCP connections, listening ports, Ethernet statistics, the IP routing table, and protocol statistics for IPv4 and IPv6. On Windows, run:
netstat -ano
netstat -abno
The -o option adds the process identifier. Map that PID to a process with:
tasklist /fi "PID eq <PID>"
Common Linux and macOS forms include:
netstat -an
netstat -rn
Read the state column in context. LISTEN means a process is waiting for incoming connections. ESTABLISHED indicates an active session. TIME_WAIT usually represents a recently closed TCP session and does not, by itself, prove a fault. A listener on 127.0.0.1 will not accept connections through the host's LAN address. A listener on the expected address can still be blocked by a firewall or unreachable route.
Socket check: Confirm the address, port, protocol, state, and owning process. “The service is running” is weaker evidence than “the expected process is listening on the expected interface.”
DNS and Address Resolution Commands with dig, nslookup and arp
Name resolution has its own diagnostic ladder. nslookup is the quick, broadly available option on Windows, macOS, and Linux. Use it when you need to establish whether a resolver returns an answer:
nslookup hostname
nslookup -type=A hostname
nslookup -type=AAAA hostname
nslookup -type=MX hostname
nslookup hostname <resolver>
The -type form asks for a specific record family, while the final form queries a chosen resolver directly. A reverse lookup checks which name is associated with an address:
nslookup <address>
dig is more verbose and better suited to comparing resolver behavior:
dig hostname
dig A hostname
dig AAAA hostname
dig MX hostname
dig @<resolver> hostname
dig -x <address>
The output exposes response flags, authoritative information, and TTL. TTL is the remaining lifetime of a record before it expires, so an old cached answer can explain why different clients appear to disagree. A practical overview of nslookup, dig, TTL, response flags, and authoritative servers appears in this DNS troubleshooting guide.
Checking local neighbors
DNS can be healthy while the local network still fails to deliver packets. ARP maps an IPv4 address to a local hardware address, so inspect the neighbor cache when a host appears to have an address conflict or the gateway behaves inconsistently.
Windows:
arp -a
arp -d *
Linux:
ip neigh show
ip neigh flush all
Use deletion or flushing carefully, especially on a production host. A changing MAC address for the same local IP can indicate a duplicate address, stale cache, failover movement, or a switching problem. ARP is a local-segment tool, not a replacement for route analysis. If the neighbor entry is correct but traffic still leaves through the wrong interface, return to ip route or the Windows routing table.
Packet Capture and Throughput Testing with tcpdump and iperf
Use packet capture when ping, route inspection, and socket checks leave two plausible explanations. tcpdump shows what crossed an interface, which makes it valuable for separating “the application sent nothing” from “the network dropped what it sent.”
Start narrowly:
tcpdump -i <interface> host <host>
tcpdump -i <interface> port <port>
tcpdump -i <interface> 'host <host> and port <port>'
tcpdump -i <interface> -w capture.pcap 'port <port>'
The first command limits traffic to one host, the second to one port, and the third combines both filters. The last writes a capture for later analysis. A normal TCP connection begins with a SYN, receives a SYN-ACK, and completes with an ACK. Repeated SYN packets without a reply suggest filtering, a route problem, or an unavailable listener. Repeated retransmissions after an established connection point toward loss, congestion, or a receiving-side issue.
Wireshark provides a graphical analysis environment, while tshark offers a command-line companion. Keep captures short and targeted. Broad captures create noise and may expose credentials or sensitive payloads.
For throughput, use iperf3 between two hosts:
Server: iperf3 -s
Client: iperf3 -c <server>
ping measures reachability and delay. iperf3 measures achievable traffic between the selected endpoints. A good latency result with poor throughput points toward capacity, congestion, shaping, duplex, wireless, or host-resource limits. A bad path result means you should first localize the route with the hop-by-hop tools above.
A practical capture workflow resembles inspecting a device log: the NeoTeo phones section is unrelated to packet analysis, but it illustrates the same kind of device-focused troubleshooting context readers often need outside the terminal.
Use the video below as a visual supplement after you've narrowed the test to a specific host, interface, or service.
Quick Reference Chart and Troubleshooting Workflow
| Command | Platforms | Common syntax | Answers the question |
| ping | Windows, macOS, Linux | ping -c 10 host | Does the host answer, and how consistent is the delay? |
| traceroute / tracert | macOS, Linux, Windows | traceroute host | Where does the path change or stop responding? |
| tracepath | Linux | tracepath host | What path and MTU information are visible? |
| mtr | Linux, macOS, some Windows builds | mtr host | Does loss or delay persist at a particular hop? |
| ipconfig | Windows | ipconfig /all | What address, gateway, and resolver state does Windows have? |
| ip | Linux | ip addr show, ip route show | Is local addressing and routing correct? |
| ifconfig | macOS, Linux | ifconfig | What interfaces and addresses are present? |
| ss | Linux | ss -tulnp | Is a process listening on the expected socket? |
| netstat | Windows, macOS, Linux | netstat -ano | What connections, listeners, routes, and protocol counters exist? |
| dig / nslookup | Linux, macOS, Windows | dig hostname, nslookup hostname | Is DNS returning the expected answer? |
| arp / ip neigh | Windows, Linux | arp -a, ip neigh show | Which local hardware address answers for an IP? |
| tcpdump | Linux, macOS | tcpdump -i <interface> port <port> | What packets actually crossed the interface? |
| iperf3 | Windows, macOS, Linux | iperf3 -s, iperf3 -c <server> | Is the path capable of the expected throughput? |
A compact incident workflow is:
- Query the hostname with nslookup or dig.
- Inspect interface addressing and routes.
- Ping the gateway, then an intermediate host, then the destination.
- Run traceroute, tracert, tracepath, or mtr when the path is suspect.
- Check listeners and process ownership with ss or netstat.
- Capture the relevant traffic with tcpdump.
- Use iperf3 when the remaining question concerns throughput rather than reachability.
For additional publication resources or a direct route to the editorial team, use NeoTeo's contact page.
NeoTeo publishes practical technology guides and troubleshooting coverage that can help you apply these commands across computers, networks, and connected devices. Visit NeoTeo for step-by-step explainers, hardware coverage, and hands-on technology resources.
