Skip to main content
Back to module
Networking Fundamentals · Troubleshooting

ping, traceroute, and netstat

Reading45mLesson 1 of 3 in this module

Use ping, traceroute and netstat to diagnose a connectivity problem one layer at a time.

Why it matters

"I can't connect" is one of the most common tickets in IT, cloud and database work. Three built-in tools answer most of it in a few minutes: ping (can I reach it?), traceroute (where does the path break?), and netstat or ss (what is my computer connected to and listening on?). The skill is not the commands themselves but running them in a sensible order and reading the results.

Start with your own configuration

Before testing anything remote, check what your machine thinks its settings are:

ipconfig /all          # Windows
ip addr; ip route      # Linux
ifconfig; netstat -rn  # macOS

Look for: an IP address in the expected range (not 169.254.x.x), a subnet mask, a default gateway, and DNS servers.

ping: is it reachable?

ping sends ICMP echo requests and reports replies and round-trip time:

$ ping -c 4 1.1.1.1
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=12.4 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=11.9 ms
...
4 packets transmitted, 4 received, 0% packet loss

(On Windows ping sends 4 by default; on macOS/Linux it runs until Ctrl+C unless you add -c 4.)

Read the result:

  • Replies with low, steady times: reachable.
  • Request timed out: no reply. The host may be down, the path broken, or a firewall may block ICMP. Many servers block ping on purpose, so a timeout alone does not prove a server is down.
  • Destination host unreachable: a router (or your own machine) has no route.
  • Packet loss or very uneven times: a congested or flaky link, often Wi-Fi.

traceroute: where does it break?

Every IP packet has a TTL (hop limit) that each router decrements; at zero, the router discards it and sends back an ICMP "time exceeded". traceroute (Windows: tracert) sends packets with TTL 1, 2, 3 and so on, so each router along the path reveals itself:

$ traceroute example.com
 1  192.168.1.1     1.8 ms
 2  10.40.0.1       9.7 ms
 3  * * *
 4  72.14.215.85   14.2 ms
 ...
11  93.184.215.14  21.3 ms
  • Hop 1 is your router. If that fails, the problem is in your home or office.
  • * * * on a middle hop is usually just a router that does not answer traceroute; if later hops answer, ignore it.
  • If every hop after a certain point is * * *, the path breaks there (or a firewall drops the probes).
  • A big, sustained jump in time from one hop onward points to a slow link at that hop.

netstat and ss: what is my machine doing?

netstat -an            # all connections and listening ports, numeric
netstat -ano           # Windows: add the process ID
ss -tulpn              # Linux: TCP/UDP listening sockets with process

Look for states: LISTEN (a service waiting for connections), ESTABLISHED (an active connection), TIME_WAIT (recently closed). This answers "is my web server actually listening on 8080?" and "what is this program connected to?".

Worked example: a layered diagnosis

A user cannot open an internal web app at http://intranet.local:8080.

  1. ipconfig shows 192.168.1.57/24, gateway 192.168.1.1. Settings look fine.
  2. ping 192.168.1.1 replies. The local network works.
  3. ping 1.1.1.1 replies. Internet routing works.
  4. nslookup intranet.local returns NXDOMAIN. DNS is the problem. The user's DNS server is a public resolver that does not know internal names.
  5. The fix is to use the company DNS server. If DNS had worked, the next step would be netstat/ss on the server to confirm something LISTENs on 8080, and then the firewall.

The order matters: you proved each lower layer before moving up, and stopped at the first failure.

Other handy tools

  • nslookup / dig for DNS (previous module).
  • curl -v https://example.com shows the TCP connection, TLS handshake and HTTP response in one go.
  • Test-NetConnection example.com -Port 443 in PowerShell, or nc -vz example.com 443 on macOS/Linux, checks one TCP port.

Common mistakes

  • Concluding a server is down because ping fails. Try the actual service port.
  • Panicking over * * * in the middle of a traceroute when the destination still answers.
  • Skipping the local checks and debugging the internet when the laptop has a 169.254 address.
  • Scanning or tracing networks you do not own beyond normal use. Probing other people's systems can break policies or laws.

Quick recap

  • Check your own config first, then ping loopback, gateway, public IP, then a name.
  • traceroute shows each hop; look at where replies stop or times jump.
  • netstat/ss shows listening ports and connections.
  • Work up the layers and stop at the first failure.

Try it

Open the Do tab and run a full troubleshooting pass on your own machine.

Also in this lesson: