Linux Network Troubleshooting: ping, traceroute, and ss Explained
The Essential Commands That Fix Internet Problems, Diagnose Server Issues, and Save IT Departments Daily
When the Internet Stops Working...
"The server is down."
"I can't connect to the database."
"The website won't load."
Every IT professional, system administrator, and developer hears these words regularly. And when they do, they don't panic, they troubleshoot.
Linux network troubleshooting isn't magic. It's a systematic process using powerful, built-in tools that reveal exactly what's happening between your computer and the rest of the world. Whether you're a student learning networking, a developer debugging applications, or a system administrator managing infrastructure mastering ping, traceroute, and ss transforms network problems from mysteries into solvable puzzles.
Let's decode how networks break and how to fix them.
How Network Communication Works
Before troubleshooting, understand this simple truth:
Network communication is like sending a letter:
- Your computer is the sender
- The destination (server/website) is the receiver
- Routers are post offices along the way
- Data travels in packets (envelopes)
When something breaks, it could be:
- Your connection (can't leave the house)
- A router in between (post office closed)
- The destination server (recipient moved)
- Firewall blocking traffic (security checkpoint)
Linux troubleshooting tools help you pinpoint exactly where the problem is.
ping: Is Anyone Home?
What ping Does
ping sends a simple message: "Are you there?" and waits for "Yes, I'm here!" back.
Think of it like knocking on a door. If someone answers, the connection works. If not, something's wrong.
Basic Usage
ping google.com
Output:
PING google.com (142.250.185.46): 56 data bytes
64 bytes from 142.250.185.46: icmp_seq=0 ttl=117 time=12.3 ms
64 bytes from 142.250.185.46: icmp_seq=1 ttl=117 time=11.8 ms
64 bytes from 142.250.185.46: icmp_seq=2 ttl=117 time=12.1 ms
What this tells you:
- ✅ Connection works – Google's server responded
- Response time: 12.3 ms – Fast (under 50ms is excellent)
- TTL (Time To Live): 117 – Packet can hop through 117 routers before dying
Real-World Scenario 1: Website Won't Load
Problem: Customer reports your website is down.
Troubleshooting:
ping yourwebsite.com
Outcome A: No response → Server is down or unreachable
Outcome B: Responds → Server is up; problem is elsewhere (maybe DNS, firewall, or web service)
Mini-story:
A startup's website suddenly stopped loading. Panic ensued. One ping command revealed the server was fine—the problem was their DNS configuration had expired. Ten minutes later, DNS updated, website back online. Crisis averted.
Advanced ping Options
Limit packet count:
ping -c 4 google.com
Sends only 4 packets, then stops.
Check response time statistics:
ping -c 10 google.com
See min/avg/max response times useful for detecting unstable connections.
Flood ping (requires root):
sudo ping -f 192.168.1.1
Sends packets as fast as possible—stress tests network (use carefully!).
traceroute: Where Does the Journey Break?
What traceroute Does
traceroute maps the entire path data travels from your computer to the destination—every router, every hop, every delay.
Think of it as GPS tracking for data packets.
If ping tells you "can't reach destination," traceroute tells you where it stopped.
Basic Usage
traceroute google.com
Output:
traceroute to google.com (142.250.185.46), 30 hops max, 60 byte packets
1 router.local (192.168.1.1) 1.234 ms 1.189 ms 1.156 ms
2 10.0.0.1 (10.0.0.1) 8.456 ms 8.234 ms 8.123 ms
3 isp-gateway.net (203.94.x.x) 12.345 ms 12.234 ms 12.123 ms
4 google-edge.net (142.250.x.x) 15.678 ms 15.567 ms 15.456 ms
5 google.com (142.250.185.46) 16.789 ms 16.678 ms 16.567 ms
What this shows:
- Hop 1: Your local router (home/office network)
- Hop 2: ISP equipment
- Hop 3: ISP gateway to the internet
- Hop 4: Google's edge server
- Hop 5: Destination reached
Each hop shows three response times (three test packets sent).
Real-World Scenario 2: Slow Database Connections
Problem: Application can connect to database, but queries are extremely slow.
Troubleshooting:
traceroute database.company.com
Discovered: Hop 7 shows * * * (timeout), then Hop 8 continues with 200ms delay.
Diagnosis: Router at Hop 7 is congested or misconfigured, adding massive latency.
Solution: Network team reroutes traffic around the problematic router. Database performance restored.
Advanced traceroute Usage
Use ICMP instead of UDP (sometimes more reliable):
traceroute -I google.com
Set maximum hops:
traceroute -m 15 google.com
Stops after 15 hops (useful for distant/unreachable servers).
Show IP addresses without resolving hostnames (faster):
traceroute -n google.com
ss: What's Talking on Your Network?
What ss Does
ss (socket statistics) shows all network connections on your system—what's listening, what's connected, who's talking to whom.
Think of it as security camera footage for your network activity.
It replaced the older netstat command and is faster, more powerful, and actively maintained.
Basic Usage
Show all connections:
ss
Show listening ports (services waiting for connections):
ss -tuln
Output:
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
tcp LISTEN 0 128 0.0.0.0:80 0.0.0.0:*
tcp LISTEN 0 128 0.0.0.0:443 0.0.0.0:*
What this shows:
- Port 22: SSH server listening (remote access)
- Port 80: HTTP web server listening
- Port 443: HTTPS web server listening
- 0.0.0.0: Listening on all network interfaces
Real-World Scenario 3: Security Audit
Task: Check if unauthorized services are running on a production server.
Command:
sudo ss -tuln | grep LISTEN
Discovered: Port 3306 (MySQL) exposed to the internet.
Security risk: Database should only be accessible internally, not publicly.
Fix:
sudo ufw deny 3306
Firewall now blocks external MySQL access. Breach prevented.
Advanced ss Usage
Show established connections:
ss -tun state established
See active connections right now.
Show connections to specific port:
ss -tn sport = :80
All connections to web server (port 80).
Show process using each connection:
ss -tulnp
Reveals which program owns each connection—critical for troubleshooting.
Example output:
tcp LISTEN 0 128 *:80 *:* users:(("nginx",pid=1234,fd=6))
Shows nginx (PID 1234) is listening on port 80.
Combining Tools: Real-World Troubleshooting Workflow
Problem: "I can't access the company file server."
Step 1: Can you reach it?
ping fileserver.company.com
- Success: Server is reachable → Problem is authentication or permissions
- Failure: Server unreachable → Continue investigating
Step 2: Where does connectivity break?
traceroute fileserver.company.com
- If it stops at Hop 3 → Network infrastructure issue
- If it reaches the server but times out → Server firewall or service down
Step 3: Is the service running?
ssh user@fileserver.company.com
sudo ss -tuln | grep 445
- Port 445 (SMB/file sharing) listening? → Service is up
- No port 445? → Service crashed or misconfigured
Result: Systematic diagnosis in under 5 minutes instead of guessing for hours.
Why These Skills Are Career-Essential
System Administrators
Daily network troubleshooting, maintaining uptime, diagnosing connectivity issues.
DevOps Engineers
Debugging microservices communication, monitoring distributed systems, optimizing latency.
Cybersecurity Professionals
Detecting suspicious connections, identifying port scans, investigating breaches.
Cloud Engineers
Troubleshooting VPC connectivity, debugging load balancers, analyzing network bottlenecks.
Developers
Debugging API calls, testing service availability, understanding application behavior.
Common Network Issues and Their Solutions
Issue 1: High Latency (Slow Connections)
Symptom: ping shows response times over 100ms
Diagnosis:
traceroute destination.com
Look for hops with sudden latency spikes.
Solutions:
- Congested network link → Upgrade bandwidth or reroute
- Distant server → Use CDN or regional deployment
- WiFi interference → Switch to wired connection
Issue 2: Connection Refused
Symptom: ping works, but application fails
Diagnosis:
ss -tuln | grep PORT_NUMBER
If service not listening:
- Service crashed → Restart it
- Wrong port configured → Check configuration
- Firewall blocking → Adjust rules
Issue 3: Intermittent Failures
Symptom: Sometimes works, sometimes doesn't
Diagnosis:
ping -c 100 destination.com
Check packet loss percentage.
High packet loss indicates:
- Failing network equipment
- Overloaded connection
- ISP routing issues
💡 Did You Know?
- ping was named after the sonar sound submarines use to detect objects
- traceroute uses TTL manipulation to map routes—clever networking trick
- ss is 10x faster than the old
netstatcommand for large connection lists - Major internet outages are often diagnosed using these exact tools
⚡ Pro Tips
Tip 1: Create aliases for common troubleshooting commands:
alias netcheck='ping -c 4 8.8.8.8 && ss -tuln'
Tip 2: Use mtr (my traceroute) for continuous real-time monitoring:
mtr google.com
Combines ping and traceroute with live updates.
Tip 3: Document baselines when everything works normally. Compare against them when troubleshooting:
ping -c 10 server.com > baseline-ping.txt
traceroute server.com > baseline-route.txt
Free Resources to Master Network Troubleshooting
- TryHackMe – Networking fundamentals and labs
- Cisco Networking Academy – Free networking courses
- Professor Messer (YouTube) – Network+ certification videos
- Linux man pages –
man ping,man traceroute,man ss
From Guessing to Knowing
Before these tools, network problems were black boxes. "It doesn't work" was the diagnosis.
Now you have X-ray vision. You can see packets traveling, routers responding, services listening. You can pinpoint problems with surgical precision.
Master ping, traceroute, and ss—and you've mastered the foundation of network troubleshooting.
👉 Open a terminal right now. Run these commands.
👉 Break your own test network. Fix it. Learn by doing.
👉 Share your findings with your team—or teach someone else.
That's how beginners become network engineers. And how network engineers become indispensable.
If this article demystified networking for you, share it with someone struggling with connectivity issues. The next server outage prevented might be because someone read this.
Comments
Post a Comment