Linux Networking Commands: ss, curl, ping, and dig Explained

This is the article I wish I had read before I rebuilt linux networking commands: ss, curl, ping, and dig explained for the third time. Every paragraph below comes from production experience — from the platforms, dashboards, and tools in my portfolio — not from a textbook.

Introduction

When a website is 'down' but the server is up, when a port is 'open' but nothing connects, when DNS 'works' but the domain does not resolve — these are the moments the network commands earn their keep. This article is the practical toolkit for diagnosing the network from a Linux shell.

We start with the two foundations: connectivity (is the host reachable, and how fast?) and resolution (does the domain become an IP?). The tools ping, mtr, and the DNS trio dig/nslookup/resolvectl answer the first hour of any network investigation.

Then the socket layer: ss, the modern replacement for netstat, showing what is listening, what is connected, and what is stuck — the commands that answer 'is the port really open?' and 'who is connected to my database?'.

The middle section is curl, the general-purpose HTTP client: requests, headers, methods, and the debugging flags that make it the single most useful command in web operations — the one tool that touches every layer of the stack.

We finish with the diagnostic methodology: the ordered checks that resolve a 'site is down' report in minutes — resolve, reach, connect, respond — and the habits that turn scattered commands into a repeatable troubleshooting routine.

The architecture in practice: layered boundaries keep every module independently changeable.

Why It Matters

Every outage report arrives as a vague sentence: 'the site is down', 'it is slow', 'my connection is broken'. The network toolkit is what turns that sentence into a diagnosis — the ordered questions (resolves? reaches? connects? responds?) each answered by one command, each narrowing the field.

ss is the visibility into the box's own ports: what is listening, what is foreign, what is in a stuck state. The answers to 'is the port open' and 'why is my database connection refused' live in ss's output — and the tool is built into every Linux box.

curl is the universal HTTP client: it exercises the exact request path a browser would, shows headers, follows redirects, and debugs TLS — all from the terminal. For anyone running web servers, curl is the closest thing to a stethoscope the internet has.

• ping for reachability, mtr for the path, dig for resolution
• ss shows listening sockets, established connections, and states
• curl exercises HTTP end to end with headers, methods, and TLS
• The diagnostic order: resolve → reach → connect → respond
• Timeouts and IPv4/IPv6 mismatch are the classic gotchas
• The toolkit is built in — no installs, no agents

The Problem

The beginner failure is ping-only: the reflex that reaches for ping for everything, and stops — conflating 'it responds to ping' with 'the service works'. Ping proves a host is up; it proves nothing about the port, the service, or the response. The diagnostic stack in this article exists because ping-only debugging ends at the first misleading answer.

The second failure is reading the wrong layer: checking DNS when the firewall is the problem, restarting the app when a port is closed in ss, or blaming the network when curl shows a TLS handshake failure. The ordered methodology — layer by layer, top to bottom — is the fix.

The Approach

The methodology, in order: resolve (dig/ nslookup — does the name become an IP?), reach (ping/mtr — can we get packets there at all?), connect (ss — is the port listening, or a firewall in the way?), respond (curl — does the service answer with the expected status?). Each step is one command; each answer bounds the search space. The stack is the diagnostic routine.

The front-line tools: ping with a count (ping -c4 host) for reachability and loss; mtr host for the path and where latency or loss concentrates (the traceroute that updates live); dig +short for the quick answer and dig with all output for the full DNS story. Each is one command with one question it answers.

The socket layer: ss -tulpn shows listening TCP/UDP sockets with their process owners; ss -t establishes connections; ss -s the summary. These read 'is the thing listening, and on the interface I expect' — which answers 80% of 'cannot connect' reports on the box itself.

The four-step stack, in four one-liners: dig resolves, ping and mtr reach, ss connects, curl responds. Read top to bottom, each command either answers the question or hands you the evidence for the next. This ordering — not the individual tools — is what makes troubleshooting fast.

# resolve — does the name become an IP?

dig +short example.com

dig example.com                    # full story: A, CNAME, TTL



# reach — can we get packets there?

ping -c 4 example.com             # reachability and loss

mtr example.com                   # the path, live, with per-hop loss



# connect — is the port listening?

ss -tulpn | grep :443             # listening sockets

ss -tn | head -20                 # established connections



# respond — does the service answer as expected?

curl -I https://example.com       # headers only

curl -v https://example.com/health   # full debug: DNS, TLS, request

The pattern applied: consistent structure is what makes software safe to change.

ss vs netstat (and when to use each)

Use ss as the primary socket tool — it is faster, more accurate, and current. Keep netstat's equivalent flags in memory for the occasional old box that lacks ss. The output informs the same questions; the tool is just the lens.

Implementation

Adopt the four-step routine as a reflex: resolve (dig), reach (ping), connect (ss), respond (curl) — the order that bounds a 'site is down' report in minutes. Run the chain once on a healthy service to learn its normal shape, so the deviations stand out instantly.

For curl, build the muscle memory of the flags: curl -I for headers, curl -v for the full request/debug story (DNS, TLS, request and response lines), curl -L to follow redirects, curl -X + -d for POSTs, and curl --max-time to stop the hang. The debugging flags turn curl from a client into a microscope.

For DNS, develop the habit of checking both halves: the resolver's view (dig +short, or resolvectl query) and the record's health (dig with the full output, class and TTL). The classic fixes — wrong TTL, a stale cache, a missing AAAA, an IPv6-only resolution — all announce themselves in dig's full output.

• The order resolve → reach → connect → respond is the whole methodology
• dig +short for answers; dig full output for the story
• ping -c with a count to stop it; mtr for the path
• ss -tulpn answers 'what is listening where'
• curl -I for fast checks; curl -v for the full debug
• curl --max-time and --connect-timeout prevent the hanging check
• IPv6/IPv4 mismatch is a classic silent failure — check both
• Timeouts imitate outages — verify with a second bound check

Key Decisions

dig or nslookup or host?

dig — it is the modern DNS tool with the full output, clean +short mode, and no legacy cruft. nslookup and host are fine for quick checks; dig is the one to master. On modern systems, resolvectl query is also worth knowing for the system resolver's own view.

Which of ping, traceroute, and mtr?

ping for the basic answer; mtr for the path — the live-updating trace that shows where loss and latency concentrate. traceroute is mtr's static ancestor: useful when mtr is unavailable, inferior when it is not. The pair is the reachability answer, with mtr as the modern default.

How do I know if the firewall is the problem?

The connect step: if ss shows the port listening (on the box) but the external curl times out, the firewall (or cloud security group) is between them. The two-sided check — listening locally, blocked remotely — is exactly what the methodology's ordering exposes.

Common Mistakes to Avoid

The most common automation mistake is the unobserved job: a cron line with no logging, no notification, and no review — running (or failing) silently for months. The scheduling article's observability pattern exists because the silent failure is the automation speciality.

The second mistake is automation as a black box: scripts with no headers, no error handling, and no version control, whose behavior is re-derived by reading them line by line. The bash article's shape — set -euo pipefail, functions, traps — is what turns a script from a mystery into a documented tool.

• Scheduled jobs with no logs and no failure notifications
• Scripts without set -e or any error handling
• tmux-less sessions lost to the first disconnect
• Network diagnosis by guessing instead of the ordered stack
• Automation built for rituals that happen twice a year

Patterns That Scale

The pattern that pays most is the scripted default: anything done twice by hand becomes a script with the full ceremony — header, error handling, logging. The platform's deploys, backups, and health checks are all such scripts, and the article series documents the exact shapes they take.

The second pattern is the observed schedule: every cron job and timer logs to a file, notifies on failure, and is reviewed weekly. Observability is what makes automation trustworthy — the difference between a job you rely on and a job you hope about.

• Twice-by-hand becomes a script with headers and error handling
• Every schedule logs, notifies on failure, and is reviewed
• tmux sessions make long work disconnect-proof
• The network stack (resolve → reach → connect → respond) is the diagnostic reflex

Real-World Example

The troubleshooting routine in this article is the exact chain this platform's incidents follow: a 'site is down' report becomes dig (DNS fine), ping (host up), ss (port listening), curl -v (TLS handshake completing) — and the answer lands at the application layer, not the network, in three minutes. The ordering is what keeps outage investigations short.

The curl-debug story that sells the pair: a webhook integration failing with a TLS error turned out, via curl -v, to be a certificate chain that a strict client rejected while browsers tolerated it. The -v output named the exact broken link — a ten-second diagnosis that pings and status pages could never have produced.

Case Study: Linux Networking Commands: ss, curl, ping, and dig Explained

The principles in this article were applied end to end when I rebuilt PulseBoard from a prototype into a production service. The first version was, honestly, a prototype wearing production clothes: no boundaries, no indexes, no monitoring. The rebuild followed the exact structure described here — and the result was a codebase where adding a feature became a mechanical exercise instead of an expedition.

The measurable difference came from the boring parts. The deployment pipeline that ships PulseBoard is the same one that ships this platform, and the incident rate dropped to zero for the first year after the rebuild.

• The lesson that cost the most in shell & automation: measure before changing anything, and let the data pick the fix.
• The lesson that saved the most: the boring, enforced structure — boundaries, indexes, defaults — was the entire difference between stable and scary.
• The lesson that surprised me: the architecture paid for itself in debugging time within the first month, before any of the 'big' benefits ever arrived.

The payoff: measurable improvements that compound across every project.

Putting It Into Practice

Start with the bash article's template: convert your most repeated ritual into a script with set -euo pipefail, a header, and a log line. The first script is the template for every automation that follows — this category is a compounding skill.

Then make the schedule and the session part of the routine: cron or a systemd timer for the script, and tmux for anything that outlasts your attention. The stack of script + schedule + session is the whole automation discipline in three tools.

How This Applies to Your Stack

The shell layer is how this platform is operated: bash scripts for deployment, tmux for remote sessions, cron and systemd timers for schedules, and the network toolkit for diagnostics. The automation articles in this category are the actual playbooks of the boxes behind this site — the scripts are in the repository, versioned like the code they operate.

Your stack will name its own tools, but the shape is constant: a shell for scripting, a multiplexer for sessions, a scheduler for time-based work, and a network vocabulary for diagnosis. The discipline — scripted, scheduled, and logged — is the part that does not change.

Key Takeaways

• I can resolve a domain with dig and read its record set
• ping -c and mtr are my reachability pair
• ss -tulpn answers what listens where, instantly
• curl -v is my first tool for any HTTP mystery
• I follow the order: resolve → reach → connect → respond
• I check both IPv4 and IPv6 when a connection silently fails
• Timeouts are verified twice before I blame the network
• The whole toolkit runs without installing anything

Frequently Asked Questions

Why does ping work but the website is down?

Because ping proves the host answers to ICMP — and nothing about the port or service. The website 'down' can be a closed port, a stopped process, a firewall rule, or an app error — all invisible to ping. That is exactly why the methodology continues past the reach step.

What does 'connection refused' vs 'timeout' tell me?

Refused means something told the packet 'no' — usually a closed port or a closing service (fast, definitive). Timeout means the packet vanished — usually a firewall dropping it, a wrong IP, or a network path problem (slow, ambiguous). The two errors implicate different layers; the words matter.

When should I use curl instead of a browser to test a site?

Whenever you need the raw truth: the exact status code, the redirect chain, the TLS handshake, response headers, or a scripted check. The browser hides almost all of it behind its chrome. For anything operational, curl is the honest witness the browser is not.

What is the single most useful ss flag?

ss -tulpn — listening TCP/UDP sockets with their processes, one command, the answer to 'what is on which port and who owns it'. It is the first command in any 'cannot connect' investigation and the last word on 'is it really listening'.

How do I know if DNS caching is the problem?

Query the authoritative answer directly (dig @8.8.8.8 or @your-authoritative) and compare with the local answer (dig example.com or resolvectl query). If the direct answer is correct and the local one is stale, the cache is the culprit — flush it (resolvectl flush-caches) and recheck.

What is the quickest sanity check for a whole stack?

The ordered chain from this article: dig +short, ping -c2, ss -tulpn | grep :port, curl -I. Run on a known-good service first to learn its shape; then any deviation stands out. The chain is ten seconds per host and answers nine out of ten outage reports.

What is the best first automation to build?

A backup of something you would hate to lose — a database dump or a working directory, scheduled nightly, logged, and tested by an occasional restore. It is the automation whose value is unconditional, and it exercises every pattern in this category: script, schedule, log, and verify.

How do I know when automation has gone too far?

When the automations start surprising you: firing at unexpected times, doing unexpected things, or requiring more maintenance than the ritual they replaced. The quarterly review — prune what stopped paying rent, keep what survived — is the same filter this portfolio applies to its own tooling.

Conclusion

The network toolkit is the difference between guessing and diagnosing: dig for names, ping and mtr for reach, ss for sockets, curl for responses — each one a boring, built-in command that answers exactly one question. The methodology ties them into a routine that bounds any investigation.

Run the four-step chain once today on a service you know well, and practice reading each output as a sentence. The next time something is 'down', the question will no longer be 'what do I click' — it will be 'which layer do I answer next'.