Port & Service-Level Checks: telnet, curl & netcat

Network Troubleshooting

Chapter 6 · Port & Service-Level Checks: telnet, curl & netcat

Chapter 5 closed out with the network path confirmed clean — a healthy ping, a traceroute that reaches the destination. That confirms packets can get to the right machine. It says nothing about whether anything on that machine is actually listening on the specific port the application needs. This chapter is entirely about that one narrow question, and about reading the difference between an active "no" and total silence — a distinction that's come up in passing since Chapter 2, and finally gets its full treatment here.

Why the Network Layer Passing Isn't the Whole Answer

A server can respond to ping perfectly while the specific service you care about — a web server on port 443, a database on port 3306 — has crashed, was never started, or is deliberately firewalled off from where you're testing. Confirming the network path is healthy narrows the search meaningfully, but the only way to confirm the actual port is to try connecting to it directly, which is what all three tools in this chapter do, in slightly different ways.

Three Tools for One Job

Tool	What it's good for	Worth knowing
`telnet host port`	The classic, simplest way to attempt a raw TCP connection to one port	No longer installed by default on Windows or many minimal Linux distributions — often needs enabling or installing first
`nc` (netcat)	The same job as telnet, plus fast scriptable checks across many ports with `-z` (zero-I/O, no data sent)	Usually available by default on Linux/macOS; a genuinely flexible, scriptable alternative
`curl -v`	Shows the same TCP connect step explicitly, as the first phase of an HTTP request, before anything HTTP-specific happens	Useful when the target is a web service specifically — Chapter 9 goes much further into reading the rest of curl's output

telnet's client is often missing entirely today

Modern Windows ships the telnet client as an optional feature, disabled by default, and a number of minimal Linux distributions leave it out entirely to reduce their attack surface. Don't assume it's there — nc or curl are, in practice, more reliably available on a random machine today.

Reading the Three Outcomes

$ nc -zv app.example.com 443
Connection to app.example.com 443 port [tcp/https] succeeded!

$ nc -zv app.example.com 8080
nc: connect to app.example.com port 8080 (tcp) failed: Connection refused

$ nc -zv app.example.com 22
(hangs with no response — Ctrl+C to cancel)

Outcome	What it means
Connects immediately	Something is actively listening and accepting connections on that port — the port/service rung is confirmed
"Connection refused"	An active reply came back saying no — either nothing is listening on that port, or something explicitly rejected the connection
Hangs / times out	No response of any kind — consistent with a firewall silently dropping the connection attempt, or the packet never arriving at all

"Refused" narrows it to two candidates, not one

A refused connection is a genuinely useful, active signal — but on its own it doesn't fully distinguish between "nothing is listening on this port" (the operating system itself replies, since no process owns that port) and "a firewall is explicitly configured to reject rather than silently drop this traffic" (which can produce the exact same client-side message). Both are more informative than a silent timeout, but telling them apart usually needs a second data point — often access to the machine itself, or the firewall's own logs, which Chapter 7 covers.

curl's Connection Phase

For a web service specifically, curl -v shows the raw TCP connect step explicitly, before anything HTTP-related begins:

$ curl -v https://app.example.com
*   Trying 203.0.113.42:443...
* Connected to app.example.com (203.0.113.42) port 443
* ALPN: offers h2,http/1.1
...

Even without reading any further, the "Trying..." and "Connected to..." lines alone confirm the exact same thing nc -zv would — this chapter's own narrow question. Everything curl prints after that point — the TLS handshake, the request headers, the response status code — belongs to Chapter 9, once the port itself is confirmed open.

Check several common ports at once with a loop

nc -z's speed makes it easy to script a quick sweep instead of testing one port at a time by hand:

$ for port in 22 80 443 3306; do
    nc -zv -w 2 app.example.com $port
done

Working Example: Closing Out the Ticket

Back to the ticket that's run since Chapter 1. With DNS corrected (Chapter 4) and the network path confirmed clean (Chapter 5), a final check confirms port 443 as well:

$ nc -zv 203.0.113.42 443
Connection to 203.0.113.42 443 port [tcp/https] succeeded!

Every rung of the ladder — local connectivity, DNS, network reachability, and now port reachability — checks out clean. Which is, in its own way, the actual finding: this ticket's real root cause was the stale DNS answer identified back in Chapter 4. Once that single rung was corrected, everything above it was already fine, and there was never a firewall or application-layer problem to chase at all. That's exactly the payoff the ladder is built for — it would have been easy to spend far longer investigating firewalls or application logs for a problem that was actually settled two chapters ago.

Hands-On Exercises

Exercise 1

Explain why confirming a clean ping and a complete traceroute (Chapter 5) doesn't yet confirm that a specific application on that server is working, and what this chapter's checks add on top of that.

📄 View solution

Exercise 2

A port check comes back "connection refused." Explain why this chapter says that doesn't fully pinpoint the cause on its own, and name the two candidate explanations it gives.

📄 View solution

Exercise 3

Explain what this chapter identifies as the real root cause of the running ticket from Chapters 1 through 6, and why confirming every later rung of the ladder was still worth doing even after that root cause was already found in Chapter 4.

📄 View solution

Chapter 6 Quick Reference

A healthy network path (Chapter 5) doesn't confirm the specific port is open — that needs a direct connection attempt
telnet, nc, and curl -v all attempt the same raw TCP connection; telnet is increasingly not installed by default
Connects immediately = something is listening and accepting; refused = an active "no"; hangs/times out = no response at all
A refused connection narrows the cause to two candidates — nothing listening, or an explicit firewall rejection — not one; telling them apart usually needs Chapter 7
nc -z scripts easily into a quick sweep across several ports at once
Next chapter: Firewalls & Blocked Traffic: Diagnosing a Block You Can't See the Rules For