curl: (52) Empty reply from server on the published port of an Ollama container started with -e OLLAMA_HOST=127.0.0.1:11434: the server inside listens on the container's own loopback, which the published port does not reach. Drop that variable (the image already sets OLLAMA_HOST=0.0.0.0:11434) or set it to 0.0.0.0:11434.

Keep the host side private with -p 127.0.0.1:<port>:11434. In the test below the container listened on all of its own interfaces while the published port on Windows stayed on 127.0.0.1.

The error

PS> docker run -d --name fix9-old-loop -e OLLAMA_HOST=127.0.0.1:11434 -p 127.0.0.1:15970:11434 ollama/ollama
...
PS> cmd /c "curl.exe -sS http://127.0.0.1:15970/api/version 2>&1"; echo exit=$LASTEXITCODE
curl: (52) Empty reply from server
exit=52

The container log says where the server listens:

PS> cmd /c "docker logs fix9-old-loop 2>&1" | findstr /C:"Listening"
time=2026-11-10T03:20:48.349Z level=INFO source=routes.go:2512 msg="Listening on 127.0.0.1:11434 (version 0.40.8)"

Why it happens

Inside a container 127.0.0.1 is the container's own loopback, not the Windows host. With the server bound to 127.0.0.1:11434 in the container, the published port gave curl no answer at all: an empty reply, exit code 52, not a refused connection. With the server on [::]:11434, the same kind of published port answered with the version.

The variable is easy to copy from a host setup, where 127.0.0.1 is the safe choice. The image sets its own value, which the -e option overrode: 

PS> docker image inspect ollama/ollama --format "{{.Id}} {{json .Config.Env}} {{json .Config.Entrypoint}} {{json .Config.Cmd}}"
sha256:2b8eecdb85aa6ea67c381c8ecffec04b2658496cf2821a8f88b0485bdff198e8 ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin","LD_LIBRARY_PATH=/usr/local/nvidia/lib:/usr/local/nvidia/lib64","NVIDIA_DRIVER_CAPABILITIES=compute,utility","NVIDIA_VISIBLE_DEVICES=all","OLLAMA_HOST=0.0.0.0:11434"] ["/bin/ollama"] ["serve"]

The fix

PS> docker run -d --name fix9-old-def -p 127.0.0.1:15971:11434 ollama/ollama
...
PS> cmd /c "curl.exe -sS http://127.0.0.1:15971/api/version 2>&1"; echo exit=$LASTEXITCODE
{"version":"0.40.8"}
exit=0
PS> cmd /c "docker logs fix9-old-def 2>&1" | findstr /C:"Listening"
time=2026-11-10T03:21:07.189Z level=INFO source=routes.go:2512 msg="Listening on [::]:11434 (version 0.40.8)"

The only change from the failing command is the missing -e OLLAMA_HOST=... option; the image and the published port stayed as they were, apart from the test's new port number. The log line is the quick check: it moved from 127.0.0.1:11434 to [::]:11434.

If a compose file or a script sets the variable on purpose, give it the all-interfaces value. That run answered too, and the host port stayed on loopback: 

PS> docker run -d --name fix9-old-any -e OLLAMA_HOST=0.0.0.0:11434 -p 127.0.0.1:15972:11434 ollama/ollama
...
PS> cmd /c "curl.exe -sS http://127.0.0.1:15972/api/version 2>&1"; echo exit=$LASTEXITCODE
{"version":"0.40.8"}
exit=0
PS> docker port fix9-old-any
11434/tcp -> 127.0.0.1:15972
PS> netstat -ano | findstr :15972 | findstr LISTENING
  TCP    127.0.0.1:15972        0.0.0.0:0              LISTENING       36556

0.0.0.0 inside the container opens the server to the container's network, and the 127.0.0.1 in -p 127.0.0.1:15972:11434 kept the Windows listener on loopback, as netstat shows above.

How it was reproduced

The cached ollama/ollama:latest image (Ollama 0.40.8, image id 2b8eecdb85aa) on Docker Desktop with engine 29.9.3 and the WSL 2 backend, Windows 11, curl.exe from Windows. Three containers were started: one with OLLAMA_HOST=127.0.0.1:11434, one with the image's default and one with OLLAMA_HOST=0.0.0.0:11434, each on its own 127.0.0.1 port. The container names are the test's own; all three were removed afterwards.

Frequently asked

Why does curl say Empty reply from server for my Ollama Docker container?
In this test the container was started with OLLAMA_HOST=127.0.0.1:11434, so its log said Listening on 127.0.0.1:11434 and the published port got no answer. Without that variable the log said Listening on [::]:11434 and curl got the version.
Is OLLAMA_HOST=0.0.0.0 safe inside a Docker container?
It opens the server to the container's network. Who can reach it from the PC is set by the published port: with -p 127.0.0.1:15972:11434 the Windows listener was on 127.0.0.1 only.
What OLLAMA_HOST does the ollama/ollama image use?
docker image inspect showed OLLAMA_HOST=0.0.0.0:11434 in the image's environment, with /bin/ollama as the entrypoint and serve as the command.

If the client runs in another container instead, see a container that cannot reach Ollama on localhost. More decoded errors in the Fixes category.