This guided TCP port scanner helps you quickly confirm whether a service is reachable on a target host. It’s built for everyday troubleshooting: check a domain or public IP, a private/LAN host, or a small CIDR when you suspect firewall rules, ACLs, security groups, NAT policies, or a downed service.
Use it when you’re answering questions like: “Is SSH (22) reachable?”, “Is HTTPS (443) open?”, or “Why does ping work but the app won’t connect?” The scanner attempts lightweight TCP connects, can optionally grab safe banners (like SSH greetings), and can probe TLS certificates on HTTPS-like ports to help you validate you’re hitting the right endpoint.
Port Scanner (TCP)
Scan a Domain/Public IP, a Private/LAN host, or a small subnet (CIDR).
We attempt TCP connects, can grab lightweight banners (SSH greetings, safe HTTP HEAD /), and probe TLS certificates on HTTPS-like ports.
Use responsibly. Only scan systems you own or are explicitly authorized to test.
Domain/Public IP: example.com or 93.184.216.34 •
Private/LAN: 192.168.1.10 (RFC1918) •
Subnet: 192.168.1.0/28 (up to 32 hosts)
What happens during a scan?
- TCP connect: We attempt to open a TCP connection to each port within your timeout.
- Banner grabbing: If enabled, we read initial greetings (SSH/SMTP/FTP) or send a safe HTTP
HEAD /. - TLS probe: For HTTPS-like ports (443/8443/9443/etc.), we read certificate subject/issuer/SANs and validity dates.
- Performance tips: Lower timeout and moderate concurrency for nearby targets; raise timeout for distant ones.
- Limits: Max 2,000 ports per scan. Subnet scans are capped at 32 hosts to keep the tool snappy.
Recent scans (local)
How to interpret results (open / closed / timeout)
Open usually means a TCP handshake completed and something is listening. Closed typically means the host is reachable but nothing is listening on that port (or it’s actively rejecting). Timeout is the most common troubleshooting signal: it can indicate packet filtering, a security group blocking traffic, upstream ACLs, asymmetric routing, or a host that’s down/unreachable from your scan source.
When not to trust a port scan: some environments rate-limit probes, use tarpits, or only allow access from specific source IPs/VPNs. A “closed” result may also be caused by intermediate devices (NAT/firewalls) returning the reset. For verification, repeat with a narrower port list, adjust timeout, and cross-check from the same network segment as the client.
Real-world workflow: if the port is open but the application still fails, pivot to DNS troubleshooting (wrong hostnames), then validate connectivity/latency with Ping & Latency and path issues with Traceroute & Routing. If you’re troubleshooting SSH specifically, an open port 22 + no banner may point to server-side SSH config, CPU load, or a middlebox doing inspection.
Reminder: only scan systems you own or have explicit permission to test.