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

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

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

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

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))

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

Add, under the [Service] section:

[Service]
Environment="OLLAMA_HOST=0.0.0.0"
Environment="OLLAMA_ORIGINS=*"

Then reload and restart:

sudo systemctl daemon-reload
sudo systemctl restart ollama

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 app reads variables set with launchctl:

launchctl setenv OLLAMA_HOST "0.0.0.0:11434"

Then fully quit and reopen the app — it only reads the variable at launch. Important caveat: launchctl setenv is temporary and is lost on reboot. For a setting that survives restarts, add it to a LaunchAgent plist or a login script. Plenty of people set it once, get it working, reboot a week later, and the error returns from nowhere — this is why.

Windows (desktop app)

Ollama on Windows inherits your user environment variables, but only at startup:

1. Quit Ollama completely (right-click the taskbar tray icon → Quit — closing the window isn’t enough).
2. Open Settings (Win 11) or Control Panel (Win 10), search environment variables, click Edit environment variables for your account.
3. Add a new user variable: OLLAMA_HOST = 0.0.0.0.
4. Click OK, then relaunch Ollama.

If you’re on Windows running Open WebUI in Docker Desktop, you typically need both this and host.docker.internal — the WebUI could not connect on Windows Docker thread is full of people who fixed only one half and stayed stuck.

Cause 3: The saved URL in the database overrides your env var

This one is maddening because everything looks right. You set OLLAMA_BASE_URL correctly, restart the container — and it still uses the wrong URL.

Open WebUI persists connection settings in its database (the open-webui volume). If you ever saved an Ollama URL through the admin panel, that stored value wins over the environment variable on subsequent starts. The env var only seeds the initial config; once a value lives in the DB, the env var is ignored.

Fix it in the UI, not the env var: go to Settings → Connections → Ollama API, correct the URL (http://host.docker.internal:11434 for Docker-on-host, http://127.0.0.1:11434 for --network=host), and click the refresh/verify icon. A green check means the backend reached Ollama. Save.

While you’re there: if Ollama responds but large models time out mid-generation, that’s not a connection failure — it’s the default 5-minute client timeout. Set AIOHTTP_CLIENT_TIMEOUT (in seconds) on the Open WebUI container to something longer for slow first-token loads on 70B-class models.

A clean two-container setup that avoids all of this

If you’re starting fresh, run both Ollama and Open WebUI in the same Docker Compose stack on a shared network. Then they address each other by service name, and none of the localhost/host.docker.internal ambiguity applies:

services:
  ollama:
    image: ollama/ollama
    volumes:
      - ollama:/root/.ollama
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    volumes:
      - open-webui:/app/backend/data
    depends_on:
      - ollama
volumes:
  ollama:
  open-webui:

Here http://ollama:11434 resolves over Docker’s internal DNS to the Ollama container. There’s no host networking, no bind-address surgery, and it survives reboots cleanly. The official bundled image (ghcr.io/open-webui/open-webui:ollama) packages both in one container if you’d rather not manage a compose file — but the two-container split is easier to update and debug.

Quick reference: match the symptom to the fix

Symptom	Most likely cause	Fix
curl localhost:11434 works on host, fails in Docker	Container localhost ≠ host	--add-host=host.docker.internal:host-gateway + URL host.docker.internal:11434
ss shows 127.0.0.1:11434	Ollama bound local-only	OLLAMA_HOST=0.0.0.0 (set it where the service reads it)
Set env var, still wrong URL	Saved DB value wins	Edit URL in Settings → Connections
Works, then breaks after reboot (Mac)	launchctl setenv is temporary	Move to a LaunchAgent plist
Connects, but big models cut out	5-min client timeout	Raise AIOHTTP_CLIENT_TIMEOUT

FAQ

Why does it work in my terminal but not in Open WebUI? Because your terminal and the Open WebUI container are different network contexts. curl localhost:11434 from your shell hits the host’s loopback, where Ollama listens by default. The container has its own loopback. Use host.docker.internal (or a shared Docker network) so the container reaches the host.

Do I need OLLAMA_HOST=0.0.0.0 if I use --add-host=host.docker.internal? Usually yes. host.docker.internal makes the container address the host correctly, but Ollama still has to accept a connection arriving on a non-loopback interface. If it’s bound to 127.0.0.1, it’ll refuse the container’s request. Set both.

I’m accessing Ollama on another machine entirely. Same fixes? The Ollama side is identical — bind to 0.0.0.0 and open port 11434 on the firewall. On the Open WebUI side, just point the URL at that machine’s LAN IP (http://192.168.1.x:11434). For access from outside your network, don’t expose 11434 to the internet raw — tunnel it. See reaching your home AI server from anywhere with Tailscale.

Is binding to 0.0.0.0 a security risk? On a trusted home LAN behind a router, it’s fine. The risk is exposing port 11434 directly to the public internet — Ollama has no authentication, so anyone who can reach it can run models on your hardware. Keep it behind your firewall or a VPN/Tailscale tunnel, and set OLLAMA_ORIGINS rather than leaving it wide open if you can.

My model list is empty but there’s no error. That’s still a connection issue — Open WebUI reached something but got no model list, often because it’s pointed at the wrong port or a stale URL. Re-verify in Settings → Connections, and confirm ollama list actually shows pulled models on the host.

Does this apply to LM Studio’s server too? The networking principles are identical (bind address + Docker localhost), but LM Studio uses a different default port (1234) and an OpenAI-compatible endpoint. Point Open WebUI’s OpenAI connection at http://host.docker.internal:1234/v1 instead.

Once the connection is solid and you want to share the rig with a household, the next step is multi-user setup — see Open WebUI multi-user auth for the family. If you’re wiring this into a coding workflow, the local AI coding stack guide and our sister site aicoderscope.com cover editor integrations.

Sources

• Connection Errors — Open WebUI Docs
• TROUBLESHOOTING.md — open-webui GitHub
• FAQ — Ollama Docs (OLLAMA_HOST, systemd, launchctl, Windows)
• Forcing Ollama to bind to 0.0.0.0 instead of localhost — Issue #5905
• OLLAMA_HOST still 127.0.0.1 after setting env var — Issue #7128
• WebUI could not connect to Ollama on Windows Docker — Discussion #10531
• Quick Start — Open WebUI Docs
• Releases — open-webui (v0.9.6, June 2 2026)

Last updated June 23, 2026. Open WebUI v0.9.6, Ollama v0.30.x. Commands and version behavior change; verify against the current docs before relying on them.