Basic Networking Commands (ping, curl, ss)
Troubleshooting anything network-related on Linux — 'is the server up?', 'is this port actually listening?', 'why can't my app reach that API?' — comes down to a small toolkit of command-line utilities that every administrator and developer should be fluent in. ping tests basic reachability at the ICMP level, curl (and its sibling wget) exercise actual application-layer protocols like HTTP, ss (and its predecessor netstat) show what's listening and what's connected on the local machine, and tools like dig/nslookup, traceroute, and ip round out the picture for DNS and routing. Knowing which tool answers which question — and reading their output correctly — turns network troubleshooting from guesswork into a methodical process.
Cricket analogy: Diagnosing 'is the ground even accessible' is like a groundsman checking the pitch before a match: ping checks if the venue exists at all, curl checks if the actual match (HTTP service) is playable, and ss checks who's already occupying the nets locally.
ping: Basic Reachability
ping sends ICMP Echo Request packets to a target host and reports whether/how quickly ICMP Echo Reply packets come back, along with round-trip time statistics. It answers a narrow but foundational question: is there a live network path to this host at all, and how does the round-trip latency look? By default ping runs indefinitely until interrupted with Ctrl-C; use -c N to send exactly N packets and exit automatically, which is essential in scripts. A crucial caveat: many hosts and firewalls deliberately block ICMP for security/DoS-mitigation reasons, so a failed ping does NOT necessarily mean the host is down or unreachable at the application layer — it may simply mean ICMP is filtered while the actual service (e.g. HTTPS on port 443) works fine.
Cricket analogy: ping is like knocking on the boundary rope to see if there's an echo back from the stadium, using -c 5 to send exactly 5 knocks and stop; a failed ping doesn't mean no match is happening — the stadium might just have its PA system (ICMP) muted even though play (HTTPS) continues.
# Send exactly 4 pings, then stop (good for scripting)
ping -c 4 example.com
# Sample output line:
# 64 bytes from 93.184.216.34: icmp_seq=1 ttl=56 time=11.2 ms
# Flood-free interval control (1 packet every 2 seconds)
ping -c 5 -i 2 10.0.0.5
# Use ping to check if a host is up, in a script
if ping -c 1 -W 2 10.0.0.5 &>/dev/null; then
echo "Host is reachable"
else
echo "Host is unreachable (or blocking ICMP)"
ficurl: Testing Application-Layer Endpoints
curl transfers data to or from a URL using virtually any protocol (HTTP, HTTPS, FTP, and more), making it the standard tool for testing web APIs and services directly from the command line. Unlike ping, curl actually exercises the application protocol, so it tells you whether a web server is not just network-reachable but actually responding correctly at the HTTP layer — distinguishing, for example, a working service (200 OK) from a misconfigured one (502 Bad Gateway) or an authentication problem (401/403). Key flags to know: -I fetches only response headers (a HEAD request), -v shows the full request/response exchange including TLS handshake details, -o file saves the response body, -X sets the HTTP method, -H adds a header, and -d sends a request body (implicitly switching to POST).
Cricket analogy: curl is like an umpire actually reviewing the replay (application layer) rather than just checking the stadium lights are on; -I peeks at just the match officials' report (headers), -v shows the full review process including third-umpire signals (TLS handshake), and -X/-d let you submit a formal appeal (POST request).
# Simple GET request, printing the response body
curl https://api.example.com/health
# Show only the HTTP status line and headers (no body)
curl -I https://api.example.com/health
# Verbose mode: see the full request/response and TLS handshake
curl -v https://api.example.com/health
# POST JSON data with a custom header
curl -X POST https://api.example.com/users \
-H "Content-Type: application/json" \
-d '{"name": "Ada"}'
# Fail with a non-zero exit code on HTTP errors (4xx/5xx), useful in scripts
curl -fsSL https://api.example.com/health -o /dev/null
echo "Exit code: $?"
# Follow redirects (-L) and show timing breakdown
curl -L -w "\ntotal time: %{time_total}s\n" -o /dev/null -s https://example.comThe -f (--fail) flag is essential for curl used inside scripts: without it, curl exits 0 (success) even when the server returns an HTTP error status like 404 or 500, because as far as curl's transport layer is concerned, it successfully received *a* response — the error is a curl script author's most common surprise. Combining -fsSL (fail on HTTP errors, silent progress meter, but still show errors, follow redirects) is a widely used idiom for reliable scripted health checks and downloads.
ss: Inspecting Sockets and Listening Ports
ss (socket statistics) is the modern replacement for the older netstat, reading directly from the kernel's netlink interface rather than parsing /proc, which makes it significantly faster on systems with many open connections. It answers questions like 'what process is listening on port 8080?' and 'what remote connections does this machine currently have open?'. -t filters to TCP, -u to UDP, -l shows only listening sockets, -n shows numeric addresses/ports instead of resolving hostnames (much faster and often clearer), and -p shows the owning process name and PID (typically requires root/sudo for other users' processes).
Cricket analogy: ss is like a modern ball-tracking system reading directly from the stump sensors (kernel netlink) instead of a scorer manually flipping through pages (/proc), answering 'which bowler is active on which end'; -t filters to the main format, -l shows only bowlers ready to bowl, and -p names the actual player.
# All listening TCP sockets, with the owning process
sudo ss -tlnp
# Sample output line:
# LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
# All established TCP connections
ss -tn state established
# Only UDP listeners
ss -ulnp
# Summary statistics of all socket types
ss -s
# Check specifically whether something is listening on port 5432 (Postgres)
sudo ss -tlnp | grep 5432netstat is deprecated on most modern distributions (part of the older net-tools package, which is often not installed by default anymore) in favor of the iproute2 suite (ss, ip). Scripts and runbooks still referencing netstat -tulnp should be updated to the ss equivalent (ss -tulnp), since net-tools may simply be absent on a fresh minimal server install, causing 'command not found' failures during an incident — precisely the worst time to discover a missing dependency.
Putting It Together: A Troubleshooting Sequence
A methodical approach to 'my app can't reach service X' typically layers these tools: first ping (or, if ICMP is blocked, skip straight to the next step) to check basic network reachability; then ss -tlnp on the target host (if you have access) to confirm the service is actually listening on the expected port and interface (0.0.0.0 vs 127.0.0.1 matters — a service bound only to localhost won't accept external connections); then curl -v from the client to exercise the actual protocol and see exactly where the failure occurs — DNS resolution, TCP connection, TLS handshake, or the HTTP response itself. This layered diagnosis, from network to transport to application, quickly isolates whether the problem is connectivity, configuration, or the application logic.
Cricket analogy: Diagnosing why a fan's app can't reach live scores layers checks like a broadcast engineer: ping the stadium (basic reachability), then ss -tlnp at the venue to confirm the camera feed is actually broadcasting on the right channel, then curl -v from the viewer's side to see exactly where the signal (DNS, connection, or feed itself) breaks.
- ping tests ICMP-level reachability and round-trip latency; use -c N in scripts so it doesn't run forever, and remember ICMP is often blocked even when the service itself works.
- curl exercises real application protocols (HTTP/HTTPS/etc.) and is the standard tool for testing APIs; -I fetches headers only, -v shows the full exchange.
- curl's -f flag is required for scripts to actually fail on HTTP error status codes — without it, curl exits 0 even on a 404 or 500.
- ss is the modern, faster replacement for netstat, reading from the kernel's netlink interface; -tlnp shows listening TCP sockets with owning processes.
- A service listening on 127.0.0.1 only accepts local connections; check the bound address (0.0.0.0 vs 127.0.0.1) when 'it's listening but unreachable remotely'.
- Layer diagnosis from network (ping) to transport/socket (ss) to application (curl -v) to isolate exactly where a connectivity problem originates.
Practice what you learned
1. Why might `ping example.com` fail even though the web server at example.com is fully operational and reachable over HTTPS?
2. By default, what exit code does `curl` return when it successfully connects and receives an HTTP 500 error response, WITHOUT the -f flag?
3. Which `ss` command shows all listening TCP sockets along with the process name and PID that owns each one?
4. A service is confirmed listening via `ss -tlnp` showing `127.0.0.1:8080`, but remote clients cannot connect to it. What is the most likely explanation?
5. Why has `ss` largely replaced `netstat` as the standard tool for inspecting sockets on modern Linux distributions?
Was this page helpful?
You May Also Like
SSH and Remote Access
Understand SSH's client-server model, key-based authentication, port forwarding, and configuration practices for securely administering remote Linux systems.
Monitoring Processes with ps and top
Learn to inspect running processes with ps snapshots and the interactive top monitor, reading CPU, memory, and state columns to diagnose system load.
Reading and Managing Logs (journalctl, /var/log)
Master the two dominant Linux logging models — the systemd journal and traditional flat-file logs in /var/log — to diagnose issues and manage log retention.
systemd and Managing Services
Learn how systemd manages services, sockets, and timers as units, and how to start, stop, enable, and inspect them with systemctl and journalctl.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics