Scan open TCP and UDP ports on any IP address or domain. Audit cloud infrastructure, find exposed services, check IoT devices, map your attack surface, or verify game server connectivity — all from outside your network.
An open port scanner (also called a port checker or port forwarding tester) probes specific TCP or UDP ports on a remote host to determine whether services are reachable from the internet. Every network service binds to a port number — web servers listen on 80 and 443, SSH on 22, databases on ports like 3306 or 5432. Knowing which ports are exposed is the first step in both network troubleshooting and security hardening.
This tool scans from our external infrastructure, so results show how your target appears to the public internet — accounting for firewalls, NAT, cloud security groups, and ISP-level filtering. Use it to verify port forwarding on your router, check that your firewall rules are working, or test whether a service is accessible after deployment. Unlike netstat or ss which show local listening sockets, this tests actual reachability from outside your network.
Choose from purpose-built scan presets for common scenarios — web stack verification, cloud infrastructure auditing, attack surface assessment, IoT device scanning, DevOps exposure checks, database exposure, mail server validation, and game server connectivity — or enter custom port numbers. Both TCP and UDP protocols are supported.
This tool supports both TCP and UDP scanning, which work fundamentally differently due to the nature of each protocol:
Attempts a full three-way handshake (SYN → SYN-ACK → ACK) with each port. Produces definitive results:
Sends a datagram and waits for a response. UDP is connectionless, so results are less definitive:
Use TCP for most diagnostics — it's faster and more reliable. Switch to UDP when testing services that use it: DNS (53), NTP (123), SNMP (161), game servers (many use UDP), WireGuard (51820), or SIP (5060).
After provisioning a server on AWS, GCP, or Azure, the first thing to verify is which ports are actually reachable from outside. Cloud providers use security groups, network ACLs, and firewall rules that default to restrictive — but misconfigurations are the leading cause of cloud data breaches.
The Cloud Infra Audit preset checks the ports most commonly misconfigured in cloud deployments:
Restrict to your IP only
Should be in private subnet
No auth by default — RCE risk
Exposes all indexed data
Mass ransom attacks on open DBs
Cluster takeover if exposed
Node compromise via API
Admin panels, debug endpoints
Metrics data leak
If any of these show as open on your cloud instance, review your security group rules immediately. Databases and caches should never be publicly accessible — use private subnets, VPC peering, or SSH tunnels instead.
The Attack Surface preset targets the ports most commonly exploited in real-world attacks. These are the same ports that automated scanners, botnets, and penetration testers probe first:
Run the Attack Surface scan against your own infrastructure regularly. If any of these ports appear as open unexpectedly, treat it as a security incident and investigate immediately.
IoT devices — cameras, routers, smart home hubs, industrial controllers — are among the most targeted endpoints on the internet. The Mirai botnet and its variants have compromised millions of devices by scanning for default credentials on exposed management ports.
The IoT & Embedded preset checks the ports most commonly left open on these devices:
If you manage IoT devices or have smart home equipment, scan your public IP with this preset. Any open port is a potential entry point — these devices rarely receive security patches.
Container orchestration platforms, CI/CD pipelines, and monitoring tools are powerful — and catastrophic when accidentally exposed to the internet. The DevOps Exposed preset targets the management ports that should only be reachable from internal networks.
Unauthenticated Docker API gives full container control — mount host filesystem, execute arbitrary commands, deploy cryptominers. The single most dangerous port to expose.
Jenkins with anonymous access enabled allows arbitrary code execution via Groovy script console. Often found with default credentials or no auth.
Kubernetes stores all cluster secrets (including TLS certs and service account tokens) in etcd. Public exposure means full cluster compromise.
The Kubelet API allows executing commands inside pods. If exposed without authentication, attackers can access any running container on the node.
These ports should never appear as open on a public scan. If any do, your CI/CD pipeline or container platform is directly accessible from the internet — restrict access with firewall rules or private networking immediately.
Active Directory is the backbone of enterprise Windows networks — and the primary target in most corporate breaches. The Windows Domain preset checks the ports that AD domain controllers and member servers expose:
AD ports should never be reachable from the public internet. If you're running a domain controller, these ports should only be accessible within your corporate network or via VPN. Any external exposure is a critical finding.
Publicly exposed databases are one of the most common causes of data breaches. The Database Exposure preset scans the default ports for every major database engine to ensure none are directly reachable from the internet.
Brute-force and SQL injection pivot
pg_hba.conf misconfig common
xp_cmdshell enables OS command execution
No auth by default — write cron for RCE
Ransom attacks on unauth'd instances
Full index data readable without auth
Databases belong in private subnets with no public IP. Access should go through SSH tunnels, bastion hosts, or VPN connections. Even password-protected databases are vulnerable to brute-force attacks and protocol-level exploits when exposed directly.
The Remote Access preset checks protocols used for remote server management and VPN connectivity. Some of these are expected to be open (SSH, VPN endpoints), while others should be locked down or replaced with secure alternatives.
Running your own mail server requires specific ports to be open for delivery and client access. The Mail Server preset verifies the full set:
Server-to-server delivery. Must be open to receive email from the internet.
Client sends mail via STARTTLS. Your email app connects here.
SMTP over implicit TLS. Used by some clients as an alternative to 587.
IMAP over TLS. Clients sync and manage mailboxes here.
POP3 over TLS. Download-and-delete mail access.
Unencrypted IMAP. Should redirect to IMAPS (993).
Port 25 must be open for your server to receive email, but many cloud providers block outbound port 25 by default to prevent spam. If you can't send email, check that your provider hasn't restricted it. Use the DNS Inspector to verify your MX, SPF, DKIM, and DMARC records are correctly configured alongside your mail server ports.
The Web Stack preset covers the ports used by web servers, reverse proxies, and application frameworks. On a production server, you typically want only ports 80 and 443 open — everything else should be internal.
For a port to appear as open from the internet, every layer between the scanner and the service must allow the traffic. Understanding these layers helps diagnose why a port might show as filtered even when your service is running:
This tool tests the entire chain from outside. If a port shows as filtered, work through each layer from the outermost (ISP) inward to find where packets are being dropped.
Hosting a game server requires the correct ports to be open and forwarded. Each game uses specific port numbers that players connect to. Some games use TCP, others use UDP, and many use both — switch between protocols using the dropdown to verify each:
Default Java Edition server port (TCP). The most popular game server port on the internet.
Bedrock Edition uses UDP. Switch to UDP scanning to verify this port.
Counter-Strike 2, TF2, Garry's Mod. Uses both TCP and UDP — test both protocols.
FiveM multiplayer framework for GTA V roleplay servers (TCP + UDP).
When setting up a game server, configure port forwarding on your router, open the port in your firewall, then use this tool to verify it's accessible. If the port shows as open, players on the internet can connect to your server.
Every port scan result falls into one of these categories. Understanding the difference is essential for interpreting results correctly:
A service is actively listening and accepting connections. For TCP, the handshake completed. For UDP, the service responded with data. This is expected for services you intentionally expose.
The host is reachable but no service is listening. TCP sends a RST. For UDP, the host returned an ICMP port-unreachable. The firewall allows traffic but nothing is bound to the port.
No response received (TCP). A firewall or network device is silently dropping packets. The actual state cannot be determined from outside. This is the preferred state for unused ports — reveals nothing to attackers.
UDP-specific. No response received, which could mean the port is open (service didn't reply) or filtered (firewall dropped it). UDP is inherently ambiguous without application-layer probes.
A well-secured server should show only intentionally exposed ports as open, with everything else filtered. Use the IP Location tool to check the security profile of IPs connecting to your services, and the Propagation Checker to verify your DNS points to the correct server before running port scans.