Docker Networking Issues - Container Can't Reach Host

A container suddenly can't talk to a service running on the host, and localhost just doesn't work the way it did outside Docker. This is one of the most common Docker gotchas, and interviewers like it because it's a quick way to check if you actually understand container networking or just know the commands.

The answer interviewers want

Inside a container, localhost points to the container itself, not to your host machine. Think of the container as a separate apartment: its own loopback interface, its own network namespace. So if your host has a database or API listening on localhost:5432, the container has no way to see it by calling localhost.

There are three common ways to fix this:

1. Use host.docker.internal as the hostname for host services. The container resolves this to the host's IP.
2. Use --network host (network mode host), which drops the container into the host's network namespace directly, so localhost inside the container really is the host.
3. Bind the service to 0.0.0.0 instead of 127.0.0.1, so it listens on all interfaces and is reachable from the container's bridge network via the host's bridge IP.

The pro tip worth mentioning explicitly: host.docker.internal only works on Docker Desktop (Mac and Windows). On production Linux hosts, it doesn't resolve by default. There you need the host gateway IP, or you add it manually with the --add-host=host.docker.internal:host-gateway flag (the extra hosts flag) so your containers behave the same way across dev and prod.

Why interviewers ask this

They're checking whether you understand that containers run in isolated network namespaces, not whether you've memorized a magic hostname. A candidate who can explain why localhost breaks, instead of just reciting the fix, shows they'd actually be able to debug a real networking incident instead of guessing.

Follow-ups to expect

• Why doesn't host.docker.internal work in production? Because it's a Docker Desktop feature backed by a VM networking layer; plain Linux Docker doesn't ship that resolution by default, so you need the host-gateway flag or the gateway IP directly.
• What's the tradeoff of using --network host? You lose network isolation between the container and host, which is a security and port-collision concern, so it's generally avoided in multi-tenant or production setups.
• What if binding to 0.0.0.0 isn't an option for a legacy service? Then you're stuck using the host gateway IP or host networking, since you can't change what interface the service listens on.

The common wrong answer

Most candidates jump straight to "just use host.docker.internal" without explaining why localhost fails in the first place, and without knowing it's Docker Desktop-only. That answer falls apart the moment the interviewer asks what happens on a production Linux box, which is exactly the follow-up most people get wrong.