Port Check (TCP)

Test whether a TCP port on a remote host is open and accepting connections.

TL;DR

A port check opens a TCP connection to a specific port on a target host and reports whether the connection succeeded, was refused, or timed out. It tells you whether a service is reachable from the network, without inspecting what that service does.

What it is

TCP services listen on numbered ports. A web server listens on port 80 or 443; SSH on 22; mail submission on 587; PostgreSQL on 5432. A port check asks the simplest question that matters in connectivity troubleshooting: "if I try to open a TCP connection to this host on this port, what happens?"

The answer falls into one of three states:

• Open: the host accepted the connection
• Closed: the host actively refused it (no service listening on that port)
• Filtered: a firewall dropped the probe with no response, so it timed out

Port checks operate at the transport layer. They do not validate that the listening service is healthy, only that something is there to answer.

How it works

TCP connections are established via a three-way handshake:

1. Client sends SYN to the target on the chosen port
2. If a service is listening, target replies with SYN-ACK
3. Client completes the handshake with ACK

A port check uses the first two steps and interprets the response:

• SYN-ACK returned: port is open
• RST returned: port is closed — host is reachable, no service bound to that port
• Nothing back within timeout: port is filtered — a firewall is silently dropping the probe
• ICMP Unreachable returned: port is filtered, firewall politely announcing the block

Common ports

When to use it

• Confirm a service is exposed where you expect it
• Diagnose firewall, security group, or NACL changes
• Verify port forwarding or NAT rules
• Test reachability from multiple geographic regions
• Validate a load balancer is forwarding to backends
• Spot misconfigured services listening on the wrong interface
• Check whether a host that does not respond to ping is still reachable on application ports

Running it on networktoolkit.io

Select port_check, enter a hostname or IP, and provide one or more ports (e.g. 80,443 or 22,80,443,3306). The test runs from each of our distributed workers and reports per-port, per-worker results. Sample output:

Target: example.com (93.184.216.34)
Worker: lhr-01 (London)

Port    Protocol  State      Time      Notes
22      TCP       filtered   5000 ms   No response (timeout)
80      TCP       open       12 ms     SYN-ACK received
443     TCP       open       12 ms     SYN-ACK received
3306    TCP       closed     14 ms     RST received

Summary: 2 open, 1 closed, 1 filtered

Reading the results

Common scenarios

Limitations & gotchas

• Port open does not mean service healthy. The listener answered, but the application may be returning errors or timing out at the application layer. Use HTTP check to validate HTTP services and SSL check for TLS endpoints.
• TCP only. UDP port checks behave very differently because UDP gives no inherent acknowledgement. UDP "open" looks identical to UDP "filtered" without protocol-specific probes.
• NAT and load balancers can make port states change depending on which backend handles the connection.
• Rate limiting and SYN flood protections can produce false "filtered" results during heavy use.
• Anycast destinations answer from different physical machines per region; results can legitimately differ across workers.

Security & privacy notes

Port checking is a standard, legitimate diagnostic — and also the first stage of network reconnaissance. It shows up in IDS logs. For your own infrastructure, the rule of thumb is: only the ports you mean to expose should be open. Common exposure mistakes worth checking for:

• Database ports (3306, 5432, 27017, 6379) reachable from the internet
• Management interfaces (3389 RDP, 5900 VNC, 22 SSH) exposed without a bastion or VPN
• Development services (8080, 9000) left open on production hosts
• Legacy protocols (21 FTP, 23 Telnet) still bound

Standards & references

• RFC 9293 — Transmission Control Protocol (current TCP specification)
• RFC 6335 — IANA Procedures for the Service Name and Transport Protocol Port Number Registry
• IANA Service Name and Port Number Registry

FAQ

What is the difference between open, closed, and filtered?

Open means the host answered with SYN-ACK; a service is listening. Closed means the host answered with RST; no service is listening but the host is reachable. Filtered means nothing came back; a firewall is silently dropping the probe.

Can a port check tell me if my website is working?

Only partly. It tells you whether the web port (usually 443) is reachable. It does not tell you whether the web server returns valid responses. For that, use http_check.

Why is port 22 filtered but I can SSH in fine?

Either the firewall allows SSH only from specific source IPs (and the worker's IP is not on the allowlist), or rate limiting and fail2ban-style protections are temporarily blocking probes.

Is it legal to port-scan another network?

Single-port checks against your own infrastructure are uncontroversial. Broader scans against third-party networks may be restricted by local law and acceptable-use policies. Always have explicit authorisation before scanning systems you do not own.

Does port checking check UDP too?

This tool checks TCP. UDP port checks are protocol-specific and far less reliable because UDP itself gives no inherent reply on an open port.