When a connection fails, "the port is not open" is one of the first things on the checklist. But there is a meaningful difference between a port that is closed, one that is firewalled, and one that is open but the service behind it is broken. Knowing which situation you are in changes what you do next.
Three States a Port Can Be In
Open — something is actively listening on that port. A TCP connection attempt completes the three-way handshake. This is what you want.
Closed — the machine is reachable but nothing is listening on that port. The OS sends back a TCP RST (reset) immediately. This is actually useful — it tells you the machine is up and networking is working, just not that specific service.
Filtered / timed out — a firewall is silently dropping packets. The connection hangs until it times out. No RST, no ICMP rejection, just nothing. This is the most common situation with production servers that have strict firewall rules.
Checking a Port from Multiple Locations
Your own machine can only tell you whether the port is open from your location and ISP. A firewall might block your IP specifically, or a geo-based rule might block an entire country, while the port is perfectly accessible from everywhere else.
The TCP check tool tests whether a port is open from 50+ global nodes simultaneously. Enter example.com:443 (or just an IP with port), run the check, and you immediately see which regions can connect and which cannot.
Partial results — some nodes timing out while others succeed — almost always indicate IP-based blocking or geo-filtering, not an actual service problem.
Checking from Your Own Machine
For quick local tests:
Telnet (available on most systems):
telnet example.com 443
Immediate connection = open. Hangs = filtered. Immediate "Connection refused" = closed.
Netcat (Linux/macOS):
nc -zv example.com 443
PowerShell (Windows):
Test-NetConnection -ComputerName example.com -Port 443
Common Ports Reference
| Port | Service |
|---|---|
| 22 | SSH |
| 25 | SMTP |
| 80 | HTTP |
| 443 | HTTPS |
| 3306 | MySQL |
| 5432 | PostgreSQL |
| 6379 | Redis |
| 8080 | Alternative HTTP |
Why a Port That Was Open Is Now Filtered
The usual reasons:
Firewall rule change. A new DROP or REJECT rule was added for that port. Check your iptables / nftables / security group rules.
Service crashed. If the OS sends back RST immediately, nothing is listening. If it times out, a firewall is blocking the port even though the service is dead.
Fail2ban or automatic IP blocking. Tools like fail2ban and CSF ban IPs after repeated failed login attempts. If nodes in the TCP check show inconsistent results (some succeed, some fail), this is often the cause. Try checking from a different country.
DDoS mitigation. Some hosting providers activate port-level blocking automatically under high traffic. This can block legitimate traffic along with the attack.
UDP Port Testing
UDP has no handshake — there is no way to definitively confirm a UDP port is "open" the way you can with TCP. You send a packet; if you get a response, something is listening. If there is no response, the port might be open and silently processing traffic, or it might be blocked.
The UDP check tool sends probes and reports responses. Useful for diagnosing game servers, VPN endpoints (WireGuard on 51820, OpenVPN on 1194), DNS (port 53), and NTP (port 123).