Why Nginx Says “Host Not Found in Upstream” in Docker

When Nginx reports host not found in upstream inside Docker, check container networking and startup order before changing the application.

What the error means

A typical Docker setup sends requests from an Nginx container to an application service by its Compose service name:

fastcgi_pass app:9000;

Docker provides DNS for that name. Nginx can resolve it only when both containers are attached to the same Docker network and the target service is available there.

Why it happens

The application can be healthy while Nginx is stuck in a restart loop. This often happens after Docker restarts: Nginx starts first, tries to resolve the application service immediately, and exits because the DNS name is not available yet.

Earlier HTTP 200 access-log entries do not explain the new failure. The useful line is the Nginx startup error itself.

How to diagnose it

Check the service states:
```
docker compose ps
```
Confirm that the proxy and application share a network:
```
docker inspect proxy app
```
Compare the upstream hostname with the Compose service name. If Nginx uses app:9000, the service or its network alias must be app.
Read the latest proxy logs:
```
docker compose logs --tail=50 proxy
```

Common causes and fixes

Cause: The containers are on different networks. Fix: attach both services to one shared Compose network.
Cause: The Nginx hostname does not match the service name. Fix: correct the upstream name or add a network alias.
Cause: Nginx started before Docker DNS exposed the application service. Fix: restart the application and proxy after the network is ready.
Cause: A stale container has old network settings. Fix: recreate the affected services from the current Compose file.

A practical recovery step

If the names and networks are correct, restart only the related services:

docker compose restart app proxy

Then confirm that both remain running and that the proxy log no longer contains the upstream resolution error.

One important detail

depends_on controls start order, but it does not always prove that the target is ready for traffic. A health check and restart policy can make recovery more reliable, especially when the proxy resolves upstream names during startup.

Distinguish lookup failure from connection failure

A hostname lookup failure occurs before Nginx connects to the application. A resolved name followed by connection refused points instead to the listener, port, or readiness. Use docker compose exec proxy getent hosts app if the proxy image includes getent. Compose service names are not necessarily container names, so inspect services through Compose when possible.

Treat host not found in upstream as a Docker DNS or network problem first. The next action is simple: compare the Nginx upstream name with the Compose service name, then verify that both containers share a network.

Reference: Docker Compose networking.