Test TCP port reachability and response time from multiple global nodes
• Target: enter host and port (e.g. example.com:443 or 1.1.1.1:80)
• Common ports: HTTP (80), HTTPS (443), SSH (22), MySQL (3306), Redis (6379)
• Test: verifies the TCP three-way handshake and measures connection setup time
• Nodes: pick specific nodes; defaults to all available nodes
A TCP port test attempts the three-way handshake to a specific port on your target host from multiple probe nodes worldwide, measuring whether the port accepts connections and how long the handshake takes. Unlike ICMP ping, it directly verifies that a specific service port is reachable — giving a more accurate picture of actual service availability.
Common uses include confirming that a web server (80/443), database (3306/5432), or cache (6379) port is reachable from each region, diagnosing security group or firewall rules that block specific ports, and comparing TCP connect latency across regions when choosing a deployment location.
Both perform a TCP handshake to verify port reachability. TCPing repeats the test multiple times to measure latency consistency and packet loss, while the TCP port test is a single-pass reachability check focused on whether the port is open.
A security group, firewall, or access control policy likely permits local access but blocks external probe sources. Check that inbound rules allow traffic from external IPs on that port.
Test the ports your services actually listen on: HTTP (80), HTTPS (443), SSH (22), MySQL (3306), PostgreSQL (5432), Redis (6379). Format is host:port, e.g. example.com:443.
The host is reachable and replied, but no service is listening on that port. This is different from a timeout (where the port is filtered) — refused means the port is actively closed.