Port Checker

Test TCP port reachability and optionally grab the server banner.

Result

No result yet

Enter the inputs above and press Run. Results appear here in a moment.

Monitor this 24/7 — get alerts on the first failure.

Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our Terms.

What is Port Checker?

Port checking answers one specific question: is the service on host:port actually accepting TCP connections from the public internet? Not "is the host up" (that's ping). Not "does the application respond correctly" (that's HTTP Headers). Just: can a TCP three-way handshake complete, and optionally, what does the service say when it greets you?

It's the diagnostic for the gap between "my firewall says it's open" and "my customer says it's closed." Misconfigured cloud security groups, asymmetric routing, MTU issues, services bound to 127.0.0.1 instead of 0.0.0.0, listeners that crashed silently — all of these produce a port that looks open internally but isn't reachable from outside.

How it works

A port check is a single TCP handshake attempt:

1Resolve hostname — If you typed a hostname, DNS lookup gives us the IP. If you typed an IP, we skip.
2Open TCP connection — Standard connect(host, port) syscall over IPv4. SYN → SYN-ACK → ACK. Timeout default 6 seconds. We don't send any application-level bytes during connect.
3Optionally read a banner — Many protocols send a greeting string immediately after the TCP handshake completes — SSH version, SMTP 220 mail.example.com ESMTP, FTP 220 ProFTPD. If the "Read banner" option is on, we read one line (up to 1024 bytes) within the same connect deadline. We never send data to the service; banner reads are read-only and harmless.
4Report result — Open (handshake completed) or Closed (RST received) or Filtered (timeout — no response at all). Connection RTT, optionally the banner string, optionally the protocol guess based on the banner format.

We're deliberately conservative on the banner read: one line, no follow-up commands. Many protocol scanners would try EHLO/HELLO/LIST/etc.; we don't. The goal is non-intrusive verification, not protocol fuzzing.

When you'd use it

"Why can't my customer connect?"

Customer claims they can't reach your service on port 443. Run a port check. If it's open from our prober, the issue is on their end (firewall, ISP block, MTU). If closed/filtered from our prober, your service isn't actually reachable from the public internet and the customer is right.

Cloud security group verification

You just opened TCP port 8443 on an AWS security group. Verify it actually works before telling your team. Port check from our prober immediately after the change shows whether the SG rule is correct, your VPC routing is right, and the service is bound to the correct interface.

Service migration confirmation

Moved a database from old host to new host on the same port. Old host's port check should be closed (service stopped), new host's should be open. Verify both before flipping the connection string in your app.

SSH key rotation / banner verification

After rotating SSH host keys, the SSH banner will change. Port check with banner-read on host:22 shows the new banner string — useful for confirming the rotation took effect on every node in a fleet, without actually attempting an SSH login.

Spot service crashes silently

Your monitoring says "host up," but customers complain. Port check the actual application port — if the host responds to ping but the application port is RSTing or timing out, the service has crashed but the host is healthy. Restart the service and the port check goes green.

Reading the result

Open vs. Closed vs. Filtered

Open = TCP handshake completed (target sent SYN-ACK). Service is listening. Closed = target sent TCP RST in response to our SYN. Host is up, but nothing is listening on that port. Filtered = no response at all within timeout. Firewall is silently dropping the packet, or the host is offline, or there's a network problem en route.

Connection RTT

Time from SYN sent to ACK sent — roughly two network round-trips. Higher than a plain ping RTT because the target's TCP stack also processes the handshake. Useful as a sanity check (sub-200ms for same-continent is normal; multi-second means something is overloaded).

Banner string (if requested)

First line the service sent us after handshake. For SSH it's SSH-2.0-OpenSSH_8.9p1, for SMTP 220 mail.example.com ESMTP, for FTP 220 ProFTPD 1.3.6. The banner reveals the protocol, often the software version, sometimes the hostname the server thinks it has. Useful for security audits (old SSH versions are vulnerabilities), version verification, and protocol identification.

What no banner means

Many services don't send a banner — HTTP servers wait for the client to send a request first. TLS-protected services need a ClientHello before they say anything. A successful port check with no banner just means the protocol is client-initiated; nothing's wrong.

Common pitfalls

"My service is running but port check says Closed"

Three usual suspects: (1) service is bound to 127.0.0.1 instead of 0.0.0.0 — check ss -tln on the host; (2) host firewall is blocking inbound (iptables/nftables/Windows Firewall); (3) cloud security group denies the port. Confirm with a port check from the same host (nc -zv localhost <port>); if that works locally but fails publicly, it's the network not the service.

Filtered status — is that good or bad?

It means the network is silently dropping packets to that port. From a security standpoint, intentional filtering is fine (a closed-by-default firewall). From a "my customers should be able to connect" standpoint, it's broken — you wanted the port open, it's not reachable. The status tells you what you see; what you should do depends on intent.

Banner reads garbage

Some protocols send binary data instead of ASCII greetings (TLS handshake bytes, custom binary protocols). We display the bytes we read; if they look like garbled chars, the protocol just doesn't have a human-readable banner.

Inconsistent results across runs

Could be load-balanced infrastructure — different TCP connections hit different backend nodes, some healthy, some not. Could also be flapping firewall rules or saturated link causing intermittent timeouts. Run multiple times; if the result is stable, trust it; if it flaps, you have a stability problem to investigate at the host/firewall level.

Run Port Checker on every change, not just once.

Get alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 monitors. No card.

Start free

Frequently asked questions

What's the difference between port checking and ping?

Ping uses ICMP and tells you the host responds at the IP level. Port check uses TCP on a specific port and tells you a service is listening there. A host can pass ping but fail every port check (no services running, or all blocked). A host can fail ping but pass port check (ICMP blocked, but services accessible).

Will port checking trigger an alert in my IDS?

A single connection attempt won't typically trigger anything — your IDS is tuned to spot scans (sequential ports from same source, high frequency). One handshake on one port from one IP is below the noise floor of any reasonable IDS.

Can I check UDP ports here?

Not in this tool — UDP doesn't have a handshake, so "is the port open" requires protocol-specific probing (e.g. sending a DNS query to UDP/53 to see if you get a response). The Free Tools UDP check is on the roadmap; in the meantime the in-app toolbox includes UDP probing for paid plans.

Why does port check show Filtered when my host clearly works?

Either your host blocks ICMP (so the network detects loss as silent timeout) or there's something on the path between our prober and your host dropping packets specifically to that port. Try from your own laptop — if it works locally and fails from us, the issue is path-specific.

Is reading a service banner intrusive?

No — we only read what the service voluntarily sends as a greeting after handshake. We send zero bytes of our own; we never attempt to log in or send protocol commands. From the service's logs it looks identical to any legitimate connection that disconnected immediately after handshake.

Can I check ports inside my private network?

Not from the public internet — we're an external prober, we can only see what's exposed publicly. If you need to verify internal connectivity, the in-app toolbox supports private region probers you can deploy in your own VPC for paid plans.

What ports should I check?

The ones your service is supposed to listen on. Common ones: 22 (SSH), 25 (SMTP), 80 (HTTP), 443 (HTTPS), 587 (Mail submission), 993 (IMAPS), 3306 (MySQL — but usually shouldn't be open publicly), 5432 (Postgres — same), 6379 (Redis — also shouldn't), 27017 (MongoDB — same).

Why does the banner sometimes leak software versions I'd rather hide?

Most servers include version info in their banner by default. SSH banners list OpenSSH version, Apache emits its version in headers, MySQL announces its version on connect. Hiding banners is a security hardening practice (set ServerTokens Prod for Apache, SyslogFacility and LogLevel in sshd config). The banner reveals what's running, which simplifies reconnaissance for attackers — for production-facing services, consider minimising it.