Fix common Ollama errors: 500, timeouts and stalled pulls

Most Ollama failures fall into a handful of buckets: the service isn't running, a proxy variable is poisoning localhost traffic, the GPU driver and the runtime disagree, or the model simply doesn't fit in memory. This page collects the exact error strings people paste into Google, with the causes ranked by how often they turn out to be the culprit and the commands that fix them. Everything below was tested on the v0.32 line (August 2026) on Ubuntu, and most of it applies unchanged to Docker and Windows installs.

Skim the diagnostic section first even if you already know your error. Half the tickets I've seen get solved by the logs alone.

Quick diagnostics: systemctl, journalctl and curl

Before touching anything else, answer two questions: is the server up, and what did it log when things broke.

systemctl status ollama
journalctl -e -u ollama
curl http://localhost:11434

A healthy install shows active (running) in the first command and the curl returns the plain text Ollama is running. The journalctl output is where the real answers live: crashes, GPU discovery, memory estimates and the request that triggered a 500 all land there. If the log is too quiet to be useful, turn on debug output and reproduce the problem:

sudo systemctl edit ollama.service

Add this in the editor that opens, then restart:

[Service]
Environment="OLLAMA_DEBUG=1"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -f -u ollama

Leave journalctl -f running in a second terminal while you retry the failing command. With that in place, on to the catalog.

Error: something went wrong, please see the ollama server logs for details

This is Ollama's most generic failure message, and the single most common cause has nothing to do with the model: a proxy environment variable. Model pulls travel over HTTPS only, so HTTPS_PROXY is the one variable Ollama respects for downloads. A stray http_proxy in your shell or in the service environment routes the client's calls to 127.0.0.1:11434 through a proxy that can't reach it, and everything breaks with this vague message. There's a long thread on exactly this in GitHub issue 8983.

Check what's set, then clear it for local traffic:

env | grep -i proxy
unset http_proxy HTTP_PROXY
export no_proxy=127.0.0.1,localhost

If you need the proxy for pulls, keep HTTPS_PROXY and add the no_proxy exception rather than clearing everything. When proxies aren't involved, the message means what it says: read journalctl -e -u ollama, because the actual error (a crashed runner, a corrupt download, a permissions problem) is printed there in full.

500 internal server error

A 500 from Ollama means the server accepted your request and then died trying to serve it. You'll also see variants like 500 Internal Server Error: remote host bubbled up through clients. Causes, in the order I'd check them:

1. The model runner ran out of VRAM or RAM. The API process survives but the subprocess doing inference gets killed. The log shows the memory math it attempted. Try a smaller quant or model tag and see the out of memory section below.

2. An outdated Ollama meeting a new model. New architectures need new runtime support. If you're pulling a model released after your install date, upgrade first (the last section covers how) and retry before debugging anything else.

3. A corrupt model blob. Remove and re-pull:

ollama rm llama3.2
ollama pull llama3.2

4. A genuine bug. If the log shows a Go panic or a CUDA error you can't explain, search the text in the Ollama repository issues. Odds are decent someone hit it this week.

Error: pull model manifest: file does not exist

The registry is telling you the tag you asked for doesn't exist. Three causes cover nearly every case:

A typo'd model name or tag. ollama pull llama3.2:3B fails while llama3.2:3b works. Tags are exact strings. Copy them from the model page rather than typing from memory.

Your client is pointed at the wrong host. If you pulled the model on your server but your laptop's OLLAMA_HOST points somewhere else, the "missing" model is sitting on a machine you're not talking to. Run ollama list through the same host setting your failing command uses.

A stale model list in a frontend. AnythingLLM and similar tools cache the model dropdown. Pull a model, then refresh the list in the tool's settings before selecting it. The model exists, the UI just hasn't asked again.

Model pull stuck at the same percentage

Pulls that stall at a fixed percent (and sometimes slowly go backwards as the retry logic resets chunks) are a known behaviour tracked in issue 8632. The good news: pulls resume. Interrupt and restart, and it continues from where the completed layers left off:

ollama pull deepseek-r1:8b
# Ctrl+C when it stalls, then run the same command again

Looping that a couple of times gets most stuck pulls through. If it keeps dying at the same point, work through these: check free disk space with df -h (the service stores models under /usr/share/ollama/.ollama/models, and a partial 40 GB download fails quietly when the disk fills), check for the proxy variables from the first section and run the pull with debug logging on to see which layer and endpoint are failing. Corporate networks that intercept TLS are a repeat offender here.

could not connect to ollama app, is it running?

The client can't reach anything on port 11434. Same family as connection refused errors from curl or from libraries. Two situations produce it.

The service is down. Start it and check it stayed up:

sudo systemctl start ollama
systemctl status ollama

If it starts and immediately exits, the log tells you why (a bad Environment line in an override file is a classic, one typo'd systemctl edit and nothing boots).

You're calling from another machine. Ollama binds to 127.0.0.1:11434 by default, so remote connections are refused by design. Expose it deliberately:

sudo systemctl edit ollama.service

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

sudo systemctl daemon-reload
sudo systemctl restart ollama

Do that on anything internet-facing and you've published an unauthenticated API to the world, so put a firewall rule or reverse proxy in front. The Ollama VPS hosting guide covers the secure version of this setup end to end.

Server Connection Error in Open WebUI

Nearly always a wrong OLLAMA_BASE_URL or a container networking miss, and rarely a problem with Ollama itself. Open WebUI runs inside Docker, so localhost from the container's point of view is the container, where no Ollama lives. When Ollama runs on the host, start Open WebUI like this:

docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  -v open-webui:/app/backend/data \
  --name open-webui ghcr.io/open-webui/open-webui:main

The --add-host flag makes host.docker.internal resolve on Linux (Docker Desktop does it automatically). Verify from inside the container before touching anything else:

docker exec -it open-webui curl http://host.docker.internal:11434

If that curl fails, the problem is reachability: Ollama bound to 127.0.0.1 (fix above), a firewall or a wrong hostname. If the curl succeeds and the UI still complains, recheck the URL in Settings under Connections, a trailing typo there produces the identical banner. Full setup steps live in the Open WebUI and Ollama setup guide.

Connection Timeout in Open WebUI

Different beast from the connection error above: here Open WebUI reached Ollama fine but gave up waiting for the answer. Its HTTP client times out after 300 seconds by default, and a big model doing a long generation on CPU sails past that. Raise the AIOHTTP_CLIENT_TIMEOUT environment variable on the Open WebUI container:

docker run -d -p 3000:8080 \
  -e AIOHTTP_CLIENT_TIMEOUT=1200 \
  ... rest of your usual flags ...
  ghcr.io/open-webui/open-webui:main

The variable is documented in the Open WebUI environment configuration reference. If you find yourself setting it above 20 minutes, the honest fix is a smaller model or faster hardware, because nobody wants a chat UI that answers in geological time.

Ollama not detecting the GPU

Symptom: inference crawls, ollama ps shows 100% CPU under the processor column and the startup log never mentions your card. Work down this list:

nvidia-smi

If nvidia-smi itself fails, Ollama never had a chance. Fix the driver first, and after any driver upgrade, reboot: a kernel module version mismatch between the loaded module and the userland libraries is the most common silent breakage. When nvidia-smi works but Ollama still ignores the card, restart the service and read the discovery lines at the top of the log. It prints what it found and why it rejected anything it rejected.

In Docker, the container sees no GPU unless you pass it in. That needs the NVIDIA Container Toolkit installed on the host plus the flag:

docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

Test with docker exec -it ollama nvidia-smi. On AMD, use the ollama/ollama:rocm image with --device /dev/kfd --device /dev/dri instead. The Ollama Docker guide walks through both stacks.

Out of memory errors

OOM shows up wearing different masks: a blunt CUDA out of memory line, a killed runner producing a 500, or the Linux OOM killer silently ending the process (look for oom-kill in dmesg). The causes stack, which is what makes this one sneaky:

The model is simply too big. A rough rule: the file size of the quantized model plus a few GB of margin must fit in VRAM, or in RAM for CPU inference. The hardware requirements guide has sizing tables per model family.

The context window is inflating the footprint. KV cache grows with context, and jumping num_ctx from the default 4096 to 32k can add gigabytes. If OOM appeared right after you raised the context, that's your answer. The context window guide covers the memory cost per size.

Previous models are still loaded. Models linger for 5 minutes after last use (OLLAMA_KEEP_ALIVE), and the server keeps up to 3 models resident by default. Check and clear:

ollama ps
ollama stop qwen3:14b

On a memory-tight box I set OLLAMA_MAX_LOADED_MODELS=1 in the service override and stop pretending I can host a model zoo in 16 GB.

listen tcp 127.0.0.1:11434: bind: address already in use

Something already owns the port, and in practice it's almost always a second copy of Ollama: the systemd service fighting a manually launched ollama serve, or a Docker container publishing 11434 while the host service runs too. Find the owner and stop the copy you don't want:

sudo lsof -i :11434

sudo systemctl stop ollama     # if the service is the extra copy
docker stop ollama             # if a container is the extra copy

Pick one way to run Ollama per machine and retire the others, future you will thank present you during the next debugging session.

Docker-specific failures

Three container problems come up constantly. First, the GPU passthrough miss covered above: no --gpus=all, no acceleration, and the container won't warn you, it just quietly runs on CPU. Second, container-to-container networking: a frontend in one container can't reach Ollama in another via localhost. Put both on a user-defined network or in one compose file and use the service name as the hostname, http://ollama:11434, since compose DNS resolves service names automatically. Third, lost models after recreating the container, which means the volume mount was missing. Always run with -v ollama:/root/.ollama so pulled models survive image updates.

When to upgrade, when to roll back

Upgrade first when the error involves a recently released model, GPU discovery on new hardware or anything you can find fixed in the release notes. Rerunning the install script upgrades in place and doesn't touch your models:

curl -fsSL https://ollama.com/install.sh | sh

Roll back when a working setup broke right after an upgrade. The script pins versions through an environment variable:

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.9 sh

Confirm with ollama --version, and if the older release fixes it, that's a bug worth reporting rather than silently living on an old version forever. A useful issue includes your version, OS, GPU and driver version, the exact model tag, the full error text and the relevant journalctl output captured with OLLAMA_DEBUG=1. Maintainers close vague reports and fix reproducible ones, and a debug log usually makes the difference. The official FAQ is worth a skim before filing, since a surprising number of "bugs" are documented behaviours like keep-alive or the localhost-only default.

One last note from experience: if you've reinstalled, overridden and edited your way into a config you no longer trust, a clean reinstall on a fresh box takes ten minutes and beats an afternoon of archaeology. The Ubuntu install guide gets you back to a known-good baseline.