A TCP port check answers a narrower, more specific question than “is the server up?” — it asks is this exact port, on this exact host, accepting connections right now? That distinction matters more than it sounds, because a server can be perfectly healthy while one specific port is closed, filtered, or blocked somewhere along the path.
How a port check actually works
Checking a port means attempting a full TCP connection — the standard three-way SYN, SYN-ACK, ACK handshake — against the host and port you specify, then watching what comes back. This is different from a raw, half-open “SYN scan” (the kind port-scanning tools like nmap can do), which never completes the handshake; a real connection attempt is slower per port but gives an unambiguous answer. There are three possible outcomes, and they mean very different things:
- Open — the handshake completes. Something is actively listening on that port and accepting connections.
- Closed — the host responds, but explicitly refuses the connection (a TCP RST). The host is reachable; nothing is listening on that port.
- Filtered / timed out — no response at all within the timeout window. This usually means a firewall is silently dropping the packets rather than actively refusing them — a deliberate, common security posture, not necessarily a problem.
Open vs. closed vs. filtered — why it matters
The difference changes what you should do next. A closed port tells you the host is definitely reachable and the network path works — the service on that port just isn't running, so the fix is almost always “start the service” or “check you have the right port number.” A filtered port tells you almost nothing about the service itself — it means a firewall, security group, or NAT rule is standing between you and the host, so the fix is almost always on the network/firewall side, not the application.
This is also why a port check from an external vantage point (like a server, rather than your own laptop) matters: a port can be wide open on your local network and still be completely unreachable from the outside world, because a router or cloud security group is blocking inbound traffic before it ever reaches the host.
Common ports worth knowing
- 22 — SSH, remote server administration.
- 25 — SMTP, mail transfer between servers (not the port your email client uses to send mail — that's usually 587).
- 80 / 443 — HTTP and HTTPS, standard web traffic.
- 3306 — MySQL. Should almost never be open to the public internet.
- 5432 — PostgreSQL. Same caution applies.
- 6379 — Redis. Frequently found exposed by accident, and a real security risk when it is.
- 27017 — MongoDB. One of the most commonly misconfigured “open to the world” databases in the wild.
As a rule of thumb: web ports (80/443) and SSH (22) are meant to be reachable from the internet. Database ports (3306, 5432, 6379, 27017 and similar) generally shouldn't be — if a check shows one of those open to the public, it's worth confirming that's intentional and properly authenticated, not an oversight.
Practical uses
- Confirming a newly deployed service is actually reachable before you spend time debugging the application itself.
- Verifying a firewall rule or cloud security group change took effect — from outside your own network, where it actually matters.
- Checking that a database or admin port you meant to lock down isn't accidentally exposed to the public internet.
- Ruling out “is it even the network” before debugging a connection timeout in an application.
If a port comes back closed or filtered and you expected it open, it's often worth confirming the host itself is reachable at all with a ping test first — that tells you whether you're dealing with a firewall rule specifically, or a broader connectivity problem.
Try it yourself with the port checker — point it at any host and port.