Linux Networking Commands Around One Failed Connection
Use a short sequence of Linux commands to separate name resolution, routing, listening sockets and an HTTP response.
A failed HTTP request can send you toward DNS, routing, a firewall, a listening socket, or the application. Running every networking command you know produces output, but little direction. Run a command only when its result can change the next question.
Imagine a client trying to open http://service.example:18081/ on a network you administer. Replace the example hostname and IP below with your real target. Keep the client machine fixed throughout the investigation; a test from the server itself answers a different question.
1. Resolve the name you actually requested
On a Linux client using glibc, ask the system’s configured name-service lookup for IPv4 results:
getent ahostsv4 service.exampleThe getent(1) manual describes ahostsv4 as a lookup through getaddrinfo restricted to IPv4. Record the address or addresses returned. An empty result moves the investigation to name service; it does not prove the target port is closed. If the application uses IPv6, inspect that family separately rather than assuming the IPv4 result explains it.
2. Ask which route the client would select
Choose the specific IP address you intend to test:
ip route get SERVER_IPThis queries the route the Linux kernel would select for that destination, including its outgoing interface and often a source address. The ip-route(8) manual notes that it is a route lookup, not a packet sent to the server. A route exists does not prove that firewalls or the remote host will permit the connection. If the client is inside a container, run the command there, not only on the host.
3. On the server, inspect the listener
On the intended Linux server, use:
ss -ltnFind the port and read its local address. 127.0.0.1:18081 is different from a listener on the server’s LAN address or 0.0.0.0:18081. The ss(8) manual defines -l as listening sockets, -t as TCP, and -n as numeric output. The loopback vs all-interfaces experiment shows why the difference matters. If no listener matches, investigate the service process and its logs before editing network policy.
4. Retry HTTP from the original client
curl -v --connect-timeout 3 http://service.example:18081/The curl manual defines --connect-timeout for the connection phase; -v reveals which address curl attempted and the response exchange. Record whether name resolution, TCP connection and HTTP response each happened. If TCP connects and the server returns an unexpected status or body, the network path has done its part for that attempt. Look at the application next.
This sequence is a command ladder, not a claim that every failure needs all four commands. Stop at the first unresolved layer. If the error is a refusal or timeout, the connection-error guide explains what each observation permits you to infer without guessing which device is responsible.