Testing Ports with Telnet

Telnet is a fossil. Created in 1969 for remote terminal access, it transmits everything—including passwords—in cleartext. SSH replaced it decades ago for actual remote login.

But telnet refuses to die. Why? Because its simplicity makes it the perfect diagnostic tool. It does one thing: attempts to establish a TCP connection to a specific port. No encryption, no authentication, no protocol negotiation. Just a knock on the door.

The Question Telnet Answers

Ping asks: "Does this host exist on the network?"

Telnet asks: "Is anyone answering the door at this specific port?"

That's a fundamentally different question. A web server might respond to ping all day while its HTTP service is crashed. A database server might be reachable but the database daemon isn't running. Telnet tests what you actually care about: is the service listening?

Basic Syntax

telnet hostname port

Examples:

telnet example.com 80     # Web server
telnet example.com 443    # HTTPS
telnet example.com 22     # SSH
telnet mail.example.com 25  # SMTP

Reading the Response

Telnet's responses tell you exactly what's happening:

"Connected" — Someone answered. The port is open, a service is listening, and you've established a TCP connection.

Trying 93.184.216.34...
Connected to example.com.
Escape character is '^]'.

"Connection refused" — The door exists but nobody's home. The host is reachable, but nothing is listening on that port. This usually means the service isn't running.

Trying 93.184.216.34...
telnet: connect to address 93.184.216.34: Connection refused

"Connection timed out" — No response at all. Either a firewall is silently dropping packets, the host is down, or there's a routing problem.

Trying 93.184.216.34...
telnet: connect to address 93.184.216.34: Connection timed out

"No route to host" — Your system can't find a path to that address. This is a routing problem, not a port problem.

Beyond Connection Testing

Once connected, you can actually talk to the service. This reveals whether it's functioning, not just listening.

Testing a web server:

telnet example.com 80

After connecting, type:

GET / HTTP/1.1
Host: example.com

(Press Enter twice after the Host line)

You'll see HTTP response headers and content. The web server isn't just listening—it's serving pages.

Testing an SMTP server:

telnet mail.example.com 25

After connecting:

EHLO test.com
QUIT

You'll see the server's SMTP banner and capabilities. This tests the actual mail service, not just the port.

What Telnet Can't Do

Test encrypted services. Telnet doesn't speak TLS. It can tell you port 443 is open, but it can't complete an HTTPS handshake. Use openssl s_client instead:

openssl s_client -connect example.com:443

Test UDP. Telnet only speaks TCP. For DNS (port 53) or NTP (port 123), you need different tools.

Distinguish filtered from unreachable. A timeout could mean a firewall is blocking the port, the host is down, or there's a routing issue. Telnet can't tell you which.

Installing Telnet

Modern systems often omit telnet:

# Debian/Ubuntu
sudo apt install telnet

# Red Hat/CentOS
sudo yum install telnet

# macOS (removed in High Sierra)
brew install telnet

On Windows, enable it through "Turn Windows features on or off" → "Telnet Client."

Better Alternatives

netcat — More versatile, often pre-installed:

nc -zv example.com 80

The -z flag scans without sending data. The -v flag shows results.

nmap — For scanning multiple ports:

nmap -p 80,443,22 example.com

curl — For HTTP/HTTPS specifically:

curl -v https://example.com

PowerShell (Windows):

Test-NetConnection example.com -Port 80

A Troubleshooting Workflow

1. Ping first — Confirm the host exists
2. Telnet the port — Check if the service is listening
3. Try alternate ports — Many services use multiple ports (80/443/8080 for web)
4. Test from elsewhere — If it fails, try from another network to isolate the problem
5. Interact with the service — If connected, send a request to verify functionality

Common Patterns

Connection refused on port 80 — Web server isn't running. Check if Apache/Nginx is started.

Timeout on port 25 — Your ISP probably blocks outbound SMTP to prevent spam. Use port 587 instead.

Works locally, fails remotely — Firewall allows localhost but blocks external connections.

Telnet connects, application fails — Network is fine. The problem is authentication, protocol version, or application configuration.

Security Note

Don't transmit anything sensitive over telnet. Ever. It's unencrypted. Use it for diagnostics only—to test if a port is open, to verify a service responds. For actual work, use the proper encrypted protocol.

Telnet's insecurity is precisely why it's useful as a diagnostic tool. It doesn't try to be clever. It just knocks on the door and tells you if anyone answers.