Diagnostic · TCP probe

Port checker

Verify whether a TCP port on a public IP is open, closed, or firewall-filtered. Useful for confirming port-forwards, validating cloud-firewall rules, and testing a freshly-deployed service.

Self-scan mode

We detected your public IP as 216.73.216.231. Scanning your own IP unlocks any port (up to 10 per check) — no allowlist applies because you could trivially scan yourself anyway.

Scan my IP →
No private / loopback / link-local targets · 3s timeout per port

Allowed ports

The checker covers ~26 well-known service ports. For full-range scanning, use nmap -p- your-host from a machine you control.

  • 21 FTP
  • 22 SSH
  • 23 Telnet
  • 25 SMTP
  • 53 DNS
  • 80 HTTP
  • 110 POP3
  • 143 IMAP
  • 443 HTTPS
  • 465 SMTPS
  • 587 SMTP submission
  • 993 IMAPS
  • 995 POP3S
  • 1194 OpenVPN
  • 3306 MySQL
  • 3389 RDP
  • 5432 PostgreSQL
  • 5900 VNC
  • 6379 Redis
  • 8080 HTTP alt
  • 8443 HTTPS alt
  • 9000 PHP-FPM / SonarQube
  • 9200 Elasticsearch
  • 25565 Minecraft
  • 27015 Source / Steam
  • 51820 WireGuard (UDP — only TCP tested)

What "open / closed / filtered" actually mean

Three TCP outcomes you can see when probing a port from the outside:

  • Open — the target accepted the connection (TCP three-way handshake completed). Something is listening on that port and the firewall isn't in the way.
  • Closed — the target answered with TCP RST. The IP is reachable and the firewall let our SYN through, but no process is bound to that port. Fix: start your service, or check that it's actually listening on the IP you expect (often it's bound to 127.0.0.1 only by default).
  • Filtered — we got nothing back within the timeout. A firewall (host-level, network-level, or cloud-provider security group) is dropping the SYN silently. The user-visible symptom is the same as "closed," but the fix is different: open the firewall rule or update the security group.

What to use this for

  • Confirming a port-forward. You set up port forwarding on your home router (see our port-forwarding explainer). Use this tool from outside your LAN to verify the public port is actually reaching your internal service.
  • Validating a cloud firewall rule. You opened TCP 5432 in your AWS security group for a PostgreSQL service. Verify it's reachable.
  • Testing a fresh deployment. The service started; the firewall is configured; the load balancer claims healthy. Verify from the public internet that all three are aligned.
  • Debugging "the site won't load." If port 443 shows filtered from the outside, the problem is the firewall, not your TLS config.

What this is NOT

  • Not a port scanner. We allowlist ~25 well-known service ports. For sweeping a target, use nmap from a host you own: nmap -sS -p- target.example.com.
  • Not a vulnerability scanner. "Open" tells you the port accepts connections; it says nothing about whether the service is hardened, authenticated, or up-to-date. Run the actual service-specific probes (Lynis, Nessus, OpenVAS) for security posture.
  • Not a tool for probing other people's infrastructure. Use this on IPs you own or have explicit authorization to probe. Network scanning without permission is illegal in many jurisdictions.
  • Not a UDP probe. TCP only. UDP requires service-specific payloads to get a reliable reply.

Abuse hardening (so you know what we built)

Web-based scanners are tempting targets for misuse. We've added several guardrails:

  • Port allowlist. Only the ~25 well-known service ports listed above are checkable. Arbitrary port numbers are rejected at the API.
  • SSRF defense. Targets in any private, loopback, link-local, CGNAT, or IPv6 ULA range are rejected. The checker can't be used to probe internal networks reachable from our datacenter.
  • Per-request port limit. Maximum 3 ports per request.
  • Short timeouts. 3 seconds per probe to bound resource use.
  • Rate limiting. Our middleware throttles requests per source IP (same limits as the rest of /api/*).

Adjacent tools