Open port checker

Refused and filtered are not the same answer

Most port checkers tell you "open" or "closed". That throws away the more useful half of the result, because a port can fail to open in two very different ways.

• Refused: the host answered and said nothing is listening. That is a complete, working network path. Routing and firewalls are fine, and the problem is the service.
• Timed out: nothing came back at all. Something is dropping packets silently, which is what a firewall is normally configured to do, or the host is not there.

If you are debugging a service that will not accept connections, that distinction decides where you spend the next hour. A refused connection means stop looking at the network. The same three-way distinction applies to application errors, which is covered in no route to host.

What this checks, and what it cannot

This connects from our server, so it tells you what the internet sees, which is exactly the question when you have opened a firewall rule and want to know whether it worked. It cannot tell you about ports on your own machine or inside your network, because those are not reachable from here, and it will refuse targets on private address ranges.

It also only tests TCP. There is no reliable way to test port reachability over UDP from outside, because a correctly configured UDP service often answers nothing at all: silence and a dropped packet look identical.

Ports that should give you pause

Some services are perfectly normal on a private network and a genuine exposure on a public address. If this check finds 445 (SMB), 3306 (MySQL), 3389 (RDP) or 5432 (PostgreSQL) reachable from the internet, that is worth investigating rather than noting. Remote desktop in particular is a routine entry point for ransomware, and databases are rarely meant to accept connections from anywhere.

Services like these are normally reached over a VPN, or restricted to known source addresses.