What a connect scan actually tells you
A TCP port is not a door that is open or shut. It is a number a program may have asked the operating system to listen on, and the only way to find out from outside is to try to start a conversation and see what comes back. This tool opens a real TCP connection to each port, watches the three-way handshake, and closes it again without writing or reading a single byte.
handshake completes → open; the host resets → closed; nothing comes back before the deadline → filtered
The difference between the last two is the part most hosted port checkers throw away, and reporting a timeout as closed is a false statement about the network: closed proves a live host declined, while filtered proves nothing about the port and quite a lot about the firewall in front of it. If every port on a scan comes back filtered, the useful conclusion is that nothing answered — not that the host is secure.
The three states
Each row is one TCP connection attempt and what came back from it. The response time is the round trip to the handshake or the reset — it is a rough distance measurement, not a health check.
| State | What happened | What it proves |
|---|---|---|
| Open | The handshake completed. Something is listening. | A program is listening and accepted a connection from our address. It may still refuse yours. |
| Closed | The host sent a reset. It is reachable, and nothing is listening here. | The host is up and reachable. Nothing is bound to that port, and no firewall is hiding it. |
| Filtered | Nothing came back. Something dropped the packet silently, or the host is gone. | Nothing. A filter dropped the packet, the host is down, or the network in between lost it. |
What this deliberately does not do is a SYN scan, which never completes the handshake and exists mainly to be harder to log; read the banner a service announces on connect; or guess a software version. The service column is a static table of what each port is registered for, so a web server running on port 22 will be labelled SSH and the label will be wrong. That is the honest cost of not fingerprinting.
The port lists
The default is the set Nmap reports as the most scanned on the internet — the ports that carry the services almost every host runs, and therefore the ones worth checking first.
| Preset | Covers |
|---|---|
| Most scannedThe ports Nmap reports as the most scanned on the internet. | 20, 21, 22, 23, 25, 53, 80, 110, 111, 135, 139, 143, 443, 445, 502, 587, 993, 995, 1723, 2525, 3306, 3389, 5900, 8080 |
| WebHTTP and HTTPS, including the alternates a dev server picks. | 80, 443, 3000, 5000, 8000, 8008, 8080, 8443, 8888 |
| MailSMTP, POP3 and IMAP, plain and over TLS. | 25, 110, 143, 465, 587, 993, 995, 2525 |
| DatabasesThe engines most often found facing the internet by accident. | 1433, 1521, 3306, 5432, 5984, 6379, 9042, 9092, 9200, 11211, 27017 |
| Remote accessSSH, Telnet, RDP, VNC and the Windows remoting pair. |
The limits, and why each one exists
None of these are tuning knobs. A hosted port scanner is an abuse surface before it is a feature, and these are most of what keeps it from being one.
| Limit | Value | Why |
|---|---|---|
| Ports per scan | 128 | A few hundred half-open connections is rude; several thousand is a denial of service with a progress bar. |
| Per-port timeout | 1500 ms | Comfortably past an intercontinental round trip, which tops out near 400 ms. Longer, and a fully-dropped scan just sits there. |
| Connections at once | 16 | All of them at once looks like a SYN flood from the far end, which is how a server's address gets blocked by the networks it most needs to reach. |
| Scans per hour | 10 / hour | Counted per visitor in a database rather than in memory, because a counter that a cold start resets is not a limit. |
| Address ranges | — | Private, loopback, link-local, carrier-grade NAT, cloud metadata and reserved ranges are refused — including an IPv4 address hidden inside an IPv6 literal. |
Before you scan somebody else's host
Port scanning a host you do not own is, in many jurisdictions, at best a grey area and at worst a criminal offence — the UK's Computer Misuse Act, the US Computer Fraud and Abuse Act and their equivalents elsewhere are written broadly enough to cover unauthorised probing. Whether a given scan is lawful depends on where you are, where the host is, and what you agreed to. This is not legal advice, and nothing here should be read as permission.
There is a practical point on top of the legal one. The scan runs on our servers, so the entry it leaves in the target's log carries our address, not yours. An operator who notices it blocks us, and every other visitor loses the tool. That is why there is an hourly limit, why the port count is capped, and why we would rather you pointed it at your own address.
Nothing about a scan is stored — not the host, not the ports, not the result. The one thing kept is a salted hash of your address with a count against it, so the hourly limit can be enforced without the table knowing who you are.
What people use this for
Checking what your own connection exposes: whether the router is forwarding 3389 to a desktop, whether a home server's SSH is reachable from outside, whether a port you opened for one evening is still open.
Confirming a firewall rule did what you meant. A port that reads filtered from outside and works from inside is the rule behaving; one that reads closed is the rule missing.
Checking that a service you just deployed is actually reachable — the difference between "the process is running" and "the internet can get to it" is a security group nobody edited.