Port checker that grades your exposure

Open means the TCP handshake completed — a service is listening and reachable. Closed means the host answered with a reset but refused the connection — reachable, nothing listening on that port. Filtered means no usable answer came back at all: a firewall either dropped the packet silently, or refused it with an ICMP unreachable message. Either way you can’t confirm a service is there. For a database or admin port that is the state you want: an attacker’s scanner learns nothing either.

It’s the most serious thing this tool looks for. Databases like MySQL, PostgreSQL, Redis and MongoDB are meant to be reached only by your application over a private network. When one answers the public internet, anyone who reaches the IP can attempt to connect. Usually a container published its port to 0.0.0.0 instead of loopback. Redis in particular is designed for a trusted network and has no authentication unless you configure it. We never send a command or attempt a login, so we can’t say whether an attacker would get in. What we can say is that the door answered, and internet-wide scanners catalogue open database ports continuously. Bind the service to 127.0.0.1 or firewall the port today.

No. Open means reachable, not compromised and not necessarily exploitable. A fully patched, authenticated service on an open port can be perfectly safe — 443 is open on every HTTPS site you use. What we grade is exposure: whether a port that shouldn’t face the public internet is doing so anyway. We don’t test the application behind the port, and we never attempt a login or send an exploit. For actual vulnerability testing you’d want a dedicated scanner, run with permission.

Scan hosts you own or have explicit permission to test, and you’re on solid ground. Port-scanning third-party infrastructure without permission can breach acceptable-use policies and, in some jurisdictions, laws. This tool ships guards to keep it a diagnostic and not a weapon. It refuses private, loopback, link-local and carrier-NAT addresses, in the probe as well as the app, so a bypass of one still hits the other. Scope is capped at the common preset, one port, or a bounded range rather than a full sweep. Scans are rate-limited per source and per target. Each port gets one TCP connect: a banner is read where the service volunteers one, then we disconnect.

Almost always nothing. Many services announce themselves the moment you connect. An SSH daemon sends SSH-2.0-OpenSSH_9.9; an SMTP server sends a 220 greeting; MySQL sends a handshake carrying its version. For those we write zero bytes and read what was volunteered. Three exceptions. On plain HTTP ports we send one HEAD / HTTP/1.0 request to read the Server header. On 443 and 8443 we finish the TLS handshake, record the negotiated version and certificate, then send that same HEAD inside it. Other TLS ports get the handshake only. That’s the entire list. We never send a protocol command, not even a Redis PING, and never a credential. Every result page tells you which of those applied to your scan.

Because that’s the firewall working. If a port comes back filtered, a device between us and the service refused or dropped the packet. We can’t distinguish “no service” from “service, hidden”, and we don’t pretend to. Behind a CDN or load balancer you’re scanning the edge, not your origin. The numbers describe what the proxy exposes, which is why an open 8080 on a CDN edge is normal rather than alarming. That’s a feature: putting a service behind a firewall is meant to hide it from scanners like this one.

Because for a port scan it rarely changes the answer. A port open to the internet is open from everywhere. Multi-location matters for latency and geo-routed availability, which our Ping Test and country tools cover. We spend the effort on reading the result instead: grading exposure, separating a silent drop from an explicit refusal, and flagging the database ports that raw scanners leave you to interpret alone.