Ollama Docker Connection Refused on Port 11434: Fix It

Quick fix: if Ollama runs on the host and your client runs in Docker, do not point the container at localhost:11434. Use host.docker.internal:11434 on Docker Desktop, map host-gateway on Linux, or use the Compose service name when both services share a network.

If that still returns connection refused, test /api/tags on the host and then from the container. When the host works but the container cannot connect, check whether Ollama is bound only to 127.0.0.1 instead of an interface the container can reach.

Reinstalling the model will not fix a network-boundary or socket-binding problem.

Why localhost changes inside Docker

In a standard container, 127.0.0.1 refers to that container, not to the Docker host. If Ollama runs on the host and the client runs inside Docker, a client configured with http://localhost:11434 tries to contact itself.

Use the address that matches the topology:

Those destinations only solve naming and routing. They do not guarantee the process is listening or that a firewall permits traffic.

Step 1: Test the Ollama API on the host

Ollama’s documented model-list endpoint is GET /api/tags. Run this from the host on which Ollama is installed:

curl -sS -i http://127.0.0.1:11434/api/tags

A JSON response means an Ollama HTTP server is reachable. An empty models array means there may be no local models; it is not a network failure.

If the connection fails on the host, inspect the process before changing Docker settings. On a typical Linux systemd installation:

systemctl status ollama
journalctl -u ollama -n 80 --no-pager

If Ollama runs under another launch mechanism, check that mechanism’s logs and bind address instead.

Step 2: Test host access from a throwaway container

On Docker Desktop, Docker documents host.docker.internal as the hostname for a service on the host:

docker run --rm curlimages/curl:latest -sS -i http://host.docker.internal:11434/api/tags

This diagnostic container changes no existing application configuration. If it succeeds, update the client’s Ollama base URL to use that reachable destination.

On ordinary Linux Docker Engine, Docker supports mapping the host gateway explicitly:

docker run --rm \
  --add-host host.docker.internal=host-gateway \
  curlimages/curl:latest -sS -i \
  http://host.docker.internal:11434/api/tags

The host-gateway mapping resolves an address; it does not cause the Ollama service to listen there. Distinguish a DNS resolution failure from TCP connection refused, a timeout, or an HTTP status response.

Step 3: Linux DNS works, yet port 11434 refuses connections

Ollama’s official FAQ says it binds to 127.0.0.1:11434 by default. A Docker bridge-network container generally contacts a different host interface via the gateway. A process bound only to loopback cannot accept that connection.

The server setting is OLLAMA_HOST. Ollama documents setting it for a Linux systemd service through an override:

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

The service-edit sequence in the upstream guidance is:

sudo systemctl edit ollama.service
sudo systemctl daemon-reload
sudo systemctl restart ollama

Security boundary: 0.0.0.0 broadens the listen address. It can expose the API to additional interfaces, depending on firewall and routing. Do not blindly expose Ollama on an untrusted network or publish port 11434 to the Internet. Where feasible, bind only to a permitted interface and restrict source traffic with appropriate local controls. Inspect the host firewall and listening socket before allowing access.

After adjusting only the intended Ollama service, repeat /api/tags from the client container. If it still fails, investigate rootless networking, container network configuration, and firewall policy. Do not keep changing model files when the HTTP connection itself has not succeeded.

Step 4: If Ollama itself is in Compose, use service DNS

If both components are services in a Compose project and share a network, reach the Ollama service by its Compose service name:

http://ollama:11434

For a service named app containing curl, a diagnostic looks like:

docker compose exec app curl -sS -i http://ollama:11434/api/tags

Replace app with the actual client service name; minimal runtime images may not ship curl. A temporary network-attached diagnostic client is another option.

For service-to-service traffic on the same Compose network, publishing Ollama’s port to the host is not necessary. Docker’s service discovery and host port publishing are different functions.

For a Compose application that instead needs a Linux host Ollama service, Docker documents:

services:
  app:
    extra_hosts:
      - "host.docker.internal:host-gateway"

This is a hostname mapping, not a fix for a loopback-only Ollama socket.

Step 5: Do not confuse HTTP, CORS, and model failures

A browser CORS rejection is not a TCP refusal. Ollama documents OLLAMA_ORIGINS for allowed browser origins; configure only the origins needed by the application rather than opening the server to every network.

An HTTP error response proves that an HTTP endpoint answered. For example, a model-not-found response means model identity or the request path needs attention, not that Docker cannot connect. Verify model inventory using /api/tags from the same network context as the failing application.

A clean evidence record contains the client container name, target hostname and port, whether host and container requests to /api/tags succeed, the Ollama bind address, and a sanitized error body. Keep credentials, private network topology, hostnames and unrelated logs out of public support reports.

Quick decision path

1. Host /api/tags fails: repair the Ollama process or socket.
2. Host works, container localhost fails: change the URL to an appropriate host gateway or service name.
3. Linux gateway resolves but refuses: check Ollama’s bind address and firewall.
4. Container /api/tags works, generation fails: inspect API parameters, model inventory and application logic, not Docker routing.

Primary sources

• Ollama FAQ: binding and OLLAMA_HOST
• Ollama API: list local models
• Docker: host-gateway for container-to-host access
• Docker Compose: service DNS and extra_hosts

See also How to Run an LLM Locally and How Much VRAM Do You Need for LLMs?.