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.

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
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
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
Quick check
nc -zv 203.0.113.20 443 says 'Connection refused'. What does that most likely mean?
Go deeper
- 1Practice using ping and traceroute to diagnose a connectivity issue.
- 2Use curl to test an HTTP endpoint's response directly from the command line.
- 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.