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. These are the same state names Nmap documents, so results read the same way across tools.
Step 1. Open the port checker
Open the Port Checker tool. Two fields matter most: the host, and the list of ports. Below them sit a preset menu and the IP version and Protocol selects, with banner grabbing and the timeout under Advanced options.
Step 2. Enter the host
The host can be a hostname (example.com) or an IPv4 or IPv6 address (104.20.23.154). All of them work. If you give a hostname, the tool resolves it to an IP first, probes that IP, and shows you the address it scanned above the results.
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, so one check only tells you about whichever backend it landed on. (example.com resolved to two different addresses across the test runs for this guide.)
Step 3. Pick the ports
You can type any comma-separated list of ports (1-65535) and ranges such as 8000-8010, up to 100 ports per check. The Common ports menu also fills the field with one of five presets:
- Web - 80, 443, 8080, 8443. The standard four HTTP/HTTPS variants.
- Mail - 25, 465, 587, 993, 995. SMTP, SMTPS, submission, IMAPS, POP3S. Only 993 and 995 can give a real answer from here (see below).
- Remote - 22, 3389, 5900. SSH, RDP, and VNC, often locked down to specific source IPs.
- Databases - 3306, 5432, 6379, 27017, 1433. MySQL, PostgreSQL, Redis, MongoDB, SQL Server, none of which should be exposed to the public internet. A database preset that returns open ports is a red flag.
- Top - 21, 22, 23, 25, 53, 80, 110, 143, 443, 3306, 3389, 8080. A quick sweep of the services scanners look for first.
A preset replaces whatever is in the ports field rather than adding to it. Choosing Web and then Mail leaves only the Mail ports, so pick the preset first and type any extra ports on the end.
SMTP ports 25, 465 and 587 can't be tested from here. The check runs from our London probe, and DigitalOcean blocks those three ports on every Droplet, the probe's included, so those connections never get out. The tool labels them not testable, which says nothing about your server. Ports 993 and 995 aren't blocked and give a normal result. To test SMTP itself, run nc -zv mail.example.com 25 from a machine whose network allows outbound SMTP, keeping in mind that plenty of home ISPs and cloud providers block port 25 too.
Step 4. Run the check
Click Check ports. The tool probes every port in parallel, waiting up to 2000 ms per port by default (set anything from 200 to 10000 ms under Advanced options), then shows all the results in one table. This is real output from a check of example.com on 7 November 2026:
2 OPEN · 3 CHECKED · 2052ms
TCP · IPV4 · LONDON
104.20.23.154
PORT STATE SERVICE RTT (MS)
22 filtered ssh -
80 open http 5
443 open https 4
The run took just over 2 seconds because the filtered port used its full timeout. SERVICE is the usual service for that port number, not proof of what is actually listening. RTT is measured from London, so distance counts towards it.
A few practical reads from this output:
openwith an RTT of a few ms means the service is up and accepting connections quickly. Normal.openwith an RTT above 500 ms means the service is up but slow. Could indicate load, an overworked service, or geographic latency.closedmeans the host is up and actively refused the connection. Service is gone, deliberately or otherwise. No RTT is shown.filteredmeans no reply before the timeout, so the RTT shows-. Firewall is dropping. Could also mean the host is offline entirely. You can't tell the difference from the outside.not testableonly appears on TCP ports 25, 465 and 587, and means the probe's own host blocked the connection.
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. To test the host itself, check a port you know should answer: any open or closed result proves the host is up.
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:
- Local service:
ss -tlnp | grep :443on the host - Cloud security group / VPC firewall rules
- Corporate or office network firewall (often blocks SSH, RDP)
- 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 (in the UK, the Computer Misuse Act 1990). 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. DNS (53), DHCP (67/68), SNMP (161), and VPN protocols such as WireGuard (51820) are typically UDP, so switch the Protocol select to UDP for those (how to troubleshoot a VPN connection lists the VPN ports). UDP port-checking is fundamentally less reliable because UDP is connectionless and many services only answer a valid request. No reply shows as open|filtered: the port may be open, or a firewall may have dropped the probe. closed is the firm answer, because the host replied that nothing is listening.
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
- Open the Port Checker.
- Enter a hostname or IP.
- Pick ports. Use a preset (it replaces the field) or type a custom comma-separated list or range.
- Run. Read the STATE column. Filtered means a firewall is dropping silently, not necessarily that the host is down.
not testableon 25, 465 or 587 says nothing about your server: our London probe can't reach those ports. - Investigate any unexpected open ports immediately; investigate filtered ports you expected to be open via your local network setup first.