`nc -vz` Is the Fast Port Check You Should Run Before You Claim a Service Is Down When the Real Question Is Whether the Port Is Even Open

Why this command matters: a lot of service debugging starts several layers too high. Before you debate API behavior, confirm the target port is reachable.

When an app cannot connect to Redis, Postgres, an HTTPS endpoint, or an internal API, the most useful first question is often brutally simple: can this host reach that TCP port at all? nc -vz is one of the fastest ways to answer that from the terminal.

The command

nc -vz example.com 443

Or for an internal service:

nc -vz db.internal 5432
nc -vz redis.internal 6379

The flags matter:

1. -v makes the output more explicit
2. -z tells netcat to scan for listening daemons without sending normal data

That makes it ideal for a quick reachability check instead of a full interactive session.

What it tells you

If the port is reachable, you usually get a successful connection message. If not, you may see timeout or refusal behavior.

That helps distinguish between:

1. host reachable but service not listening
2. network path blocked
3. firewall or security group issue
4. wrong port entirely

Those are very different problems, and nc -vz helps separate them early.

Why this is better than skipping straight to app blame

Developers often jump to:

1. “the client library is broken”
2. “the cert chain is wrong”
3. “the app must be hanging”

Sometimes those are real. But if the target port is not reachable in the first place, those theories are premature.

A good quick sequence is:

dig +short api.example.com
ping -c 4 api.example.com
nc -vz api.example.com 443

Now you have DNS, basic host reachability, and actual port-level visibility.

Final recommendation

If a service connection is failing and you are not yet sure the port is open, run nc -vz before constructing smarter explanations. Port reachability is one of the cheapest facts you can verify, and it cuts away a lot of fake debugging fast.

Sources

• OpenBSD nc manual