How to check if a port is open

The quick way: test from outside your network

Enter the hostname or IP address and the port number into a port check tool and let it open a connection from a machine somewhere else on the internet. Whether the service is running is a different question. What you need to know is whether anyone out there can reach it, and testing from the same server, or from the same office network, skips exactly the layers that usually cause the problem.

The manual way: nc, nmap and telnet

From any other machine on a different network, three tools do the job:

nc -zv example.com 443            # single port, zero-I/O scan, verbose
nmap -Pn -p 22,80,443 example.com # several ports, reports open/closed/filtered
telnet example.com 25             # old but universal; Ctrl+] then "quit" to exit

nc (netcat) is the simplest: -z means connect and immediately disconnect without sending data, -v prints the result. It answers "succeeded" or "refused / timed out" and nothing more. Reach for nmap when the distinction matters, because it is the only one of the three that reliably separates a refused connection from a dropped one, and -Pn tells it to skip its ping probe and test the port even when the host does not answer pings. telnet is installed almost everywhere, and for text protocols such as SMTP or HTTP it also shows you the greeting banner the service sends.

To see what is listening on the machine itself, which is a different question, use ss -tulpn on Linux or netstat -ano on Windows. If a port is listening there but closed from outside, the block is in between: a host firewall, a cloud security group, or the provider.

Open, closed and filtered are three different answers

• Open. Something completed the TCP handshake. A service is listening and accepted the connection.
• Closed. The host answered, but with a refusal (a TCP reset). The machine is reachable and nothing is listening on that port. This is a fast, definite answer.
• Filtered. Nothing came back at all. A firewall dropped the packet without replying, so the probe times out. This is the slow answer, and it means a firewall is in the way rather than that the service is down.

Closed points you at the service configuration. Filtered points you at a firewall rule, a security group, or an ISP blocking the port. Many providers block port 25 outbound by default, and a few block 445 and other commonly abused ports, which produces a filtered result no amount of server-side configuration will change.

UDP is a special case. UDP has no handshake, so a scanner often cannot tell an open port from a filtered one, and silence is a valid response from a healthy UDP service. Treat UDP results as much weaker evidence than TCP results.

Why an open port is not a working service

An open port proves that a TCP connection can be established. It says nothing about what happens next. All of these are open ports with broken services:

• A web server accepting connections on 443 while serving 502 because the application behind it has crashed.
• A database listening on its port but refusing every login.
• A mail server that completes the handshake and then drops the session before accepting a message.
• A service whose TLS certificate expired last night. The port opens, and every client rejects the connection.
• A port forwarded to the wrong internal machine, which accepts connections and answers nothing useful.

So a port check is the first step of a diagnosis, not the whole of it. Once the port answers, check the protocol: request a page and read the status code, run a real login, or send a test message. The order matters, because a port check rules out the entire network layer quickly and lets you stop looking there.

A short checklist when a port will not open

1. Confirm the service is listening on the machine, and on the right interface. A service bound to 127.0.0.1 is unreachable from anywhere else, and that is a very common cause.
2. Check the host firewall (ufw, firewalld, or the Windows firewall).
3. Check the cloud security group or network ACL, which is a separate layer from the host firewall and frequently forgotten.
4. Check any router or NAT port forwarding if the machine is not directly on a public address.
5. Confirm the provider does not block that port, especially for mail ports.
6. Re-test from a third network to rule out your own outbound filtering.

Rechecking on a schedule

A port check tells you the state right now, from wherever the probe ran. Ports do not usually close on their own. Firewall rules get edited, security groups get tightened, certificates expire and services stop restarting after a reboot, and none of that announces itself. Scheduled port monitoring reconnects on an interval from multiple locations and alerts when the connection stops succeeding, which also catches the case where the port is reachable from one region and filtered from another. Test a port now with the port check tool. When the port opens but TLS fails, the next thing to read is how to check certificate expiry.