server-assisted
Port checker
Checks whether a TCP port on a host is open, closed or filtered — with latency and service info.
one TCP connect to the given port — nothing is stored
Enter a host and pick a port to run the check.
What the result tells you
The check resolves the host and opens a single TCP connection from the public internet. Three outcomes matter and they mean different things: open means something accepted the connection, closed means the host answered with a reset — it is reachable but nothing is listening — and filtered means the packet vanished, which is what a firewall doing its job looks like.
That distinction is the whole value. Closed points at the service; filtered points at the network in front of it.
The port is open locally but shows filtered here. Where do I look?
Between the internet and the host: a security group, a cloud firewall, an on-host iptables/nftables rule, or a load balancer that has no listener for that port. The service itself is fine — nothing reached it.
What does the latency number mean?
It is the TCP handshake time from our probe to the host, so it includes network distance. It is useful as a comparison, not an absolute: the same port answering in 20 ms one minute and 900 ms the next says more than either number alone.
Can I scan a range of ports?
No, one host and one port per request. This is a reachability check, not a scanner — and running a port scanner on someone else's infrastructure from a shared service is not something we are willing to offer.
Why are private addresses rejected?
The probe runs on our infrastructure, so it can only tell you about addresses reachable from the internet. Asking it about 10.0.0.1 would say something about our network, not yours.
Related tools: SSL / TLS audit, GeoIP lookup and CIDR calculator.