What does "open" actually mean here?

**Open** means the **TCP three-way handshake completed**: we sent SYN, the server replied SYN-ACK, we replied ACK. That is the proof that **something is listening** and the firewall lets the packet through. It does **not** mean the service speaks the protocol you think. Port 443 could be open but serving plain HTTP, or open but not running TLS yet. It just means the door is unlocked.

Open vs closed vs filtered, what is the practical difference?

**Open**: server accepted the handshake, a service is listening. **Closed**: server replied with TCP RST (ECONNREFUSED), meaning the host is up but **no process is bound** to that port. **Filtered**: we got **no reply at all** within 4 seconds, almost always a firewall doing DROP instead of REJECT. Closed tells you "host is fine, service is down". Filtered tells you "a firewall is in the way" (or the host is completely off-grid).

Why only one port? Why not a full scan?

A full port scan is **30,000+ probes** against one host. From a shared cloud IP, that gets the IP blacklisted in hours and is also illegal in many jurisdictions without written permission. This tool is for **operational debugging** ("is my one service up?"), not for reconnaissance. If you legitimately need a full scan, run **nmap** from your own machine against your own network.

Why do some firewalls DROP instead of REJECT?

**DROP** (silently discard) makes the host look offline. **REJECT** (send RST or ICMP unreachable) tells the attacker "I am here but nothing listens". Security teams prefer DROP for **public-facing services** because it slows down port scanners. Every closed port takes a full timeout instead of a millisecond. The trade-off: legitimate connectivity tests look indistinguishable from a network outage.

TCP vs UDP, why does this tool only check TCP?

**TCP** is connection-oriented: there is a handshake, a clear "accepted" or "refused" signal. **UDP** is fire-and-forget: you send a packet, nobody is required to reply. Checking a UDP port like 53 (DNS) or 123 (NTP) requires **speaking the actual protocol** because "silence" can mean either "open" or "filtered". For HTTP-over-QUIC (UDP 443), use a real HTTP/3 client. This tool stays TCP-only on purpose.

Quick cheatsheet, what runs on which port by default?

The classics: **22** SSH, **25** SMTP server-to-server, **53** DNS, **80** HTTP, **110** POP3, **143** IMAP, **443** HTTPS, **465** SMTPS, **587** SMTP submission, **993** IMAPS, **995** POP3S. Databases: **3306** MySQL/MariaDB, **5432** PostgreSQL, **6379** Redis, **27017** MongoDB, **9200** Elasticsearch. Admin: **3389** RDP, **5900** VNC, **8080**/**8443** dev HTTP servers. Full list at IANA, but these cover 95% of real-world checks.

How do I run a real scan from my own network?

Install **nmap** (`brew install nmap`, `apt install nmap`, `choco install nmap`). For a full TCP scan of one host: `nmap -p- -sV your-server.com`. For the 1000 most common ports: `nmap -sV your-server.com`. For UDP: `nmap -sU -p 53,123 your-server.com` (slow, needs root). **Always have written permission** before scanning anything you do not own. Many providers (AWS, GCP, Hetzner) require advance notice even for your own resources.

My port check fails but the service definitely works from inside the network. Why?

Almost always **one of four things**: (1) The service is bound to `127.0.0.1` instead of `0.0.0.0`, fix the bind address. (2) A cloud-level firewall (AWS Security Group, GCP firewall rule, Hetzner Cloud Firewall) blocks public ingress. (3) The host firewall (`ufw`, `firewalld`, Windows Firewall) rejects the port. (4) NAT or port forwarding on the router does not forward the public port to the internal host. The single-port check tells you "the outside world cannot reach this", and the next step is to walk each layer.

Is it OK to scan other people's servers with this tool?

**No.** Even one TCP connection to a stranger's port can violate the **Computer Fraud and Abuse Act** (USA), **Computer Misuse Act** (UK), and similar laws across the EU. Many ISP terms of service explicitly ban port scanning. The aggressive **30 checks per hour per IP** rate limit is here precisely to make this tool useful for legitimate operations work and useless for anything else. Only check **your own** infrastructure, or hosts you have **written permission** to probe.

YourDevToolsPro

Port Reachability Check

Check whether a single TCP port is reachable from the internet. Three outcomes: open, closed, or filtered by a firewall. Captures the server banner (SSH, SMTP, FTP) if it sends one.

LiveRuns in your browser

Open one TCP connection to a public host and see what answers. Open, closed, or quietly dropped by a firewall? Captures the server banner too if one is sent.

Your request goes to our server, which opens one TCP connection to the host you provided. We do not store any check history. Limit of 30 checks per hour per IP.

What does the port reachability check do?

Type a host (domain or public IP) and a TCP port, click Check, and our server opens one TCP connection to that address from a public IP. You get back one of three answers: open (something is listening), closed (the server actively rejected with RST), or filtered (the packet vanished, almost always a firewall).

This is not a port scanner. It checks one port at a time and is rate-limited to 30 checks per hour per IP on purpose. It is the right tool when you just rebooted a service and want to confirm the firewall opened back up, when SMTP isn't accepting mail and you want to rule out the network layer, or when a customer says "your API is unreachable" and you want a second opinion from a different network.

If the server greets the client on connect (SSH, SMTP, FTP, POP3, IMAP, Redis often do), the first line of the banner is captured and shown. Banners are useful: they reveal the software, version, and sometimes the OS.

How to use it

Type a host: a domain like `mail.example.com` or a public IP like `93.184.216.34`. No scheme, no path. Private addresses (`192.168.x`, `10.x`, `127.x`) are blocked on purpose.
Pick a port from the preset chips (22 SSH, 443 HTTPS, 25 SMTP, etc.) or type any number from 1 to 65535.
Click Check. The probe takes up to 5 seconds: 4 s for the TCP handshake, 1 s waiting for an optional banner.
Read the status pill: green = open, red = closed, amber = filtered, grey = error. Each comes with a one-line explanation.
If the server sent a banner, read it. SSH shows the version, SMTP shows the MTA name, FTP shows the daemon. This is normal and usually safe to expose.

When this is useful

Five everyday situations where a single-port check beats SSHing into the box:

Did the firewall actually open? You added a rule in AWS Security Groups, Cloudflare, or ufw and want a quick confirmation from outside.
Is SMTP really listening? Your mail server claims port 25 is up but mail isn't flowing. Check from outside, because many ISPs and clouds block outbound 25 by default.
Service crashed silently. Your monitoring missed it. A 2-second check tells you whether Postgres, Redis, or MySQL is reachable at all.
Customer says "your API is down". Their network might be the problem. Run the same check from a neutral location and compare.
Post-migration smoke test. You moved a service to a new host. Confirm SSH (22), HTTPS (443), and any custom ports came up before flipping DNS.

Questions and answers

A port is a numbered door on a server. The IP address takes you to the building, the port number takes you to a specific apartment. 80 is the door HTTP uses, 443 is HTTPS, 22 is SSH, 25 is email between servers, 3306 is MySQL. Each listening service binds to one port. When you connect, your laptop tells the server which door you want to knock on.

Related tools

DNS Lookup

Check a domain's DNS records (A, AAAA, MX, TXT, CNAME, NS, SOA, CAA), see propagation across 8 public resolvers and surface the server's ASN/ISP, no terminal required.

SSL Certificate Inspector

Type a domain, get the full SSL certificate chain: days to expiry, public key, signature, SANs, fingerprints, security warnings.

HTTP Headers Inspector

Paste a URL, see every response header, the full redirect chain with per-hop timing, and an A-F security score with concrete fixes.

IPv6 Readiness Check

See how well your domain is ready for IPv6. Five signals (AAAA, www, MX, NS, TLS over v6), a 0-100 score, an A-F letter grade and a clear list of what to fix.

Cloud Provider / CDN Detector

Type a domain, find out who hosts it, which CDN sits in front, who runs its DNS, and whether a WAF protects it. Four independent sources, a confidence label on every result.

Port Reachability Check

Check whether a single TCP port is reachable from the internet. Three outcomes: open, closed, or filtered by a firewall. Captures the server banner (SSH, SMTP, FTP) if it sends one.

LiveRuns in your browser

Port Reachability Check

Open one TCP connection to a public host and see what answers. Open, closed, or quietly dropped by a firewall? Captures the server banner too if one is sent.

Your request goes to our server, which opens one TCP connection to the host you provided. We do not store any check history. Limit of 30 checks per hour per IP.

What does the port reachability check do?

How to use it

Type a host: a domain like `mail.example.com` or a public IP like `93.184.216.34`. No scheme, no path. Private addresses (`192.168.x`, `10.x`, `127.x`) are blocked on purpose.
Pick a port from the preset chips (22 SSH, 443 HTTPS, 25 SMTP, etc.) or type any number from 1 to 65535.
Click Check. The probe takes up to 5 seconds: 4 s for the TCP handshake, 1 s waiting for an optional banner.
Read the status pill: green = open, red = closed, amber = filtered, grey = error. Each comes with a one-line explanation.
If the server sent a banner, read it. SSH shows the version, SMTP shows the MTA name, FTP shows the daemon. This is normal and usually safe to expose.

When this is useful

Five everyday situations where a single-port check beats SSHing into the box:

Did the firewall actually open? You added a rule in AWS Security Groups, Cloudflare, or ufw and want a quick confirmation from outside.
Is SMTP really listening? Your mail server claims port 25 is up but mail isn't flowing. Check from outside, because many ISPs and clouds block outbound 25 by default.
Service crashed silently. Your monitoring missed it. A 2-second check tells you whether Postgres, Redis, or MySQL is reachable at all.
Customer says "your API is down". Their network might be the problem. Run the same check from a neutral location and compare.
Post-migration smoke test. You moved a service to a new host. Confirm SSH (22), HTTPS (443), and any custom ports came up before flipping DNS.