Question first, command second
A network command is useful only when it answers a specific question. Before typing anything, state what you want to prove: does the interface have the expected address, is the default route present, can the gateway be resolved, does DNS return the expected record, is a port listening, or where does the path stop?
This discipline prevents command output from becoming noise. Save the relevant result, compare it with the expected state, and use the difference to choose the next test.
Windows: interfaces and configuration
ipconfig /all shows addresses, masks or prefixes, default gateways, DNS servers, DHCP state, and adapter details. PowerShell adds structured commands such as Get-NetIPConfiguration, Get-NetIPAddress, and Get-NetAdapter, which are easier to filter and automate.
Check that the active interface is the one you expect and that it has the correct network parameters. An APIPA address in 169.254.0.0/16, missing gateway, disabled adapter, or unexpected DNS server immediately changes the troubleshooting path.
Windows: routes and neighbors
route print and Get-NetRoute expose the routing table. Look for the destination prefix, metric, next hop, and interface. arp -a and Get-NetNeighbor show IPv4 ARP and IPv6 neighbor state.
If the route is correct but the gateway cannot be resolved to a link-layer neighbor, focus on the local VLAN and Layer 2 path instead of the remote network.
Windows: ping, tracert, and Test-NetConnection
ping can test reachability and round-trip behavior, while tracert sends probes with increasing TTL to reveal intermediate responses. PowerShell Test-NetConnection can also test a TCP port, which is often more meaningful than ICMP when an application uses a specific service.
A failed ping does not prove the destination is down because ICMP may be filtered. Conversely, a successful ping does not prove that HTTPS, SSH, or DNS works. Match the test to the protocol that matters.
Windows: DNS
nslookup remains widely available, while PowerShell Resolve-DnsName exposes record types and richer output. Query the resolver the client is actually configured to use, then compare with another resolver or authoritative data when the result is suspicious.
Distinguish a timeout from NXDOMAIN, SERVFAIL, and a valid but unexpected answer. Each points toward a different class of failure.
Linux: interfaces and addresses
Modern Linux networking commonly uses the ip suite. ip link shows link state and attributes, while ip addr displays IPv4 and IPv6 addresses. Distribution-specific tools such as NetworkManager add higher-level configuration views.
Check operational state, MTU, addresses, and whether the expected interface owns the source address that applications are using.
Linux: routes and neighbors
ip route shows IPv4 routes and ip -6 route shows IPv6 routes. ip route get <destination> is especially useful because it asks the kernel which route, source address, and next hop it would actually select for a destination.
ip neigh displays ARP and Neighbor Discovery state. Entries that remain incomplete or failed indicate a local reachability problem before routing to remote networks can succeed.
Linux: ping, tracepath, and traceroute
ping is useful for controlled reachability tests. tracepath and traceroute explore path behavior and can reveal where responses stop or where path MTU information changes. Different probe types may produce different results because firewalls treat ICMP, UDP, and TCP differently.
Use a known-good comparison and remember that intermediate routers may suppress replies while still forwarding traffic.
Linux: sockets and ports
ss shows listening sockets, established connections, addresses, ports, and protocol state. It largely replaces older netstat usage. Commands such as ss -lntup help verify whether the expected service is actually listening and on which address.
For remote tests, tools such as nc can confirm whether a TCP or UDP endpoint is reachable, but interpret UDP carefully because the protocol does not establish sessions in the same way as TCP.
Linux: DNS and resolver
dig provides detailed DNS query information: server used, response code, flags, answer sections, TTL, and timing. resolvectl can expose systemd-resolved state, per-interface DNS servers, and search domains on systems that use it.
Test both names and specific record types. A service may depend on SRV, TXT, CNAME, or reverse PTR records rather than only A and AAAA.
macOS: useful equivalents
macOS provides ifconfig, route, netstat, arp, ndp, ping, traceroute, dig, and scutil --dns. The exact syntax differs from Linux even when command names look similar.
Use route -n get <destination> to inspect the selected route and scutil --dns when resolver behavior depends on VPNs or multiple interfaces.
Packet capture from the CLI: tcpdump and TShark
tcpdump captures packets with BPF capture filters and can write PCAP files for later analysis. tshark is Wireshark's command-line analyzer and supports both capture and display filters. These tools are valuable on servers, routers, containers, or remote systems without a graphical interface.
Capture narrowly when possible: choose the correct interface, host, port, or protocol and preserve timestamps. A focused capture is easier to analyze and safer to handle.
A command map by question
Ask “what is my configuration?” and inspect interfaces and addresses. Ask “where will this destination go?” and inspect the route. Ask “can I resolve the next hop?” and inspect neighbors. Ask “does the name resolve?” and query DNS. Ask “is the service listening?” and inspect sockets. Ask “what happened on the wire?” and capture packets.
This question-to-tool mapping is more reusable than memorizing long command lists.
Permissions and safety
Some commands require administrative privileges, especially packet capture and low-level interface operations. Avoid destructive commands during diagnosis unless you have a rollback plan. Flushing neighbor tables, resetting interfaces, or restarting services changes the state you are trying to observe.
Packet captures can contain credentials, identifiers, internal addresses, and application data. Store and share them as sensitive operational artifacts.
Interpret results without jumping to conclusions
A timeout, unreachable message, reset, or DNS error is evidence, but it may be generated by an intermediate device rather than the endpoint. Correlate multiple views. For example, a TCP connection timeout plus firewall deny counters is stronger evidence than the timeout alone.
Always distinguish what a command directly proves from what you infer. This habit reduces false diagnoses.
Practical case: I have an IP address but cannot browse
First inspect address, prefix, gateway, and DNS. Test the local gateway, then a known remote IP. If remote IP connectivity works, query DNS. If DNS works, test the application's TCP port. Compare the route and use a packet capture if the connection still fails.
This sequence narrows the problem from local link to routing, name resolution, and application policy without changing configuration prematurely.
Next step
When command output cannot explain why packets are missing, duplicated, retransmitted, or rejected, move to Wireshark. Packet-level evidence lets you validate the exact request and response sequence.