How to check whether a public TCP port is open
A useful port test answers a narrow question: can a client at this location establish a TCP connection to this public host and port now?
What “open” means
TCP begins with a handshake. If the target accepts it, the port is reachable from the test source. That does not prove the application protocol is healthy, correctly configured or safe. A web server might accept TCP on port 443 and then fail TLS negotiation. Conversely, a closed result does not prove that no service is running; a firewall, router or cloud rule may be blocking the route before the connection reaches it.
Interpret the three common outcomes
- Connected/open: the handshake completed. Continue with a protocol-specific health check.
- Connection refused: the host actively rejected it, often because nothing is listening or a firewall sent a rejection.
- Timed out: no useful response arrived before the limit. Packet filtering, routing failure or an unavailable host can all look this way.
These outcomes are observations, not permanent properties. Load balancers, source-IP rules and transient network conditions can produce different results from different locations.
Check the service locally first
On the server, confirm that the process is running and listening on the intended port. Pay attention to the
bind address: a service listening only on 127.0.0.1 accepts local connections but not traffic on
the network interface. Confirm IPv4 versus IPv6 as well. Then test the application locally using its actual
protocol before investigating the perimeter network.
Follow the connection path
- Verify the hostname resolves to the expected public IP address.
- Check the host firewall for an inbound rule covering the correct port, protocol and source.
- For a private host, verify router NAT/port forwarding points to its current internal address.
- Check cloud security groups, network ACLs, provider firewalls and load-balancer listeners.
- Test from outside the destination network to avoid NAT loopback giving a misleading result.
- After TCP connects, run a protocol-specific request and inspect server logs.
Frequent configuration mistakes
- Opening UDP when the service uses TCP, or the reverse.
- Forwarding a public port to the wrong internal port or stale DHCP address.
- Allowing traffic in the cloud firewall but blocking it on the operating system.
- Testing a domain whose DNS still points to an old server or only has an unexpected IPv6 record.
- Assuming an ISP permits unsolicited inbound traffic or provides a dedicated public address.
Security guidance
Expose only services that are designed for internet access. Restrict administrative ports by source IP or a VPN, require strong authentication, patch the service and log failed access. An open-port checker should be used only on systems you own or are authorized to test. Broad or repeated scanning can violate acceptable-use rules and trigger defensive controls.
Why two tests can disagree
The GenericTools.dev Port Checker connects from its server, so it measures the route from that server to the destination. A corporate office, mobile carrier or another region can see a different route or source-IP policy. Record the test location, hostname, resolved IP, time and exact error when comparing results.