You SSH into a fresh server, type telnet 443 out of habit, and the shell tells you the command doesn’t exist.
Now you’re about to install a client for a decades-old protocol just to check whether a port is reachable.
But modern Linux systems already have several faster ways to do the same thing, and some of them give you much more information than Telnet ever did.
Tested on Ubuntu 26.04 and RHEL 10, but these commands work on any modern Linux distribution.
Anything inside angle brackets, such as or , is a placeholder.
Replace it with your own value and remove the angle brackets when you run the command.
Telnet sends everything in plaintext, including usernames and passwords, which makes it fundamentally unsuitable for secure remote administration.
That’s why modern Linux distributions generally don’t install Telnet by default, especially on minimal server installations.
The habit stuck around because Telnet was also a convenient way to open a raw TCP connection and check whether a service was listening on a particular port.
That’s the part you actually want, and you don’t need Telnet for it.
Modern Linux systems provide better tools such as nc (Netcat), nmap, curl, and Bash’s built-in TCP support.
These can test connectivity without installing an obsolete remote-login protocol, and several of them provide considerably more useful information than Telnet ever did.
Netcat (nc) is the closest replacement for the old Telnet trick.
It can open a TCP connection, check whether a port is accepting connections, and report the result without requiring an interactive session.
The package name differs between Debian-based and RHEL-based distributions, which can trip you up.
On Ubuntu/Debian:
On RHEL/Rocky Linux:
sudo runs the command with root privileges, which the package manager needs to install software into system directories.
Without it, you’ll typically get a permissions error.
Now point nc at a host and port:
You should see something similar to:
Here’s what each part of the command does:
If you see succeeded, the TCP connection was established successfully.
That means the host accepted the connection on port 22, which normally indicates that a service is listening there.
A closed port looks different:
Connection refused means the target was reachable and responded to the connection attempt, but nothing accepted the connection on that port or a firewall/device actively rejected it.
A timeout is different:
A timeout means no response was received within the connection timeout period.
A firewall silently dropping packets is one common cause, but routing problems, network ACLs, security groups, or an unreachable host can produce the same symptom.
That distinction is important when troubleshooting:
A filtered port may leave nc waiting until the connection attempt eventually times out.
Depending on the network and system configuration, that can take quite a while.
Use -w to set your own timeout:
Here, -w 3 tells nc to wait up to 3 seconds for the connection attempt before giving up.
This is particularly useful when you’re testing multiple hosts or ports.
Instead of waiting for the operating system’s default timeout, you get a predictable response time.
Netcat implementations aren’t completely identical.
If the command behaves differently or an option isn’t recognized, run nc -h and check which options your installed version supports.
In particular, older netcat-traditional versions can handle some options differently from the OpenBSD version commonly installed today.
Bash has a built-in TCP client mechanism called /dev/tcp, so there’s nothing to install.
This makes it especially useful on locked-down servers where you don’t have package-manager access or permission to install additional tools.
Try:
If the connection succeeds:
Here’s what each part does:
The trick is that Bash recognizes /dev/tcp// as a special redirection target.
When you redirect output to it, Bash attempts to establish a TCP connection rather than writing to an actual file.
If the TCP connection succeeds, Bash returns a successful exit status, and you get:
First, this is Bash-specific; it won’t work under plain sh or dash.
On Debian and Ubuntu, /bin/sh typically points to dash, not Bash.
Second, /dev/tcp isn’t guaranteed to be available in every Bash build.
Some hardened or specially compiled environments may disable network redirections.
So this is an excellent zero-install TCP connectivity check, but nc is generally the better choice when you need more control, diagnostics, or UDP testing.
nc is great when you want to check one port at a time.
When you’re troubleshooting a service that uses several ports or you want more information about why a port isn’t responding, nmap is the better tool.
Install it with your distribution’s package manager:
On Ubuntu/Debian:
On RHEL/Rocky Linux:
You can give nmap a comma-separated list of ports with -p:
A typical result looks like this:
The STATE column is the important part.
Unlike a simple Telnet connection test, nmap distinguishes between several useful states:
That last state is especially useful when troubleshooting.
If you see:
Don’t immediately restart MySQL.
The database might be running perfectly well; a firewall, security group, or network ACL could be blocking traffic before it reaches the server.
To scan a larger range, specify the starting and ending ports:
This checks ports 1 through 1000 in a single scan, giving you a much broader picture of what the host is exposing.
Everything so far has tested a port from another machine.
When you’re already logged into the server, ss command gives you a direct view of the sockets currently listening on that machine.
The older netstat utility has largely been replaced by ss on modern Linux distributions, so there’s usually no reason to install net-tools just to run netstat.
Run:
You might see:
The options work together:
Pay close attention to the Local Address:Port column.
It often explains the classic “the service is running, but I can’t connect to it” problem.
For example:
Means MariaDB is listening only on the loopback interface.
Connections from the same machine can reach it, but remote clients cannot connect directly.
By contrast:
Means sshd is listening on all IPv4 interfaces, so the service can accept connections arriving through any of them, subject to firewall and other network controls.
You don’t have to read through the entire output when you’re troubleshooting a specific service.
Pipe the result through grep command:
Here’s what the pipeline does:
This makes ss particularly useful for answering a question that nc or nmap cannot answer by themselves: “Is the service actually listening on this machine, and which process owns the port?”.
curl is already installed on many Linux systems, including some minimal environments and container images where nc isn’t available.
While curl is primarily an application-protocol client, it can also use its Telnet protocol handler to establish a raw TCP connection.
Try:
A successful connection might look like:
The important line is:
That confirms the TCP connection was established.
In this example, the SSH banner immediately following it also tells you what service answered.
That’s useful when troubleshooting because you’re not just learning that the port is reachable, you can sometimes see exactly which service is responding.
If the banner identifies an unexpected service, you may have discovered that you’re connecting to the wrong host or port.
Not every curl build includes the Telnet protocol handler.
Check the supported protocols with:
Look at the Protocols line.
If telnet isn’t listed, you can’t use the telnet:// form with that particular build.
For HTTP or HTTPS services, you can test the application directly instead:
This has an important advantage over a generic TCP test: curl can tell you whether the HTTP service itself responds, rather than merely confirming that something accepted the TCP connection.
UDP works differently from TCP because there is no three-way handshake.
Nothing has to establish a connection before data can be sent, so simply getting no response doesn’t tell you whether the port is open.
Both nc and nmap can test UDP, but you need to interpret the results differently from TCP.
With nmap, use -sU for a UDP scan:
You might see:
The open|filtered result is nmap being honest about what it can determine from the outside.
The target didn’t send back a response that lets nmap distinguish between these two possibilities:
With TCP, the handshake gives you much clearer signals.
With UDP, silence can mean several different things.
If you have access to the target machine, check its sockets directly:
Look for the UDP port in the output.
For example:
That tells you a process is actually bound to UDP port 53 on the server.
So when troubleshooting UDP, remember:
That distinction can save you from chasing a firewall problem when the service isn’t even listening; or blaming the service when the firewall is the real issue.
Here’s a common troubleshooting situation:
ss shows that a service is listening, but a remote nc connection still times out.
If the service is bound to 0.0.0.0 or the appropriate network interface, the firewall is one of the next things to check.
Don’t guess; look at the active rules.
On Ubuntu/Debian:
On RHEL/Rocky Linux:
Look at the ports, services, and other relevant rules in the output, if the port you’re testing isn’t allowed by the firewall, the firewall may be dropping the incoming connection before it reaches the application.
From a remote machine, that often appears as a timeout or an nmap result such as filtered.
For example, the troubleshooting chain might look like this:
That’s a much better diagnosis than repeatedly restarting the service.
You now have five practical ways to test ports without Telnet, and each tool answers a slightly different question.
nc and Bash /dev/tcp give you a quick TCP connectivity check.
nmap goes further by distinguishing between open, closed, and filtered ports.
ss shows what’s actually listening on the local machine and which interface it’s bound to, while curl lets you test application-level services such as HTTP and inspect responses or service banners when available.
The most useful part is knowing which tool to reach for when troubleshooting:
Try these commands on a server you already manage.
Start with sudo ss -tulnp then look closely at the Local Address column.
If a service you expected to be reachable remotely is bound to 127.0.0.1, you’ve probably found the problem: the service is running, but it’s listening only for local connections.
That’s one of those small Linux details that can save you a lot of unnecessary troubleshooting.
Which tool do you reach for first when a port isn’t responding? And has ss ever revealed a service listening on loopback when you expected it to be public? Let us know in the comments.
9 Deprecated Linux Networking Commands and Alternative Tools You Should Use
Top 25 Network Ports You Must Know for Interviews
How to Increase Network TCP/IP Connections in Linux
How to Bridge Two Network Interfaces in Linux Using Netplan
networkctl – Query the Status of Network Links in Linux
12 Tcpdump Commands – A Network Sniffer Tool
Psensor – Monitor Linux Hardware Temperature [Motherboard and CPU]
SARG – Squid Analysis Report Generator and Internet Bandwidth Monitoring Tool
Configure Collectd as a Central Monitoring Server for Clients
How to Monitor Nginx Performance Using Netdata on CentOS 7
How to Add Hosts in OpenNMS Monitoring Server
screenFetch – An Ultimate System Information Generator for Linux
How to Avoid Retyping Long Commands in Linux
How to Undo or Redo a Yum Install on CentOS and RHEL
How to Find Out Who is Using a File in Linux
Most Commonly Used Linux Commands You Should Know
8 Useful Commands to Monitor Swap Space Usage in Linux
12 Tcpdump Commands – A Network Sniffer Tool
10 Best Linux File and Disk Encryption Tools (2024)
13 Free and Open-Source Video Editing Software for Linux in 2024
12 Open-Source WYSIWYG Editors Worth Using in 2026
20 Useful Security Features and Tools for Linux Admins
10 Top Open Source Reverse Proxy Servers for Linux
10 Best PDF Document Viewers for Linux Systems
—
**📚 Original Source:**
[5 Ways to Test TCP and UDP Ports in Linux Using nc, nmap, ss, and Bash](https://www.tecmint.com/test-open-ports-linux-without-telnet/)
About The Author
