Networking · 4 steps

Cannot reach a port

Work outwards from the process to the socket to the firewall. The distinction between refused and timed out narrows it enormously.

Every step

Read the failure mode precisely

Refused and timed out are different diagnoses. Refused means a machine answered with an RST — something is reachable. Timed out means nothing answered at all, which points at a firewall silently dropping packets or a route that goes nowhere.

$ nc -vz <host> <port>

$ curl -sv --connect-timeout 5 telnet://<host>:<port>

$ time nc -vz <host> <port> # a ~5s hang before failure is a drop, not a refusal

Look for: The exact wording. "Connection refused" is immediate; "Connection timed out" takes seconds and then gives up.

Check what is listening, and on which address

A service bound to 127.0.0.1 refuses every connection from outside the machine while looking perfectly healthy in its own logs. This is the single most common cause of a refused connection.

$ ss -tlnp | grep <port>

$ ss -tlnp # everything listening

$ lsof -nP -iTCP:<port> -sTCP:LISTEN

Look for: The Local Address column. `127.0.0.1:8080` is loopback only. `0.0.0.0:8080` or `*:8080` is every interface. `[::]:8080` is IPv6, which may or may not also cover IPv4.

Test the path rather than the service

A silent drop is a firewall’s signature. Establishing where in the path the packets stop tells you whose firewall to argue with.

$ traceroute -T -p <port> <host>

$ ping -c 3 <host> # ICMP may be blocked even when TCP is fine

$ curl -sv --connect-timeout 5 https://<host>:<port> 2>&1 | head -20

Look for: How far the TCP trace gets before it stops. Compare with an ICMP ping — they can disagree, and TCP is the one that matters.

Check the host firewall and the socket backlog

Packets can arrive at the machine and still be dropped by its own firewall, or accepted into a backlog that the application never drains. Both look like a hang from outside.

$ iptables -L INPUT -n -v --line-numbers

$ nft list ruleset 2>/dev/null | head -40

$ ss -tln | grep <port> # Recv-Q against Send-Q on a listening socket is the accept backlog

$ netstat -s | grep -iE "listen|overflow|drop"

Look for: Non-zero packet counts on a DROP rule, and "listen queue overflowed" in the netstat statistics.