Online Port Checker
Probe TCP ports on a host or public IP, read the exposure notes, and copy a tidy report.
This online port checker pokes a TCP port from our server and tells you whether anything actually answers, which is exactly what you want to know after a firewall edit, a migration or a mail setup that won't cooperate. Type a host or public IP, list the ports or a short range, or load a profile for a web server, mail server, remote admin box or database review. Each result comes with an exposure reading, so an open database port or a wide-open admin service gets flagged instead of buried. One thing to be clear about: this checks reachability only. It does not log in, fingerprint versions or prove a service is safe. An open port just means something picked up the phone. You can also copy a clean text report and skim the built-in reference of common ports.
Queries run through the PeopleAreGeek lookup service. We log nothing.
Live TCP reachability utility
So here's what this does. It pokes a TCP port from our server and tells you if anything answers. Load a profile, skim the exposure notes, grab a tidy report when something's misbehaving on a firewall or a fresh box. One thing to get straight though: this checks reachability. It doesn't log in, it doesn't fingerprint, it won't tell you a service is safe. An open port only means something picked up the phone. What that something is, and whether it should be reachable at all, that's on you to read against the server's job.
Every probe goes out from the site backend over TCP. Heads up: a firewall might swallow the check on purpose, and even a port that answers still has to be locked down properly.
What an online port checker can and cannot tell you
An online port checker answers one narrow question, and it's a useful one: can an outside network actually reach this host on this port? You'll want that answer after a firewall edit, a migration, a mail setup that won't cooperate. Reverse proxy work too. If HTTPS is meant to be public, 443 should pick up. And if a database is supposed to stay private but its port answers from the outside, well, that's the kind of thing you go look at right now.
Now what it is not. It's not a vuln scan, and it sure isn't proof your service is healthy. An open port can sit in front of something fully patched and locked behind an allowlist. A port that times out can be completely deliberate, just a firewall quietly dropping probes from strangers. Honestly, I think the whole value here is the comparison: reachable versus what you meant to expose. The gap between those two is where the bugs live.
How to interpret common TCP ports
- 80 and 443 carry HTTP and HTTPS. Public web traffic. Seeing these open is usually fine.
- 22 and 3389 are how you get into a box remotely, so they should only ever be open because you decided they would be.
- 25, 465 and 587 handle mail transport or submission, but only if this host genuinely runs email. If it doesn't, why are they answering?
- 3306, 5432, 1433, 6379 and 27017 are data services. As a rule they belong behind a private network or an allowlist, not out in the open.
- 21, 23 and 445 deserve a hard look. Legacy stuff, and the kind of ports attackers love for moving sideways once they're in.
A useful firewall workflow
Start with what the server is for. A public web server, a VPN gateway, a database node sitting quietly in the back, none of these want the same exposure. So check the ports that ought to be open. Then run a short list of the sensitive ones that absolutely shouldn't be, and make sure they aren't. Got a management service that genuinely has to stay public? Then wrap it: lock it to known source IPs, push it behind a VPN, bolt on MFA and keep loud logs. And when a port reads closed but the app should be reachable, walk the chain. Is the service even bound to a public interface? Then cloud security groups, the host firewall, NAT, whatever your provider filters upstream. Usually it's the boring one you skipped.
Port checker results and security context
Reachability is just layer one. For a web service, your next stop is HTTP headers and the SSL cert, plus a quick look at how redirects behave. Running mail? Then it's DNS records and TLS policy, and honestly the reputation stuff matters more than people expect. For admin ports, I'd want patching confirmed and key-based access only, with rate limiting and eyes on the logs. Here's the thing I keep coming back to, and maybe it's just me: the best port report isn't the one with the fewest open services. It's the one that lines up with a plan you actually wrote down somewhere.
Frequently asked questions
Why does my port show closed when the service works locally?
Usually the service is only listening on localhost or some private interface, so it works for you and nobody else. Or something in the path is blocking the outside connection, a firewall, a cloud security group, the router, your provider upstream. Any one of those will do it.
Can this tool test UDP?
Nope, TCP only. It works by trying to open a connection. UDP is a different animal and frankly harder to read, since plenty of UDP services just sit there and never reply to a probe they did not ask for.
What does it mean when a port is open or closed?
Open means something is listening and you reached it. Closed means either nothing is home, or a firewall actively bounced you. Filtered is the sneaky one. That is a firewall quietly dropping your probe and never saying a word, so you just sit there waiting.
Why should I not leave database ports open to the internet?
Because bots scan 3306, 5432, 6379 and 27017 around the clock. Leave a database hanging out there and it gets brute-forced or hit with a known exploit fast, sometimes within minutes of going live. Tuck it behind a VPN or an SSH tunnel and let it talk to your app, not the whole internet.