How to Check Whether a Port Is Open, and What the Result Means
Open, closed, and filtered are three different answers, and telling them apart is the whole skill. Here is what the TCP handshake reveals and why a firewall makes a port look filtered rather than closed.
Step-by-step
- 1
Enter a host and a port
Open the Port Checker, type the hostname or IP, and give it a port number. If you just stood up a web server, test 80 and 443; a database would be 3306 for MySQL or 5432 for Postgres; SSH is 22. The check runs from a server on the public internet, so it tells you what the outside world sees, which is exactly the perspective that matters when a remote user says they cannot connect but the service is up locally.
- 2
Understand the TCP handshake behind the test
A TCP port check is really a partial handshake. Your side sends a SYN packet. If something is listening, it replies with SYN-ACK and the port is open; the checker then sends a reset to tear the half-open connection down cleanly. That single exchange is all it takes to prove a service accepted the connection. Nothing about the application is tested, only whether the transport layer would let a conversation start. That distinction matters later when an open port still does not behave.
- 3
Read open, closed, and filtered apart
Open means you got a SYN-ACK: a service is listening and reachable. Closed means the host answered, but with a TCP RST, so the machine is up and reachable yet nothing is bound to that port. Filtered means you got nothing at all, no SYN-ACK and no RST, just silence until timeout. That silence is the important case, because a live host that simply has no service will actively refuse with a reset, whereas a firewall dropping your packets produces no reply of any kind.
- 4
Read filtered as a firewall, not a dead host
This is where people jump to the wrong conclusion. A filtered result almost always means a firewall or security group is silently dropping the probe, not that the server is offline. Cloud providers default to this: an AWS security group or a UFW rule that does not allow the port will swallow packets with no response, exactly matching the filtered signature. So before you restart the whole box, check the firewall rule for that specific port. Nine times out of ten the service is running fine and the packet never reached it.
- 5
Test your own server after opening a port
The classic loop: you edit a firewall rule, reload it, and want to confirm the change actually took from outside. Checking from the same machine is useless because loopback bypasses the firewall entirely; localhost always looks open. Run the external check instead. Open the port in your security group, hit it from the tool, and you get a straight open or filtered answer that reflects the real path in. If it still reads filtered, the rule did not apply, the wrong port range is listed, or a second firewall upstream is also in the way.
- 6
Confirm the service, not just the socket
An open port proves the transport layer accepts connections; it does not prove the application answers correctly. A web server can accept on 443 while presenting an expired certificate, or a database can accept on 5432 while rejecting every login. Use the port check to settle the network question, then move up a layer to test the protocol itself. If port 443 is open but the site errors, the reachability is fine and the problem is TLS or the app, which narrows your search enormously.
The three answers side by side
- Open: SYN-ACK received. A service is listening and the path is clear.
- Closed: RST received. The host is up and reachable but nothing is bound to the port.
- Filtered: no reply until timeout. A firewall is dropping the probe; you learn nothing about the service behind it.
Ports worth knowing
You do not need to memorize the full IANA list, but a handful come up daily: 22 for SSH, 80 for HTTP, 443 for HTTPS, 25 and 587 for mail submission, 3306 for MySQL, 5432 for PostgreSQL, 6379 for Redis, and 27017 for MongoDB. Database ports are the ones you most want to see filtered from the public internet, because a Redis or Mongo instance open to the world with no auth is a well-worn way to get breached.
Checking a single port on your own server is routine diagnostics. Sweeping ports across machines you do not control is a different thing entirely and can violate acceptable-use policies or local law, even if you never connect to anything. Keep it to your own infrastructure or systems you have written permission to assess.