Gyaan

Network Debugging Toolkit

intermediate debugging tools cli tcpdump wireshark networking

When the network is broken, knowing the right tool saves hours. This is the toolkit that covers 99% of “why can’t I reach this server” debugging.

ping — Is the host reachable?

The simplest test. Sends ICMP echo requests and prints round-trip time.

ping -c 5 google.com
# Use it for: connectivity, RTT, packet loss

If ping works but TCP doesn’t, the issue is firewall / port-level. Some networks block ICMP, so a failing ping doesn’t always mean the host is down.

traceroute / mtr — What’s the path?

traceroute shows every hop between us and the destination. mtr is traceroute + ping — continuous, with packet loss per hop. Always prefer mtr.

traceroute google.com
mtr google.com
# Use it for: locating slow / lossy hops, routing issues

If hop 7 has 30% loss, the problem is probably at that ISP, not our app.

dig / nslookup — DNS resolution

dig is the modern, scriptable DNS tool. nslookup is older but ubiquitous.

# Resolve a record
dig example.com

# Use a specific resolver
dig @8.8.8.8 example.com

# Trace the resolution from root
dig +trace example.com

# Other record types
dig example.com MX
dig example.com TXT
dig example.com NS

When a site “doesn’t load,” 90% of the time DNS is the first thing to check.

netstat / ss — What’s listening?

ss (socket statistics) replaces the older netstat.

# All listening TCP ports
ss -tlnp

# All connections, with PIDs
ss -tnp

# Show stats per protocol
ss -s

Use it for: “is my service even listening on port 3000?” or “how many connections does this server have right now?“

lsof -i — Which process owns a port?

# Who's using port 3000?
lsof -i :3000

# All network sockets used by a PID
lsof -i -p 12345

Best one-liner for “address already in use” errors.

tcpdump — Inspect raw packets

The Swiss army knife. Captures and prints (or saves) packets matching a filter.

# Capture HTTP traffic on eth0
sudo tcpdump -i eth0 'tcp port 80'

# Capture and save to a pcap file (for Wireshark)
sudo tcpdump -i any -w /tmp/capture.pcap 'host 1.2.3.4'

# Filter by host and port
sudo tcpdump -i eth0 -nn 'host 1.2.3.4 and tcp port 443'

# Verbose, show packet contents
sudo tcpdump -i eth0 -vvX 'tcp port 443'

Use it when curl fails but you can’t tell if packets are even going out. Capture, then inspect.

Wireshark — GUI for pcap analysis

Open the pcap file from tcpdump in Wireshark for visual analysis. Filter by tcp.port == 443, follow TCP streams, decode TLS handshakes, see retransmissions in red.

wireshark /tmp/capture.pcap

Use it when tcpdump’s text output isn’t enough — long sessions, complex protocols, retransmission analysis.

curl -v — HTTP debugging

curl is the universal HTTP debugger. The -v flag shows everything — DNS, connect, TLS, request/response headers, body.

# Verbose request
curl -v https://example.com

# Show only response headers
curl -I https://example.com

# Time breakdown of each phase
curl -w "@-" -o /dev/null -s https://example.com <<< '
  time_namelookup:  %{time_namelookup}\n
  time_connect:     %{time_connect}\n
  time_appconnect:  %{time_appconnect}\n
  time_starttransfer: %{time_starttransfer}\n
  time_total:       %{time_total}\n'

# Force HTTP/2 or HTTP/1.1
curl -v --http2 https://example.com
curl -v --http1.1 https://example.com

The timing output is gold for “why is this slow?” investigations — it tells us whether the bottleneck is DNS, TCP, TLS, or the server.

openssl s_client — TLS debugging

When HTTPS misbehaves and we need to see the handshake.

# Connect and show cert + handshake
openssl s_client -connect example.com:443 -servername example.com

# Force TLS 1.2 (test compatibility)
openssl s_client -connect example.com:443 -tls1_2

# Check cert expiry
echo | openssl s_client -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates

Use it for cert errors, “wrong version of TLS,” or to see the cert chain a server actually serves.

DevTools Network Tab

The browser’s built-in network inspector. Worth its weight in gold for frontend issues.

  • Waterfall — see request order and timing.
  • Headers — request/response headers, cookies, cache hits.
  • Timing — DNS, connection, TLS, TTFB, content download.
  • Throttling — simulate slow 3G to find slow assets.
  • Initiator — what triggered each request.

For most “the page is slow” debugging, this is the first stop, not tcpdump.

Quick Cheat Sheet — Symptom to Tool

"Can I reach the host?"          ping, mtr
"Where's the path slow?"          mtr, traceroute
"DNS not resolving?"              dig, nslookup
"Is my service listening?"        ss -tlnp, lsof -i
"Port already in use?"            lsof -i :PORT
"Are packets going out?"          tcpdump
"What's the HTTP response?"       curl -v
"TLS / cert problem?"             openssl s_client
"Page slow in the browser?"       DevTools Network tab
"Need to deeply analyze pcap?"    Wireshark

Interview Tip

Interviewers love asking “the API is slow / unreachable, walk me through how you’d debug it.” A strong answer goes top-down: DevTools / curl → DNS (dig) → ping/mtr → ss / lsof on the server → tcpdump if needed. Knowing which tool answers which question shows real ops experience.

References