BrowserTools
Advertisement
Home / Networking / TCP Port Check (Ping)

TCP Port Check (Ping)

Check if a TCP port on a public host is open and measure connection latency.

Loading TCP Port Check (Ping)… If nothing happens, please enable JavaScript.

Frequently asked questions

What data does this tool send to your servers?
The hostname (or IP address) and port number you enter are sent to our server, which performs the TCP connection attempt on your behalf. We do not log your IP address alongside individual check requests or store target hostnames for any purpose beyond serving the response. No personally identifying information is retained.
Why does this tool use TCP instead of ICMP like a real ping?
Standard ICMP ping requires raw socket access, which needs elevated (root or administrator) privileges on the operating system. Shared hosting and containerised server environments do not grant these privileges. A TCP connect-based check provides an equivalent 'is it reachable?' answer for most purposes and additionally lets you test service-specific port availability, which ICMP cannot do.
The check times out even though the server is up — what does that mean?
A timeout rather than a 'connection refused' response almost always indicates a firewall or security group silently dropping packets rather than actively refusing the connection. Check whether a firewall rule is blocking the port, whether the server's host-based firewall (iptables, ufw, Windows Firewall) is configured correctly, and whether cloud provider security groups or network ACLs allow inbound traffic on that port from external IPs.
What do the different result statuses mean?
A successful result with a latency reading means the port is open and accepted the TCP handshake. 'Connection refused' means the host is reachable but no service is listening on that port. 'Timeout' means packets are being silently dropped, typically by a firewall. 'Host unreachable' or 'DNS resolution failed' indicates a routing or DNS problem upstream of the port check.
Are there rate limits on how many checks I can run?
Yes. Per-IP rate limits prevent automated abuse and keep the service available for all users. Individual spot-checks and manual troubleshooting sessions are never impacted. Scripted or automated checks at high frequency will be throttled. For continuous uptime monitoring, a dedicated monitoring service like UptimeRobot or Better Uptime is more appropriate.
How does this compare to running 'ping' or 'nc' in a terminal?
The command-line 'ping' sends ICMP and is not port-specific. 'nc -zv hostname port' (netcat) performs the same TCP connect test this tool does, but from your local machine. This tool runs the check from our server, which is useful when you want to know if a host is reachable from the public internet rather than just from your current network. A host might be reachable from your office but blocked by a geo-filter or firewall rule that affects external traffic.
Can I check private or internal IP addresses?
No. Private address ranges (10.x.x.x, 172.16.x.x–172.31.x.x, 192.168.x.x), loopback (127.x.x.x), link-local (169.254.x.x), and cloud metadata endpoints (169.254.169.254) are blocked to prevent abuse and SSRF (Server-Side Request Forgery) attacks. To test internal hosts, run 'nc', 'telnet', or 'Test-NetConnection' directly from within the network where those hosts reside.
Does this tool log the hosts I check for analytics or advertising?
No. Target hostnames and ports are used only to perform the connectivity check and return results. We do not record target hosts against your identity, share check data with third parties, or use it for advertising profiling. Aggregate anonymised metrics (total checks per day) may be tracked for infrastructure capacity planning.
What port numbers are commonly associated with standard services?
Well-known port assignments include: 22 (SSH), 25 and 587 (SMTP), 53 (DNS), 80 (HTTP), 110 (POP3), 143 (IMAP), 443 (HTTPS), 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis), 8080 (HTTP alternate), and 27017 (MongoDB). These assignments are managed by IANA and published in the Service Name and Transport Protocol Port Number Registry. Many services can be configured to listen on non-standard ports for security through obscurity.
Many firewalls block ICMP — does that mean ping is useless?
ICMP ping is indeed blocked by many enterprise firewalls and cloud security groups as a default hardening measure, which means a host can be fully operational and serving web traffic while appearing 'down' to a traditional ping. This is one reason TCP port checks are often more useful in practice — a successful connection to port 443 is definitive proof the service is running and reachable, regardless of ICMP policy. Network engineers generally recommend keeping ICMP unrestricted within internal networks while blocking it at perimeter firewalls.

About TCP Port Check (Ping)

Ping is one of the most fundamental network diagnostic tools, used to determine whether a remote host is reachable and to measure the round-trip time of a network connection. The classic 'ping' command uses ICMP (Internet Control Message Protocol) Echo Request and Echo Reply messages, which travel at the IP layer below TCP and UDP. Network engineers rely on it daily to confirm that routers, servers, and appliances are online, to measure latency baselines, and to detect packet loss indicating a congested or unreliable link. The round-trip time (RTT) reported by ping is one of the key metrics in every network performance investigation.

Sysadmins use ping to quickly verify that a server came back online after a reboot, or to confirm that a firewall rule change didn't inadvertently block connectivity. Developers test API server reachability and latency. Web hosting customers check whether their server IP is responsive after a reported outage. Security teams use port-level reachability checks to verify that firewall rules are enforcing the correct allow and deny policies — confirming that port 22 (SSH) is closed to the internet while port 443 (HTTPS) is open, for example. Even gamers use latency measurements to choose the lowest-latency game server region.

Because standard ICMP ping requires elevated operating system privileges not available in shared hosting environments, this tool performs a TCP three-way handshake connect to the port you specify rather than sending ICMP packets. The result tells you the same essential information — is the host accepting connections? — while also being more operationally useful for service-specific checks: you can test port 80 for HTTP, port 443 for HTTPS, port 25 for SMTP, port 22 for SSH, and so on. The hostname is resolved server-side using public DNS, and private IP ranges (RFC 1918), loopback, and cloud metadata endpoints are blocked to prevent abuse. Latency is measured as the time from the TCP SYN to the completion of the handshake.

When interpreting results, a successful connection with low latency (under 50 ms for nearby servers) indicates the port is open and the service is responding. A 'connection refused' error means the host is reachable but nothing is listening on that port, which is different from a timeout — a timeout usually means a firewall is silently dropping packets rather than actively rejecting them. If you are troubleshooting a service outage, try both the expected port and port 443/80 to distinguish between a service crash and a network-level block. Consistently high latency (above 200 ms) is worth investigating with traceroute for routing anomalies.

From 'Submarine Sonar' to Network Debugging in 40 Years

The ping command was written by Mike Muuss in December 1983 as a debugging tool to investigate strange behaviour on a network he was managing. He named it after the sound a submarine sonar makes when it bounces a sound pulse off an object — the analogy being that a network ping sends a signal and listens for an echo to determine if something is 'out there.' Muuss wrote the original implementation in a single evening, and the program was so useful that it spread rapidly across the ARPANET and eventually became a standard utility on every operating system. Muuss died in a car accident in 2000, never having trademarked or commercialised the tool that bears his sonic metaphor.

ICMP, the protocol that traditional ping uses, was defined in RFC 792 by Jon Postel in September 1981. It operates at the IP layer rather than the transport layer (TCP/UDP), making it the internet's built-in signalling and error-reporting mechanism. ICMP is used for more than ping — it also carries traceroute's TTL-exceeded messages, path MTU discovery signals, and the 'destination unreachable' responses that tell applications their connections have failed. The TTL (Time to Live) field in IP packets was specifically designed to prevent routing loops from causing packets to circulate forever; each router decrements it by one, and ICMP reports when it hits zero.

The transition from ICMP ping to TCP-based reachability checks reflects a broader shift in network philosophy over the decades. Early internet design assumed trusted, cooperative participants and made network infrastructure maximally transparent. Modern networks treat external probes as potential attack vectors, leading to firewalls that block ICMP by default and security groups that only allow traffic on specific application ports. This is why operations teams increasingly measure application-layer reachability — can I complete an HTTPS handshake? — rather than raw network reachability, since a server that responds to application requests is functionally up even if it silently drops all ICMP probes.

Advertisement