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.

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.

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).

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).

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.