You stood up a service, opened a firewall rule, or wired up a reverse proxy. Now you want to know if a specific port is actually reachable from where you are. The instinct is to type telnet host 443 and read the response, but telnet is not on most modern Linux servers anymore, and installing it just to ask one TCP question feels like a lot. The fix is to use what is already on the box. Six tools cover almost every connectivity check you would ever do with telnet, and several of them give you better information than telnet ever did.
This is the practical guide I wish someone had handed me the first time I tried to debug a stuck Caddy (an open source web server) install. The recipes assume a Debian or RHEL-family Linux box with a normal user account, and they were tested on Ubuntu 24.04 and Fedora 41. The order is from quickest to most diagnostic.
A quick map of the six tools and when they win:
/dev/tcpfor the fastest yes/no on a single TCP port, with zero install costncfor raw TCP probing and manual HTTP requests when you need to see the bytescurlfor verifying a service is actually serving traffic, not just listeningssfor checking what is bound to a port on the local machinenmapfor the “I have tried everything else” filtered-port diagnosticpython3 -cfor the stripped-down container fallback when nothing else is installed
/dev/tcp: the bash built-in nobody remembers
Most admins know that bash has a /dev/tcp pseudo-filesystem that lets you open raw TCP connections from inside a shell script. It is one of the most usable port-testing tools on Linux because it ships with the shell itself. There is nothing to install, no need to be root, and it tells you whether the connection succeeded or failed in clear text.
The simplest recipe is a one-liner that returns 0 on a successful connection and non-zero on a failure:
if timeout 3 bash -c "</dev/tcp/example.com/443" 2>/dev/null; then
echo "port 443 is open"
else
echo "port 443 is closed or filtered"
fi
The timeout wrapper is important. Without it, a filtered or hung port will leave your shell session hanging until the kernel TCP timeout kicks in, which can be 75 seconds or more. The `