Open, refused, and filtered are not the same thing
Most port checkers collapse everything into "open" or "closed", which throws away the most useful piece of diagnostic information. TCP gives you three distinguishable answers, and knowing which one you got usually tells you where the problem is.
| Result | What the network did | What it means |
|---|---|---|
| Open | The host replied SYN-ACK and the handshake completed. | A service is listening and the whole path allows the port. Nothing to fix. |
| Refused | The host replied with a TCP RST. | The host is reachable and answering, but nothing is bound to that port — the daemon is stopped, or it is bound to 127.0.0.1 instead of 0.0.0.0. |
| Filtered | Nothing came back before the timeout. | A firewall is dropping the packets silently — a cloud security group, a host firewall with a DROP rule, or an ISP block. The service may be running perfectly. |
The distinction matters because the fix is different in each case. A refusal points at the service on the box. A timeout points at something between us and the box. If you are debugging "my site is down", a refused port 443 means nginx died; a filtered port 443 means the security group changed.
What this tool does and does not prove
The check runs from our server, over the public internet. That is exactly the perspective you want when the question is "can the outside world reach this?" — and exactly the wrong perspective when the question is "can my laptop reach this?". A port that is open here but times out from your office is being blocked by your office network, not by the host.
Read the full explanation of port checker results ↓Show less ↑
A completed handshake also says nothing about what is behind the port. Port 443 being open does not mean TLS is configured correctly, that the certificate is valid, or that the right site is being served. Follow up with the SSL certificate checker for the TLS layer and the HTTP headers checker for what the application actually returns.
UDP is not covered, and that is deliberate
This is a TCP checker. UDP has no handshake: a silent UDP port and a firewalled UDP port look identical from outside, so any tool claiming to tell you a UDP port is "open" is either guessing or relying on an application-layer response. If you need to test DNS on UDP/53, query it: dig @<host> example.com either answers or it does not. For other UDP services, use a protocol-specific probe rather than a generic port scan.
Ports worth knowing
- 22 (SSH) — should be open only to the addresses that need it. Open to the world means constant credential-stuffing traffic in your logs.
- 25 (SMTP) — server-to-server mail relay. Blocked outbound by most residential ISPs and by several cloud providers by default; see Is port 25 blocked?.
- 465 / 587 (submission) — where mail clients hand messages to your server. 587 uses STARTTLS, 465 uses implicit TLS. Compare them in port 465 vs 587 vs 25.
- 80 / 443 (HTTP/HTTPS) — 80 should stay open even on an HTTPS-only site, so redirects and ACME HTTP-01 challenges work.
- 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis), 27017 (MongoDB), 11211 (Memcached), 9200 (Elasticsearch) — if any of these answer from the public internet, treat it as an incident. Every one of them has been the entry point for large-scale automated compromises.
- 3389 (RDP), 445 (SMB) — never expose these directly. Put them behind a VPN.
The command-line equivalent
Anything this page does, you can do from a shell — and should, when you need to test from a specific network:
# netcat: -z scan only, -v verbose, -w timeout in seconds
nc -zvw3 cloudflare.com 443
# Connection to cloudflare.com port 443 [tcp/https] succeeded!
# nmap distinguishes open / closed / filtered explicitly
nmap -Pn -p 443,80,22 cloudflare.com
# Nothing installed? bash can open a TCP socket by itself:
timeout 3 bash -c "</dev/tcp/cloudflare.com/443" && echo open || echo "closed or filtered"
# Confirm what is listening locally, and on which interface:
ss -tlnpThat last command is the one that solves most "refused" results. If ss -tlnp shows 127.0.0.1:5432 rather than 0.0.0.0:5432, the service is bound to loopback only and no firewall change will ever make it reachable — you need to change the daemon's bind address.
A troubleshooting order that works
- Confirm the hostname resolves to the address you expect with a DNS lookup. Half of "port closed" reports are DNS pointing at an old server.
- Check the port from here. Open means the problem is on your side of the network.
- If refused: on the server, run
ss -tlnpand confirm the service is running and bound to a public interface. - If filtered: check the cloud security group or firewall rules first, then the host firewall (
ufw status,firewall-cmd --list-all,iptables -L -n). - Still filtered with everything open? Ask your provider whether they block the port upstream — 25 and 445 are commonly filtered at the network edge.
- For mail specifically, use the SMTP connection test, which also reads the server greeting and STARTTLS support rather than just the handshake.