TCP port checker: open, refused or timed out?

Understand TCP port-check results, separate reachability from application health, and diagnose firewall or listener problems one step at a time.

Network

Open Port Checker →

Choose the service and port

Use Port Checker with a public domain or IP address and a TCP port from 1 to 65535. Choose the actual port configured for the service; a conventional number does not guarantee that a service runs there. Test systems you administer or are authorized to diagnose. This check makes a TCP connection; it does not test UDP or scan an entire subnet.

Interpret an accepted or refused connection

An open result establishes that a TCP connection was accepted from the test location. It does not verify a website, database query or user login. A refusal commonly means no listener accepted the connection or an intervening device actively rejected it. Review the returned error and verify the service binding, because listening only on localhost or only on IPv4 changes what outside clients can reach.

Investigate a timeout in layers

A timeout cannot identify a firewall rule by itself. Start by confirming the hostname resolves to the expected public address. Then check the application listener, host firewall, cloud network policy and any router port forwarding. A working internal test and a failing external test narrow the investigation but do not pinpoint a device. Avoid opening unrelated ports while troubleshooting one service.

Follow a successful connection with a protocol check

For a web service, run HTTP Status after TCP succeeds and inspect SSL Certificate for TLS errors. If IPv4 works but IPv6 fails, compare both DNS records and listener configuration; IPv4 port forwarding does not configure IPv6 access. Save the exact address, port and time so later checks measure the same endpoint.

Worked example

Illustrative example — not a live test
TCP 443: connection accepted
HTTPS: certificate hostname mismatch
Conclusion: the port is reachable, but HTTPS needs correction.

What to check next

  1. Confirm the target address and intended TCP port.
  2. Check listener and firewall configuration if the connection fails.
  3. Test the application protocol once TCP succeeds.

Common questions

Does this tool check UDP ports?

No. A TCP connection result does not establish UDP availability on the same port number.

Can a port be open while a website is broken?

Yes. TLS negotiation, HTTP routing or the application can fail after the TCP connection succeeds.

References

TCP connection establishment: RFC 9293