Ping a Specific Port: You Cannot, and Here Is What to Use

Ping uses ICMP, a protocol with no concept of ports. To test a port you need a tool that opens a TCP connection — nc, nmap, curl, or bash itself.

This question comes up whenever a service is unreachable and ping says the host is fine. That result is genuine and almost useless: it tells you the machine is powered on and routable, not that anything is listening on port 5432.

The distinction is worth internalising, because “ping works but the app cannot connect” is one of the most common shapes of infrastructure problem.

Table of contents

• Why ping cannot do it
• netcat, the quickest answer
• Bash with no tools installed at all
• nmap when you need detail
• When the port is open but the app still fails
• Reading the result correctly
• How this fits the rest of the stack
• FAQ

Why ping cannot do it

Ping sends ICMP Echo Request packets. ICMP sits alongside TCP and UDP at the same layer and has no port field, because it was never intended to address applications — it addresses hosts.

So a successful ping tells you three things: the host is up, routing works in both directions, and no firewall is dropping ICMP. It tells you nothing about whether a service is running, listening, or accepting connections.

The reverse is also true and trips people the other way: many hosts and cloud networks drop ICMP by default while happily serving traffic. A failed ping is not evidence that a host is down. Testing the actual port is the only test that answers the question you have.

netcat, the quickest answer

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

nc -zv -w 3 db.internal 5432   # 3 second timeout
nc -zv example.com 20-25       # scan a range

-z means scan only — connect and close without sending data. -v prints the result. -w sets a timeout, and it is worth always including: without it a filtered port hangs until the kernel gives up, which can be a couple of minutes.

nc exits 0 on success, so it scripts cleanly:

if nc -z -w 3 db.internal 5432; then
  echo "database reachable"
else
  echo "cannot reach database" >&2
  exit 1
fi

One caveat: there are several netcat implementations and their flags differ. The OpenBSD version is the common default on Linux and macOS; some minimal images ship a busybox variant with fewer options. If -z is unrecognised, you have a different nc.

Bash with no tools installed at all

Minimal containers often have neither nc nor nmap nor telnet. Bash can open a TCP connection on its own:

if timeout 3 bash -c '</dev/tcp/db.internal/5432'; then
  echo "port open"
else
  echo "port closed or filtered"
fi

/dev/tcp/host/port is a Bash feature, not a real device file — the shell intercepts the redirect and opens a socket. It works in any Bash with network redirection compiled in, which is nearly all of them.

Two things to note. It is Bash-specific: sh, dash and ash do not have it, so the bash -c wrapper matters in a container whose /bin/sh is not Bash. And timeout is essential, because the redirect will otherwise hang on a filtered port.

This is the trick worth memorising. It has rescued more debugging sessions in stripped-down containers than any other line in this post.

nmap when you need detail

nmap -p 443 example.com
nmap -p 80,443,5432 example.com
nmap -p- example.com            # all 65535 ports, slow
nmap -sV -p 5432 db.internal    # identify the service and version

nmap’s advantage is that it distinguishes three states that the simpler tools conflate:

• open — something accepted the connection.
• closed — the host actively refused (RST). Reachable, nothing listening.
• filtered — no response at all. A firewall is dropping packets silently.

That distinction is the actual diagnostic. closed means the service is not running; filtered means a firewall or security group is in the way. Those have completely different fixes, and no other tool tells them apart as clearly.

Two cautions. nmap is not installed by default on most systems, and scanning hosts you do not own or have permission to test is at best rude and in many jurisdictions illegal. Scan your own infrastructure.

When the port is open but the app still fails

An open port means something completed a TCP handshake. It does not mean your application is healthy. For HTTP services, test at the application layer:

curl -sS -o /dev/null -w "%{http_code} in %{time_total}s\n" https://api.example.com/health

# Follow the whole timing breakdown
curl -sS -o /dev/null -w \
  "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}\n" \
  https://api.example.com/

That timing breakdown localises the problem quickly: slow time_namelookup is DNS, slow time_connect is the network or a saturated listen backlog, slow time_appconnect is TLS, and slow time_starttransfer is your application.

For TLS specifically, openssl s_client -connect host:443 -servername host shows the certificate chain and negotiated protocol, which is where expired-certificate and SNI problems become obvious.

Reading the result correctly

A short diagnostic order that resolves most cases:

1. Does the name resolve? dig +short host. If not, it is DNS and nothing else matters.
2. Is the port open from here? nc -zv host port, or the bash redirect.
3. If closed: check the service is running and listening on the right interface — ss -tlnp | grep :5432. A process bound to 127.0.0.1 is invisible from anywhere else, which is a very common cause.
4. If filtered: it is a firewall, security group or network policy between you and the host.
5. If open but the app fails: it is authentication, TLS, or the application itself. curl with the timing breakdown.

Step 3 deserves emphasis. A database listening on localhost rather than 0.0.0.0 is reachable from the machine and from nowhere else, and it produces exactly the symptom that sends people to a port-testing article in the first place.

Managed databases on RunxBuild use private networking with connection limits, so services in the same project reach the database over the internal network without exposing a public port at all — which removes most of this diagnostic path rather than making it easier.

How this fits the rest of the stack

Ping answers a question about hosts; ports need a TCP connection. nc -zv -w 3 host port is the everyday tool, bash -c '</dev/tcp/host/port' is the one that works in a bare container, and nmap is the one that distinguishes closed from filtered — which is the distinction that tells you whether to restart a service or fix a firewall rule. When a service reaches its database over private networking, that whole path shortens; the RunxBuild hosting calculator shows the service and managed database together.

Useful related references:

• SSH Specify Key: IdentityFile, -i, and the Right Defaults
• nslookup: How to Specify a DNS Server (and Why the Answer Keeps Changing)
• What Port is SSH: 22 (Default), How to Change, and Why
• Services on RunxBuild

FAQ

Can you ping a specific port?

No. Ping uses ICMP, which has no port field because it addresses hosts rather than applications. Use nc -zv host port, nmap -p port host, or a bash TCP redirect to test whether a specific port accepts connections.

How do I check if a port is open in Linux?

nc -zv -w 3 host port is the quickest. With no tools installed, timeout 3 bash -c '</dev/tcp/host/port' works in any Bash. nmap -p port host adds the ability to distinguish a closed port from a filtered one.

What is the difference between a closed and a filtered port?

Closed means the host actively refused the connection with an RST — it is reachable but nothing is listening. Filtered means no response at all, which indicates a firewall silently dropping packets. The first is a service problem, the second a network one.

Why does ping work but my application cannot connect?

Ping only proves the host is reachable. The service may not be running, may be bound to 127.0.0.1 rather than a reachable interface, or a firewall may be blocking that port. Check ss -tlnp on the host to see what is actually listening and where.

How do I test a port without netcat installed?

Use Bash’s network redirection: timeout 3 bash -c '</dev/tcp/host/port'. The shell opens a real socket for that path. It requires Bash specifically — sh and dash do not support it — and timeout is needed or a filtered port will hang.