Linux networking: find how far the request got

The browser shows no practice page. From that window alone, several quite different stories look alike: the name led somewhere unexpected, no server was listening, or a server answered but did not have the page.

We can separate those stories inside the disposable Ubuntu VM, using the synthetic Dispatch service. Complete Services and logs if needed, then run systemctl --user start dispatch-lab.service. Keep every check in this lesson inside the guest where that service runs.

Reach the guest without asking for a name

curl -i --max-time 3 http://127.0.0.1:8080/
ss -ltn 'sport = :8080'

The numeric address 127.0.0.1 sends the request back into this guest. It is a loopback address, so there is no name to look up first. The URL chooses port 8080 and asks for /, the root resource. A successful reply means this request reached something speaking HTTP at that address and port.

The ss command lets you look for the listener that could receive it. Its -ltn flags select listening TCP sockets and display numeric addresses. A socket is a communication endpoint; here the important details are where it listens and on which port. A listener at 127.0.0.1:8080 receives local traffic, not requests arriving on the VM’s other interfaces. When your permissions allow, adding -p shows process details.

If the selected socket list is empty, you have learned something about that listener, not the entire network. And if curl cannot connect, there may be no HTTP status at all. A 404 means something else: a server did answer, but could not find the requested resource.

Let localhost choose the address

getent ahostsv4 localhost
curl -i --max-time 3 http://localhost:8080/
getent ahostsv4 dispatch-example.invalid

getent asks the system’s configured name services for an address. Those services can consult /etc/hosts as well as DNS, which looks up domain names. The reserved .invalid name should fail to resolve. It gives us a failed lookup to inspect without changing resolver settings.

With localhost, the client has one extra job before connecting: turn the name into an address. If both this URL and the numeric one work, both requests reached a working endpoint. If only the numeric URL works, compare the returned addresses with the attempted connection. The name may have sent the client to a place where this server is not listening.

A browser may take a different route through a proxy or its own encrypted-DNS settings. If its result differs from getent’s, compare those paths. This command reports one system lookup, not a result every client is obliged to share.

Three failures that point to different places

Stop the service and repeat the numeric request. A local “connection refused” error means the connection was rejected, commonly because nothing is listening there. A timeout can reflect dropped traffic or an unresponsive path and needs more investigation. Neither is an HTTP 404; neither required a server to send an HTTP reply.

Start the service again and request /missing, then /. Expect 404 from the first and 200 from the second. One reachable server can lack one resource while serving another. Save both responses so the distinction does not disappear into a note saying only “network issue.”

For a remote destination, ip route get ADDRESS shows which route and source address the kernel chooses. It cannot establish that every intervening hop or firewall will allow the connection. Loopback keeps those outside uncertainties out of this exercise.

Put the observations in order: with the service stopped, the request was refused; after it started, the page returned; another path returned 404. That account lets another learner predict what should happen to the next missing path without assuming the server will stop.

How far did this request get?

Keep the name lookup, address and route, listener, and HTTP response together, with the actual result of each command. Each answers a smaller part of the original question. “Localhost resolved to loopback” is something this exercise can show. “DNS works everywhere” reaches far beyond it.

Leave the service bound to loopback. Understanding these failures requires neither an exposed port nor a firewall change. The browser’s empty window now has a more useful explanation behind it: you can say which step the request reached and where to look next.

Names, routes and listeners

Ubuntu’s networking documentation supplies the system context. The manuals for curl, ip-route and ss explain the checks used here.