Stop 03 · Networking FundamentalsTopics · 9/9

Common Network Troubleshooting

Part of the DevOps Roadmap

In short

'The site is down' could mean DNS, a firewall, a dead process or a slow database. Checking layer by layer, in order, turns a panicked hour into a calm ten minutes.

A practical toolkit (ping, traceroute, curl, netstat/ss) for diagnosing connectivity issues — knowing where to look first turns a multi-hour outage investigation into a 10-minute fix.

The mascot climbs to a rooftop water tank with a torch, a dry kitchen tap visible below.

Think of it like this

No water in the tap

When the tap is dry, you don't call the municipality first. You check the tap, then the overhead tank, then the main valve, then whether the society supply is on. Network troubleshooting works the same way: start near you and move outwards, one check at a time.

Watch it happen

Checking, from outside in

DNS
Reach
Port
HTTP
Service

1/5dig shop.example.com: does the name resolve to the IP you expect? Wrong IP means a DNS problem.

The big ideas

What you need to know

Timeout vs refused

A timeout means packets are dropped, often by a firewall. 'Connection refused' means you reached the machine but nothing listens on that port.

One layer at a time

Confirm DNS before blaming the app. Skipping layers is how people spend hours on the wrong problem.

Check from both sides

If curl works on the server itself but not from outside, the problem is between them: firewall or load balancer.

Write down what you tried

Note each command and result. It speeds up the fix and makes the postmortem easy.

See it in code

Walk through the code

bash
1dig +short shop.example.com          # 1. DNS: which IP?2ping -c 3 203.0.113.20                # 2. can I reach it?3traceroute 203.0.113.20               #    where does it stop?4nc -zv 203.0.113.20 443               # 3. is the port open?5curl -sv https://shop.example.com -o /dev/null   # 4. HTTP + TLS6 7# 5. on the server itself8sudo ss -ltnp | grep 443              # who is listening?9curl -s localhost:3000/health         # does the app answer locally?

1/4Check the name points to the IP you expect.

Run these in order and stop at the first one that fails. That's where your problem lives.

Save yourself the pain

Common mistakes

Oops

Restarting the app the moment the site is down, before checking anything.

Do this instead

Run the checks first. If DNS or the firewall is the issue, a restart wastes time and hides clues.

Oops

Deciding the server is dead because ping fails.

Do this instead

Many cloud setups block ping. Test the actual port with nc or curl before drawing conclusions.

Your mission

Break it three ways

~30 min

Quick check

nc -zv 203.0.113.20 443 says 'Connection refused'. What does that most likely mean?

Go deeper

  1. 1Practice using ping and traceroute to diagnose a connectivity issue.
  2. 2Use curl to test an HTTP endpoint's response directly from the command line.
  3. 3Learn a systematic troubleshooting order: local machine, DNS, network path, then the remote server.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge