A port checker tests whether one public TCP port accepts a connection. Enter a hostname or IP address to see whether the port is open, closed, or timed out and identify its likely service.
Public TCP target
Enter a public host and TCP port. Private, local, reserved, and multicast addresses are blocked.
Port status
Run a check to see whether a public TCP port accepts connections.
Ready for a public host
Try tornic.dev on port 443, or enter a public server you own or are authorized to test.
Use a domain, public IPv4 address, or public IPv6 address that you own or are authorized to test.
Enter a port from 1 to 65535 or choose a common service preset such as HTTPS on 443.
Tornic resolves the host, blocks non-public targets, and attempts one short TCP connection.
Open means accepted, closed means refused, and timed out or filtered means no conclusive TCP response arrived.
Forward the same external and internal TCP port to the correct device, then confirm the service is listening before checking again.
Allow only the required source ranges and ports. An open port is reachable, but it still needs authentication, patching, and monitoring.
This checker performs a TCP handshake. DNS, gaming, streaming, and VPN services may use UDP and need protocol-aware testing.
A port checker attempts a TCP connection to one public host and port, then reports whether the connection was accepted, refused, or timed out.
An open TCP port means a service accepted the connection from the checker. It does not prove the service is secure, authenticated, or configured correctly.
A timeout can mean a firewall silently dropped the connection, the route is unavailable, the host is offline, or the service is filtering this checker.
No. UDP has no TCP-style handshake, so a generic connection attempt cannot reliably distinguish an open UDP port from a filtered one. Use a protocol-specific UDP test instead.
No. For safety, the checker blocks localhost, private, link-local, reserved, documentation, and multicast addresses. Run a local network tool from inside your own network instead.
Building reliable developer workflows? See how Tornic makes AI coding automation deterministic.