Free Open Port Scanner

Scan any domain for 17 commonly targeted network ports and find out which are open, closed, or filtered. Each port is assessed with a security risk level – from low-risk services like HTTPS to critical exposures like open database ports or RDP. Know exactly what your server is exposing to the internet.

How to Use This Tool

1. Enter a domain name – for example, example.com. The tool accepts bare domains and strips protocols and paths automatically if you paste a full URL.
2. Click “Scan” to begin checking all 17 ports. The tool attempts a TCP connection to each port with a 5-second timeout and reports whether the port accepted the connection (open), actively refused it (closed), or didn’t respond (filtered/blocked).
3. Review the results. Each port shows its number, service name, status (open/closed/filtered), and a risk assessment. Ports flagged as critical or high risk deserve immediate attention.

Understanding Your Results

The scanner checks these 17 ports, each associated with a specific service:

What the statuses mean

• Open – the port accepted the connection. A service is actively listening and responding. This is expected for ports like 80 and 443 on a web server, but alarming for ports like 3306 (MySQL) or 3389 (RDP).
• Closed – the port actively refused the connection (sent a TCP RST). The server is reachable but no service is listening on that port. This is fine.
• Filtered – no response within the timeout period. Usually means a firewall is silently dropping the connection attempt. This is the ideal state for ports you don’t want exposed – it gives attackers no information about whether the port exists.

Why This Matters

Every open port is a potential entry point for attackers. The principle of least exposure says a server should only expose the minimum ports required for its function – a web server needs 80 and 443, a mail server needs 25, 993, and 995, and everything else should be firewalled off. Ports left open by accident or default configuration are one of the most common causes of security breaches.

The critical-risk ports in particular (Telnet, SMB, MySQL, PostgreSQL, RDP) are actively scanned by automated attack tools across the entire internet, 24 hours a day. The Verizon Data Breach Investigations Report consistently finds that exposed RDP is one of the top initial access vectors for ransomware. An open MySQL port means anyone on the internet can attempt to authenticate to your database. These aren’t theoretical risks – they’re how breaches happen in practice.

Even if you’re not a server administrator, a port scan of your own network helps you understand what’s visible to the outside world. VPN users can scan their IP before and after connecting to see exactly which ports their VPN provider’s infrastructure exposes.

Frequently Asked Questions

Is port scanning legal?

Port scanning your own infrastructure or systems you have authorization to test is legal in most jurisdictions. Scanning third-party systems exists in a gray area – it’s generally not illegal in the US and EU (courts have compared it to knocking on a door to see if someone’s home), but some organizations may consider it hostile activity and block your IP. This tool is designed for checking your own servers and domains. If you’re scanning a domain you don’t control, use good judgment and be aware of the target’s acceptable use policies.

Why does the scan show port 80 open but I set up HTTPS – is that a problem?

No, having port 80 open is normal and expected even on HTTPS-only sites. Port 80 typically serves a redirect that sends visitors to the HTTPS version on port 443. If you close port 80 entirely, users who type your domain without https:// (which is most users) will see a connection error instead of being smoothly redirected. The standard practice is to keep port 80 open but configure it to issue a 301 redirect to the HTTPS URL.

A critical port is open on my server – what should I do?

If ports like 3306 (MySQL), 5432 (PostgreSQL), or 3389 (RDP) are showing as open: configure your server’s firewall (iptables, ufw, or Windows Firewall) to block incoming connections on those ports from the public internet. For database access, connect through an SSH tunnel or VPN instead of exposing the port directly. For remote desktop, use a VPN to connect to the server’s private network first, then RDP over the encrypted tunnel. After making firewall changes, run this scan again to verify the ports no longer respond.