Test TCP reachability

“Is that port even reachable?” is one of the most common questions in debugging, and a Telnet client answers it in seconds. Point it at a specific TCP port:

telnet 127.0.0.1 8000

There are three common outcomes, and each one means something different:

Connected to 127.0.0.1.
telnet: Unable to connect to remote host: Connection refused
telnet: Unable to connect to remote host: Operation timed out

Let’s take them one at a time.

What success proves

A successful connection proves four things. The client resolved the address, reached the host, completed a TCP handshake, and found something listening on that path.

That is a lot from one command. If you are debugging “the app can’t reach the database”, a Connected line eliminates DNS, routing, and firewall in one test. You can stop looking at the network and start looking at the application.

It does not prove that the service is healthy. The application may speak the wrong protocol, reject the next command, return bad data, or wait forever. Something answered the handshake. You know nothing yet about what.

What failure tells you

A refusal usually means the host is reachable but nothing accepted that port. The machine actively answered “no”. Typical causes: the service is not running, it crashed, or it listens on a different port or address. Check the server side with ss -tlnp and compare what is actually bound against what you assumed.

A timeout points somewhere else: routing, firewall, a wrong address, or silent packet loss. Your packets got no answer at all. From the client alone you cannot tell whether they never arrived or the replies were dropped. Firewalls that silently discard packets produce exactly this symptom, and it takes noticeably longer to appear than a refusal. Refusals come back in milliseconds. Timeouts make you wait.

A subtle trap: a refusal from 127.0.0.1 when the service is up sometimes means it bound only to another address. A server listening on 192.168.1.5:8000 refuses loopback connections. The port is fine. The address was wrong.

Preserve the evidence

Write down the exact result before you change anything. “Refused” versus “timed out” sends you down entirely different paths. If you restart three things before reading the message carefully, you have lost the evidence, and you will end up testing the same things twice.