DEV Community

Jovan Chan
Jovan Chan

Posted on • Originally published at runaihome.com

Open WebUI Can't Connect to Ollama? Every Fix for the Server Connection Error (2026)

This article was originally published on runaihome.com

TL;DR: 90% of "Open WebUI can't reach Ollama" failures are one of two things: Open WebUI runs in a Docker container where localhost means the container, not your machine — or Ollama is bound to 127.0.0.1 and refuses outside connections. Fix the URL with host.docker.internal, bind Ollama with OLLAMA_HOST=0.0.0.0, and check the saved URL in Settings hasn't overridden your env var.

What you'll be able to do after this:

  • Diagnose whether the break is on the Open WebUI side (Docker networking) or the Ollama side (bind address) in under two minutes with one curl and one ss command.
  • Apply the exact fix for your setup — Docker on Linux, Docker Desktop on Mac/Windows, or --network=host.
  • Stop the error from coming back after a reboot or a settings change.

Honest take: Don't start editing config files. Run curl http://localhost:11434 first. If it answers, the problem is how the container is addressing Ollama; if it doesn't, Ollama itself isn't reachable. That one check tells you which half of this guide to read.

The two error messages, and what each one means

Open WebUI surfaces this failure in a couple of ways. In the chat box you'll see a red "Open WebUI: Server Connection Error" toast, or the model dropdown is simply empty with no models to pick. In the admin panel under Settings → Connections, a "Verify Connection" click returns "WebUI could not connect to Ollama."

Both mean the same thing: the Open WebUI backend tried to reach the Ollama API at the URL it has configured (default http://localhost:11434) and got nothing back. The question is why, and there are exactly three common causes. Work them in order — they're sorted from most to least likely.

This guide assumes Open WebUI v0.9.6 (released June 2, 2026) and Ollama v0.30.x (current as of June 2026). The mechanics below have been stable across the 0.x line of both projects, but the version tags matter when you're reading older forum threads — pre-0.2 Open WebUI used OLLAMA_API_BASE_URL, which was renamed.

Step 0: Is Ollama even running?

Before touching Open WebUI, confirm Ollama answers on the host where it's installed:

$ curl http://localhost:11434
Ollama is running
Enter fullscreen mode Exit fullscreen mode

If you get Ollama is running, the server is up and serving on the local interface. Good — skip to Cause 1, because your problem is almost certainly Docker networking.

If you get curl: (7) Failed to connect to localhost port 11434: Connection refused, Ollama isn't running at all (or crashed on startup). Start it (ollama serve, or start the desktop app), then re-run the curl. If it still refuses after the app says it's running, that's a different class of failure — see our guide on Ollama not using the GPU and falling back to CPU and the llama runner process terminated walkthrough for crash-on-load cases.

Cause 1: Docker's localhost is not your localhost (the #1 cause)

This is the single most common reason, and it trips up almost everyone running the recommended Docker install.

Here's the trap. You install Ollama natively on your machine, it listens on localhost:11434, and curl http://localhost:11434 works perfectly from your terminal. Then you run Open WebUI in Docker and point it at http://localhost:11434 — and it fails.

The reason: inside a Docker container, localhost (and 127.0.0.1) refers to the container itself, not the host machine. Ollama is running on the host. From the container's point of view, nothing is listening on its own localhost:11434. The official troubleshooting docs state it plainly — the failure is "the WebUI docker container not being able to reach the Ollama server at 127.0.0.1:11434 (host.docker.internal:11434) inside the container."

There are two clean fixes.

Fix 1a: Use host.docker.internal (recommended)

Docker provides a special hostname, host.docker.internal, that resolves to the host machine from inside a container. Point Open WebUI at that instead of localhost.

On Docker Desktop (Mac and Windows), host.docker.internal works automatically. On Linux, it does not exist by default — you have to add it with --add-host. This is the line most Linux tutorials get wrong.

The correct Linux command:

docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui \
  --restart always \
  ghcr.io/open-webui/open-webui:main
Enter fullscreen mode Exit fullscreen mode

Then set the Ollama URL inside Open WebUI to http://host.docker.internal:11434 (either via the env var below or in the admin panel — see Cause 3 for why the panel can win).

You can also bake the URL into the container at launch:

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 --restart always \
  ghcr.io/open-webui/open-webui:main
Enter fullscreen mode Exit fullscreen mode

After this, Open WebUI is at http://localhost:3000 (the 3000:8080 mapping sends host port 3000 to the container's internal port 8080).

OLLAMA_BASE_URL is the environment variable Open WebUI reads to decide where to forward Ollama API calls. Note it's OLLAMA_BASE_URL in current versions — older guides referencing OLLAMA_API_BASE_URL are pre-0.2 and will silently do nothing.

Fix 1b: Use --network=host

The blunter option is to share the host's network stack directly, so localhost inside the container points where you'd expect:

docker run -d --network=host \
  -v open-webui:/app/backend/data \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main
Enter fullscreen mode Exit fullscreen mode

Watch the port change. With --network=host, the -p 3000:8080 mapping is ignored — the container binds the host's port 8080 directly. So Open WebUI is now at http://localhost:8080, not 3000. People apply this fix, see the old URL stop working, and assume it failed. It didn't; the address moved.

--network=host is the less-preferred fix because it throws away Docker's network isolation. Use host.docker.internal unless you have a specific reason not to.

Cause 2: Ollama is bound to 127.0.0.1 and rejecting the container

If curl http://localhost:11434 works on the host but Open WebUI still can't connect even after fixing the address, the problem flips to the Ollama side. By default Ollama binds only to the loopback interface 127.0.0.1, which accepts connections from the same machine but not from the Docker bridge network the container lives on.

Confirm what it's actually bound to:

$ ss -tlnp | grep 11434
LISTEN 0  4096  127.0.0.1:11434  0.0.0.0:*  users:(("ollama",pid=1234,fd=3))
Enter fullscreen mode Exit fullscreen mode

127.0.0.1:11434 = local only. You want to see 0.0.0.0:11434 (all IPv4 interfaces) or *:11434. The fix is to set OLLAMA_HOST=0.0.0.0, and how you set it depends on the platform — this is where most people go wrong, because Ollama reads its environment once at startup and a variable exported in your shell often isn't the environment the service actually runs under.

Linux (systemd)

If Ollama was installed via the official script, it runs as a systemd service — and your shell's export OLLAMA_HOST=0.0.0.0 does nothing, because systemd uses its own environment, not your terminal's. You have to edit the unit:

sudo systemctl edit ollama.service
Enter fullscreen mode Exit fullscreen mode

Add, under the [Service] section:

[Service]
Environment="OLLAMA_HOST=0.0.0.0"
Environment="OLLAMA_ORIGINS=*"
Enter fullscreen mode Exit fullscreen mode

Then reload and restart:

sudo systemctl daemon-reload
sudo systemctl restart ollama
Enter fullscreen mode Exit fullscreen mode

OLLAMA_ORIGINS=* relaxes the CORS origin check, which matters when a browser-based front end on a different host/port talks to the API. Re-run the ss check; you should now see 0.0.0.0:11434.

macOS (desktop app)

The Ollama menu-bar ap

Top comments (0)