The scenario
The Client (10.0.1.10) reaches the Server (10.0.2.10) through a Router that uses its two connected networks and nothing else (OSPF is off). Routing is correct in both directions, so a ping gets its answer. But nothing on the Server accepts connections on its network address, 10.0.2.10: in this lab the Server has no listening ports at all. That is exactly what the network sees when a web server is bound only to the loopback address, 127.0.0.1: the developer's 'curl localhost' on the Server works, while every client gets 'connection refused'. This lab cannot run a test from the Server to itself; it models the part that matters to clients, which is that no service listens on 10.0.2.10.
What you will work out
Learn to tell a network problem from a service problem, and understand why a server bound to 127.0.0.1 refuses connections from the network.
Why this matters
'It works on my machine' is often literally true: the service answers on the machine and nowhere else. Reading the error precisely saves hours. 'Connection refused' means the packet arrived and nothing listens there; 'timed out' usually means something dropped it on the way; 'no route to host' points at routing or a host that is not there. Checking the bind address is one of the first things to do when a freshly deployed service cannot be reached.
Running it
Works Locally But Not Remotely opens on a canvas, already wired and addressed. Trace a packet through it hop by hop, or run the same topology live on real Linux network namespaces. How the two modes differ.
Open Works Locally But Not Remotely
Runs in your browser. No install, no signup, and the simulation starts instantly.
Open the lab →