Port Checker

About the Port Checker

This tool checks whether a single TCP port is reachable on a host. It resolves the hostname to its public IP, opens one TCP connection to the port you specify, and reports a clear verdict: open (something is listening and accepted the connection), closed (the host answered but actively refused the connection, meaning nothing is listening) or filtered (no response at all before the timeout, which usually means a firewall is silently dropping the traffic). Alongside the verdict you get the resolved IP, the well-known service name for common ports, and the connect time in milliseconds.

It's the quick way to answer "is this actually reachable from the outside?", whether that's a mail server on 25 or 587, a database on 3306 or 5432 that shouldn't be public, SSH on 22, a control panel on 2222, or your own app behind a load balancer. Because the check runs from our server on the public internet rather than from your own machine, it tells you what the internet actually sees, which is exactly the question a firewall change or a new deployment usually raises.

This performs a single connect to one host and one port per query, deliberately, not a sweep across a range of ports or a list of hosts. That keeps it useful for verifying something you operate without turning it into a general-purpose scanning service. If you need to check several ports, run the check again for each one.

Private, loopback, link-local and other non-routable targets are refused before a connection is attempted, and the hostname is resolved to a public IP first, so DNS can't be repointed at an internal address to get around the guard.

How to use it

1. Enter a hostname or IP address, or combine both as host:port.
2. If you didn't include a port inline, enter the TCP port to test (1-65535).
3. Optionally set a custom connect timeout in milliseconds (default 5000, capped at 10000).
4. Submit to make a single TCP connection attempt from our server.
5. Read the verdict, open, closed or filtered, alongside the resolved IP.
6. Check the connect time in milliseconds to spot high latency even on a port that is open.

Examples

• Confirm a new mail server answers on port 25 (SMTP) and 587 (Submission) before pointing MX records at it.
• Check whether MySQL on 3306 or PostgreSQL on 5432 is reachable from the public internet, and lock it down if it shouldn't be.
• Verify SSH (22) or a DirectAdmin panel (2222) responds again after tightening a firewall rule.
• Test example.com:8443 to confirm a non-standard HTTPS port is actually open before wiring up a reverse proxy.
• Tell a closed port (refused instantly) apart from a filtered one (silently dropped) when a service that used to work suddenly stops answering.

Open, closed and filtered: what each verdict means

The wording matters, because each verdict points at a different fix.

• open: the TCP handshake completed; something is listening on that port and accepted the connection
• closed: the host answered but actively refused the connection (a TCP RST); the host itself is reachable, nothing is listening on that specific port
• filtered: no response came back at all before the timeout, the classic signature of a firewall silently dropping the packets rather than rejecting them
• error: a different connection-level failure was returned by the network stack (for example, no route to host), reported with the raw error code

Well-known ports reference

When a port you test matches a well-known service, the checker names it automatically. The current table:

• 20 FTP-data, 21 FTP, 22 SSH, 23 Telnet, 25 SMTP, 53 DNS
• 80 HTTP, 110 POP3, 143 IMAP, 443 HTTPS
• 465 SMTPS, 587 Submission, 993 IMAPS, 995 POP3S
• 2083 cPanel, 2087 WHM, 2222 DirectAdmin / SSH-alt
• 3000 dev server, 3306 MySQL, 3389 RDP, 5432 PostgreSQL
• 5672 AMQP, 6379 Redis, 8080 HTTP-alt, 8443 HTTPS-alt
• 9000 PHP-FPM, 11211 Memcached, 27017 MongoDB

A single check, not a port range scanner

This deliberately checks one host and one port per query rather than sweeping a range, which is why there's no scan-a-block-of-ports mode. That keeps the service focused on verifying something you actually operate, rather than functioning as a general-purpose network scanner. If you need to confirm several ports on the same host, e.g. 80, 443 and 8443, run the check once per port; each one takes a fraction of a second.

Common pitfalls when testing a port remotely

A few things trip people up when comparing a local test against this one:

• testing from your own machine over a VPN or LAN can show open even though the same port is blocked from the public internet; a check from an external server, like this one, catches that gap
• cloud load balancers and CGNAT can make a port look reachable on one IP while the actual origin server behind it is not, if DNS points somewhere unexpected
• a filtered result can also mean the host is just slow to respond within the timeout window rather than actively firewalled; raising the timeout parameter helps rule that out
• an open port only confirms the TCP handshake succeeds, not that the application behind it is healthy; pair this with the SSL or HTTP checker to validate what's actually running there

Frequently asked questions