A TCP service can appear unreachable when the application is down, when the service is bound to a different address, or when a firewall is blocking the path. Netcat gives a socket-level test that separates an accepted TCP connection from a refused or unanswered port before protocol-specific debugging starts.
OpenBSD Netcat uses -z for zero-I/O scanning, so it opens the connection and exits without sending application data. Adding -v prints the connection result, and -w keeps silent paths from hanging the terminal indefinitely.
The examples use OpenBSD Netcat on Ubuntu 26.04 against loopback test ports. Replace 127.0.0.1 and the sample port with the service endpoint being checked, and treat success as proof of a TCP handshake only; HTTP, TLS, database authentication, and application responses still need a protocol-aware test.
$ nc -vz -w 2 127.0.0.1 9042 Connection to 127.0.0.1 9042 port [tcp/*] succeeded!
-z tests the TCP connection without sending payload, -v prints the result, and -w 2 limits the connection attempt to two seconds.
$ nc -vz -w 2 127.0.0.1 9043 nc: connect to 127.0.0.1 port 9043 (tcp) failed: Connection refused
A timeout instead of Connection refused usually means the route, firewall, address, or service binding did not answer within the timeout window.
$ nc -vz -w 2 service.example.net 443
A local success on 127.0.0.1 does not prove that another host can cross routing, firewall, load balancer, or security-group boundaries. Expect the same succeeded line when the remote path accepts the TCP connection.