How to check open ports on a host

You want to know whether a specific TCP port is reachable on a host from the public internet. Maybe the question is "is the new service actually exposed?" or "did the firewall change land?" or "is something listening here that shouldn't be?"

A port check answers in seconds. This guide covers the standard workflow, the meaning of every result state, and the common mistakes that lead to wrong conclusions.

What "open port" really means

A TCP port can be in one of three states from an external probe's perspective:

• Open - a process is listening, accepted the TCP handshake, and is willing to talk.
• Closed - no process is listening. The host responded with a TCP RST (reset). The network reaches the host fine; nothing's there.
• Filtered - no response at all. A firewall is silently dropping the packets. Looks identical to "host is down" from the outside.

The distinction between closed and filtered is the most diagnostic part of a port check. Closed means your network path is fine and the service is gone. Filtered means the network is blocking you before you can even ask.

Step 1. Open the port checker

Open the Port Checker tool. Two fields: the host, and a comma-separated list of ports.

Step 2. Enter the host

The host can be a hostname (example.com) or an IP address (93.184.216.34). Both work. If you give a hostname, the tool resolves it to an IP first (using the DNS Lookup under the hood) and then probes the resulting IP.

If you have multiple IPs to check, say you want to verify a load-balancer pool, run the port check against each IP separately, not against the hostname. The hostname might round-robin and you wouldn't know which backend you actually hit.

Step 3. Pick the ports

You can type any comma-separated list of ports (1-65535). The tool also includes four preset bundles for common needs:

• WEB - 80, 443, 8080, 8443. The standard four HTTP/HTTPS variants.
• MAIL - 25, 465, 587, 993, 995. SMTP submission, SMTPS, IMAPS, POP3S.
• SSH - 22. The classic, often locked down to specific source IPs.
• DB - 3306, 5432, 6379, 27017. MySQL, PostgreSQL, Redis, MongoDB, none of which should be exposed to the public internet. A "DB" preset that returns open ports is a red flag.

You can stack presets, click WEB, then MAIL, then add your own custom ports to the field. Anything goes.

Step 4. Run the check

Click Check ports. The tool runs all probes in parallel with a 3.5-second timeout per port. Results stream back into a table:

A few practical reads from this output:

• open · <few ms> means the service is up and accepting connections quickly. Normal.
• open · >500ms means the service is up but slow. Could indicate load, an overworked service, or geographic latency.
• closed · <few ms> means the host is up and rejecting fast. Service is gone, deliberately or otherwise.
• filtered · 3500ms means timeout. Firewall is dropping. Could also mean the host is offline entirely. You can't tell the difference from the outside.

If you need to distinguish "filtered" from "offline", run a separate DNS lookup on the hostname. If it resolves, the registration is fine; if it also fails, the whole domain is the issue.

Step 5. Investigate the unexpected

Three patterns worth flagging:

A port you didn't open is reporting open

This is the highest-signal finding in a port check. Something is listening on a port you don't have a reason for. Possible causes, in roughly decreasing order:

• A deploy script enabled a debug or management interface in production
• Default firewall rule changed and exposed an internal-only service
• Compromised host running a backdoor process
• A forgotten service from a prior project still binding the port

Investigate immediately. The WHOIS lookup on the IP can tell you who owns the address range; combined with ss -tlnp on the host itself, you can usually identify the process.

A port you expect open is filtered

Either the service isn't running, or there's a firewall layer between you and it. Check in this order:

1. Local service: ss -tlnp | grep :443 on the host
2. Cloud security group / VPC firewall rules
3. Corporate or office network firewall (often blocks SSH, RDP)
4. ISP egress firewall (rare but real for residential connections)

Port shows open from outside but service is broken

Open from a port check means the TCP handshake completes. That tells you nothing about whether the service behind the port is healthy. An HTTP server returning 500 to every request still answers the TCP handshake.

For deeper service-level checks, combine the port check with the HTTP Header Checker (for web), the SSL Certificate Checker (for HTTPS), or a synthetic transaction against an actual endpoint.

Common port-check mistakes

Scanning hosts you don't own. Don't. Port scanning a server you're not authorised to test can land you on the wrong side of computer-misuse laws in most jurisdictions. Only scan your own infrastructure or hosts you have explicit written permission to test.

Trusting a single check. Run a port check from a few different network locations if you can, your own machine, a cloud VM, a colleague's network. Some firewalls allow specific source IPs; a "closed" from one location might be "open" from another.

Forgetting UDP. This tool checks TCP. DNS (53), DHCP (67/68), and SNMP (161) are typically UDP. UDP port-checking is fundamentally less reliable because UDP is connectionless and "filtered" is indistinguishable from "no response needed."

Confusing open with secure. An open port is just a fact about reachability. Whether it should be open, whether the service is patched, and whether the authentication is correct are separate questions.

Quarterly external scan

If you operate any production infrastructure, run a port check against every public IP you control at least once a quarter. The diff between the last quarter and this one is one of the highest-signal security alerts you can configure. A port that's newly open, or one that was open and is now mysteriously closed, are both findings worth investigating.

There's a longer article on port-security basics covering the audit workflow in more depth.

Related tools

• SSL Certificate Checker - once a port responds, verify the TLS cert if it's HTTPS.
• HTTP Header Checker - the layer above port-level reachability.
• DNS Lookup - resolve a hostname to all its IPs before scanning each one.

TL;DR

1. Open the Port Checker.
2. Enter a hostname or IP.
3. Pick ports. Use a preset or type a custom comma-separated list.
4. Run. Read the open / closed / filtered column. Filtered means a firewall is dropping silently, not necessarily that the host is down.
5. Investigate any unexpected open ports immediately; investigate filtered ports you expected to be open via your local network setup first.