Open
A TCP connection completed, so something is listening and accepting. If a service greets us first, its banner is shown — that says what is actually there, rather than what the port number implies.
Tries a single TCP connection to the address the internet sees you from. Answers immediately unless the port is firewalled, which takes five seconds.
A refused connection proves the host is reachable and nothing is listening — definite, useful information. A timeout proves nothing at all, because a firewall silently dropping packets and a host that does not exist look identical from outside. Most port checkers report both as “closed”.
A TCP connection completed, so something is listening and accepting. If a service greets us first, its banner is shown — that says what is actually there, rather than what the port number implies.
The host actively refused. It is reachable, routable, and has nothing on that port. A clean answer.
Nothing came back. Consistent with a silent firewall, and equally consistent with a host that is not there. Not evidence that the port is closed.
There is no address field. The check runs against the address the internet sees you from, which is the only direction that answers the question — and means this cannot be pointed at anyone else.
The obvious objection to a server-side check is that the traffic comes from us rather than from you. That is unavoidable, and it is the point: reachability from the internet can only be measured from the internet. A test that ran in your browser would be connecting from inside your own network — it would either loop back through your router, which tests the wrong side of it, or fail regardless of whether the port is genuinely open. Every tool that does this properly runs server-side for the same reason.
What we will not do is check a port on a host you name. Connecting to a published service on its standard port and speaking the protocol — which is what the certificate, header and SIP checks do — is ordinary client behaviour that every uptime monitor performs. Probing a port to see whether anything answers, on a host that did not ask, is port scanning by definition. Pointed at third parties from one address it is also how a hosting account gets suspended, so the service refuses a host outright rather than rate-limiting it.
What an open port means depends entirely on which port. 443 open on a web server is the point. 3389 open to the internet is the single most commonly attacked exposure there is, and 6379 open means a Redis instance with no authentication is reachable by anyone who looks. The checker marks the ports that should not face the internet, because “open” is good news for some and an incident for others.
One limit worth keeping in mind: the result describes the path between our server and you. A port open to us is open to the internet generally, but a port that times out for us could still answer a different network if you run an access list that permits some addresses and not others.
Something between us and the service is dropping the connection silently — a firewall, a NAT with no forward configured, or an access list that only permits known addresses. The service being up locally tells you nothing about whether it is reachable from outside, which is the whole point of checking from here.
Just pick the port — the check already runs against the address we see your connection from, which is the address the forward has to be configured on. This is also why testing from inside your own network is useless: the traffic never leaves, so it appears to work whether the forward exists or not.
Because probing ports on a host that did not ask is port scanning, and doing it from one address on behalf of strangers is how a hosting account gets suspended and an IP ends up on abuse lists. The check always runs against the address your own request came from. If you administer a server elsewhere, run a check from a machine you control — or visit this page from that network, which tests the same thing.
It depends on whether you meant it. SSH exposed to the internet is normal for a server and should then have password authentication disabled, key-only access, and ideally a restriction to known addresses. SSH exposed by accident — on an appliance, a camera, a printer — is a problem. The checker flags it so the question gets asked.
No. UDP has no connection to establish, so the only way to test it is to send a protocol-specific message and wait for a protocol-specific reply — which means sending unsolicited traffic to somebody else's service. We do not do that.
An expired certificate, a missing header or an exposed port is a finding. Knowing which of them matters on your estate, fixing them without breaking the application, and noticing the next one before a stranger does is the work. That is what we do, continuously rather than as a report.