To check a port with telnet, run telnet host port — for example telnet example.com 443. A blank screen with a blinking cursor (or Connected to on Linux) means the TCP port is open and something is listening. An instant "Connection refused" means closed; a long hang ending in a timeout means a firewall drops the packets.
Telnet port check: the command
The telnet client takes a hostname or IP address and a port number. Always type the port: without it, telnet connects to port 23 — the port of the Telnet protocol itself — rather than the service you actually want to test.
telnet example.com 443
telnet 10.0.0.15 5432
telnet mail.example.com 25Under the hood, telnet opens a plain TCP connection. It sends a SYN and waits. If an application is listening on that port, the host answers with SYN-ACK, the three-way handshake completes, and telnet reports success. From that point, anything you type is written straight into the socket, which is why administrators have used telnet for decades as a universal probe for web servers, mail servers, databases and SSH daemons.
Two caveats up front. Telnet only tests TCP; it cannot tell you anything about UDP services such as DNS queries, NTP or WireGuard. And a successful connection only proves that something completed the handshake — possibly your application, possibly a load balancer, reverse proxy or DDoS-protection layer sitting in front of it.
How to enable the Telnet client on Windows 10 and 11
Windows ships the Telnet client but leaves it disabled. Without it, cmd replies with 'telnet' is not recognized as an internal or external command, operable program or batch file. Any of the following turns it on (administrator rights required):
- GUI: press
Win + R, runoptionalfeatures, tick Telnet Client and click OK. On Windows 11 the same dialog is reachable from Settings → System → Optional features → More Windows features. - DISM in an elevated command prompt:
dism /online /Enable-Feature /FeatureName:TelnetClient - PowerShell as administrator:
Enable-WindowsOptionalFeature -Online -FeatureName TelnetClient
No reboot is usually needed; just open a new console. To remove it later, run dism /online /Disable-Feature /FeatureName:TelnetClient. The client itself carries no risk — it only makes outbound connections. The security problem is a Telnet server accepting logins, which is covered below.
Test-NetConnection: the PowerShell alternative
On any modern Windows you may not need telnet at all. PowerShell's Test-NetConnection cmdlet performs the same TCP check and returns an unambiguous answer:
Test-NetConnection example.com -Port 443Look for TcpTestSucceeded : True. The output also shows which address the name resolved to (RemoteAddress) and which local interface was used — handy when a host has several IPs or you are on a VPN. The short alias is tnc, and -InformationLevel Quiet reduces the result to a bare True or False for scripts:
tnc 10.0.0.15 -Port 3389 -InformationLevel QuietWhen the port is closed, the cmdlet also tries a ping and prints a warning, which makes failures slower than successes. That is expected behaviour. Full parameter reference: Test-NetConnection on Microsoft Learn.
Checking ports on Linux and macOS
Linux
Minimal server images rarely include telnet. Install it with sudo apt install telnet (Debian/Ubuntu) or sudo dnf install telnet (RHEL, AlmaLinux, Rocky, Fedora). A successful check looks like this:
$ telnet server.example.com 443
Trying 203.0.113.10...
Connected to server.example.com.
Escape character is '^]'.macOS
Apple removed telnet in macOS High Sierra. You can reinstall it with Homebrew (brew install telnet), but the built-in netcat is the better tool for the job.
netcat (nc)
nc -zv example.com 443
nc -zv -w 3 10.0.0.15 5432-z tells nc to connect without sending data, -v prints the result and -w 3 sets a three-second timeout. On macOS a success reads Connection to example.com port 443 [tcp/https] succeeded!. Unlike telnet, nc exits by itself, and its exit code (0 for open) makes it easy to use in scripts and health checks.
No telnet, no nc
Bash can open TCP sockets on its own through the /dev/tcp pseudo-path:
timeout 3 bash -c '</dev/tcp/example.com/443' && echo open || echo closedcurl works too, because it understands the telnet scheme: curl -v telnet://example.com:443 prints Connected to when the port accepts connections. Press Ctrl + C to leave.
Reading the result
The useful part of a port check is not just open versus closed but how the connection failed. Each outcome points somewhere different.
| Output | Meaning | Next step |
|---|---|---|
Blank screen (Windows) or Connected to … | Port open, handshake completed | The network path is fine; if the service still misbehaves, look at the application |
Connection refused / "Could not open connection to the host, on port N: Connect failed", returned instantly | Host reachable, but nothing listens on the port — or a firewall rejects with a TCP reset | Check that the service is running and which address it binds to |
Stuck on Trying …, then Connection timed out | Packets silently dropped or host unreachable | Check the server firewall, cloud security groups, routing |
No route to host | No route to that network, or the host is down on the local segment | Verify the address, gateway and routes |
could not resolve …: Name or service not known | DNS lookup failed | Check the domain's DNS records or test by IP |
Connects, then Connection closed by foreign host | Port open, but the service dropped you — allow-lists, connection limits, fail2ban | Read the service log and access rules |
"Refused" versus "timed out" is the key distinction. A refusal arrives immediately, which proves the packet reached the host and it answered. A timeout means no answer at all, usually because a firewall — on the server, at the hosting provider or in a cloud security group — drops the traffic without replying. Also keep outbound filtering in mind: many residential and mobile ISPs block outgoing connections to port 25, so a timeout on port 25 from a home connection does not prove the mail server is down.
How to exit telnet
Once connected, telnet waits for input. Press Ctrl + ] to reach the telnet> prompt (Microsoft Telnet> on Windows), then type quit.
Open locally but not from outside
A classic trap: telnet localhost 8080 works on the server, but the same port times out from anywhere else. Most often the application listens only on the loopback address. Check what is listening and where:
# Linux
sudo ss -tlnp
# Windows
netstat -ano | findstr :8080
Get-NetTCPConnection -LocalPort 8080 -State Listen
# macOS
sudo lsof -iTCP -sTCP:LISTEN -n -P127.0.0.1:8080 means the service is reachable only from the machine itself; 0.0.0.0:8080 or [::]:8080 means all interfaces, and from there it is the firewall's call. Always repeat an inside check from the outside — from another network or an online checker — or you are testing a path your users never take.
Talking to HTTP and SMTP by hand
Because telnet passes your keystrokes straight to the socket, it doubles as a manual client for plain-text protocols.
HTTP on port 80
telnet example.com 80
GET / HTTP/1.1
Host: example.com
Finish with an empty line (press Enter twice) and the server replies with a status line such as HTTP/1.1 301 Moved Permanently plus headers. The Windows client does not echo what you type; enable it with Ctrl + ] and set localecho. This trick does not work on port 443, where a TLS handshake comes first — use openssl s_client -connect example.com:443 instead.
SMTP on port 25
A mail server greets you with a 220 banner and its hostname; send EHLO to list the extensions it supports. That confirms the MX host is alive. The full conversation, including STARTTLS and relay tests, is walked through in how to test an SMTP server.
UDP is a different story
telnet 8.8.8.8 53 only tests DNS over TCP, not the UDP port normal queries use. UDP has no handshake, so a silent service and a dropped packet look identical; nc -zu results are unreliable, and even sudo nmap -sU -p 53 host often reports "open|filtered". See TCP vs UDP for why.
The Telnet protocol and why SSH replaced it
Telnet is also a remote terminal protocol, defined in RFC 854. It runs over TCP port 23 and gives the client a shell on the remote machine; Unix servers, routers and switches were administered this way for years.
Its fatal flaw is that everything, including usernames and passwords, travels in clear text. Anyone able to capture traffic on the path — a shared Wi-Fi network, a compromised router, an ISP segment — can read the credentials. Port 23 exposed to the internet is also scanned constantly by bots trying default passwords on routers and IP cameras.
SSH on port 22 replaced it: the session is encrypted, the server's identity is verified and key-based login is supported. The practical rule:
- The telnet client as a port-testing tool is harmless and useful.
- A Telnet server reachable from the internet should be switched off — on Linux, remove the telnetd or telnet-server package.
- Telnet on network gear (switches, routers) should be limited to the management network or disabled wherever SSH is available.
To lock SSH down properly, follow the guide on SSH key authentication; for why every extra listening port matters, read open ports and server security.
Command cheat sheet
| Task | Windows | Linux | macOS |
|---|---|---|---|
| Test a TCP port | telnet host 443 | telnet host 443 | nc -zv host 443 |
| True/false result for scripts | tnc host -Port 443 -InformationLevel Quiet | nc -z -w 3 host 443; echo $? | nc -z -w 3 host 443; echo $? |
| No extra packages | Test-NetConnection host -Port 443 | bash -c '</dev/tcp/host/443' | nc -zv host 443 |
| Install telnet | dism /online /Enable-Feature /FeatureName:TelnetClient | sudo apt install telnet | brew install telnet |
| List listening ports | netstat -ano | sudo ss -tlnp | sudo lsof -iTCP -sTCP:LISTEN -n -P |
| Inspect HTTPS manually | openssl s_client -connect host:443 | openssl s_client -connect host:443 | openssl s_client -connect host:443 |
The Windows client's built-in commands (open, close, set, display) are documented in the Microsoft telnet reference.
How to check if a port is open online
Telnet on your own machine tests the port from where you sit — through your router, ISP and any corporate proxy. To see a server the way visitors on the internet see it, test from outside:
- Port scanner — checks which TCP ports of a host are reachable from the internet, nothing to install.
- Ping — confirms the host answers at all and shows latency; useful when telnet only times out.
- Traceroute — shows the hop where packets stop.
If a port answers locally but not in the online check, the filtering is somewhere on the path: the host firewall, the provider's network, a cloud security group or missing port forwarding. More techniques, from scanners to listing listening sockets, are collected in how to check open ports.
Frequently asked questions
Why do I just get a black screen after running telnet on Windows?
That is the success case: the connection is established and the client is waiting for input. The port is open. Press Ctrl + ] and type quit to leave.
Can telnet test a UDP port?
No, telnet only speaks TCP. For UDP use nmap -sU, keeping in mind that "open|filtered" is not a definitive answer.
What is the difference between ping and telnet?
Ping sends ICMP and tells you whether the host responds at all; it says nothing about ports. Telnet tests one specific TCP port. A host can ignore ping yet accept connections on 443, and vice versa.
What port does telnet use by default?
TCP port 23. Running telnet host without a port number connects there.
Is it safe to enable the Telnet client?
Yes. The client opens nothing on your computer; it only makes outgoing connections. The risk lies with Telnet servers that accept clear-text logins.
The port is open but the service still fails — why?
Telnet only confirms the TCP handshake. The application may return errors, require TLS, reject your IP, or the port may belong to a proxy rather than the service you expect. Check the service's own response next: HTTP status, banner, logs.
