Half the tickets that start with “the service isn’t reachable” are actually questions about reachability from outside the network the requester is sitting on. Their laptop says the port is closed; your bastion says the same port is open; the client’s monitoring says it’s intermittent. Until somebody runs the probe from a known location on the public internet, the conversation goes in circles. That is what PortJar’s TCP Port Check is for — one fast probe from a neutral vantage point, with a banner attached when the service speaks first.
What the tool does
TCP Port Check opens a TCP connection from a PortJar server to a host and port you specify, then reports one of three outcomes: open, closed, or filtered. Open means the three-way handshake completed and a service is listening. Closed means the host answered with a TCP RST — somebody’s home, but nothing is bound to that port. Filtered means no answer came back at all within the timeout, which almost always points to a firewall silently dropping the packet rather than a host that simply doesn’t exist.
When the service on the other side sends data immediately after the handshake — SMTP, FTP, SSH, IRC, MySQL, and a handful of others all do this — the banner is captured and returned alongside the open/closed verdict. That single line of text is often more useful than the verdict itself, because it confirms not just that something is listening on the port but exactly which version of which daemon. UDP and raw packet scans are out of scope.
How to use it
Open portjar.com/tools/port-check, enter the hostname or IP, and the port number. Hit run. The probe completes in a couple of seconds for open or closed ports; filtered results take the full timeout, which is the most reliable signal that a firewall is involved. The URL is stateless — paste it into a ticket so the next person sees the same probe.
When you’d reach for it
- Confirming a firewall rule actually took effect. A new inbound rule was added in the cloud console, but you want a third-party verdict from outside the VPC before you tell a client the port is open. Asking your own bastion proves nothing — your bastion is likely inside the same trust zone.
- Settling an “is the SMTP relay listening on 587?” debate. The banner grab shows you the exact daemon and version answering on port 587, which immediately tells you whether the wrong service is bound or the right one came up with a broken config.
- Diagnosing a “container is running but unreachable” report. Run the probe against the host’s public IP and the published port. If it returns filtered, the host firewall or security group is the problem. If closed, the port isn’t bound where you think it is — most commonly because EXPOSE was confused with
-p. - Verifying a DNAT or load-balancer cutover. After repointing a public endpoint to a new backend, probe the public port to confirm the new path answers before any client tries it.
- Spot-checking a “we opened port 443 for you” claim from a client’s IT team. The probe takes five seconds and resolves the dispute without anyone screen-sharing.
What to make of the output
Treat open as a strong positive signal — something is listening and accepting connections from the public internet. If you got a banner, even better; the banner is the definitive answer to “what’s actually running there.” A banner from nginx/1.18.0 on port 25 is its own kind of finding worth investigating.
Treat closed as a strong negative signal at the application layer — the host is reachable, but nothing is bound to that port. Look at the service unit, the container’s port mapping, or the load-balancer target group.
Treat filtered as a firewall verdict, not a service verdict. Somewhere between PortJar and the destination, the SYN was dropped silently. Common culprits: cloud security groups, an upstream provider’s ingress firewall, a host-level iptables rule, or the destination simply not existing. Pair the probe with PortJar’s guide on connection-timed-out vs. connection-refused for the next step.
A surprising open or closed result on a port the client claims is firewalled is itself a finding — security groups drift, and “we configured that two years ago” is not the same as “it is configured today.”
Stack Harbor uses TCP Port Check as a routine verification step during cutovers and firewall changes we run as part of Monitoring and Support.