--- title: Free Port Checker description: Test TCP port reachability and optionally grab the server banner. canonical: https://watchfor.io/port-checker --- [Back to all free tools](/free-tools) # Port Checker Test TCP port reachability and optionally grab the server banner. [How to use this tool](/blog/how-to-check-if-a-port-is-open) Result No result yet Fill in the form above and run it — the result appears here. Monitor this 24/7 — get alerted when a failure is confirmed. [Start free](/auth/sign-up) 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](/legal/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: - 1 Resolve hostname — If you typed a hostname, DNS lookup gives us the IP. If you typed an IP, we skip. - 2 Open 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. - 3 Optionally 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. - 4 Report result — OPEN (handshake completed) or CLOSED. For a closed port the message underneath says which kind: connection refused (an RST came back, nothing is listening) or no response (the attempt timed out, so a firewall is dropping it or the host is down). You also get the DNS, connect and first-byte times, and the banner line when one was read. 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 (refused or no response) OPEN = TCP handshake completed (target sent SYN-ACK). Service is listening. CLOSED covers two cases, and the message under the badge tells them apart. "Connection refused" = the target sent a TCP RST: the host is up, but nothing is listening on that port. "No response" = nothing came back within the 6-second timeout, what port scanners call filtered: a firewall is silently dropping the packet, the host is offline, or there's a network problem en route. ### Connect time How long the TCP handshake took: about one network round trip plus the target's handshake processing. DNS time (when you gave a hostname) and first-byte time (when a banner was read) are shown next to it. 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 ); if that works locally but fails publicly, it's the network not the service. ### "No response" (filtered) — 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 alerted when an outage is confirmed — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 15 monitors. No card. [Start free](/auth/sign-up) ## 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). There is no free UDP check; a UDP monitor sends a payload you choose and checks the reply. For a time server, use the NTP Server Test. Why does the port check get no response when my host clearly works? Something between our prober and your host is dropping packets to that port: a firewall or security group that only allows certain source addresses, a CDN or proxy that doesn't forward that port, or a path-specific block. Try from your own laptop — if it works locally and fails from us, the issue is path-specific or an allow-list that doesn't include us. 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, and the tool refuses private addresses. For checks inside your own network, the Enterprise plan can run monitors from private locations. 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. ## Related network tools - [PingICMP echo request — round-trip time, jitter, packet loss.](/ping-test) - [TracerouteTrace the network path hop by hop, with packet loss and average latency at each hop (MTR-style).](/traceroute-online) - [Blacklist CheckCheck an IPv4 address against the Spamhaus ZEN, SpamCop and Barracuda blocklists (a domain is checked through the address it resolves to).](/blacklist-checker) - [What Is My IPSee your public IPv4 / IPv6 address, approximate location (city, region, country), timezone and map coordinates — detected instantly from your connection, no signup.](/whats-my-ip) --- Canonical page: https://watchfor.io/port-checker · Site guide: https://watchfor.io/llms.txt