Open WebUI Not Connecting to Ollama? 4 Causes and Fixes

The interface loads, the login works, and the model dropdown is empty. Or the model list spins forever and settings pages hang. Almost every report of this pattern comes down to one of four causes, and they are worth checking in order because the cheap check rules out the expensive one.

The underlying reason this is the most common Open WebUI problem is structural: the interface and the model backend are separate processes that talk over HTTP. When the models are missing, the connection is wrong, not the model. That split is explained in how Open WebUI and local models fit together, and it is the mental model that makes the rest of this page obvious rather than fiddly.

Cause 1: Ollama is only listening on localhost

By default the Ollama server binds to 127.0.0.1, which accepts connections from the same machine and nothing else. A container is not the same machine as far as the network stack is concerned, so a correctly configured Open WebUI still gets refused.

The documented fix is to set OLLAMA_HOST=0.0.0.0 so the server listens on all interfaces, ensure the variable is actually present in whatever starts Ollama, and restart it. Where that variable goes depends on the platform, and the Ollama documentation is specific:

• Linux, systemd service: run systemctl edit ollama.service, add Environment="OLLAMA_HOST=0.0.0.0:11434" under [Service], then systemctl daemon-reload and systemctl restart ollama.
• macOS application: launchctl setenv OLLAMA_HOST "0.0.0.0:11434", then restart the Ollama application.
• Windows: quit Ollama from the taskbar, edit the environment variables for your account, add OLLAMA_HOST, then start Ollama again from the Start menu.

Setting the variable in the shell where you happen to be typing does nothing if Ollama is started by systemd or by the desktop application. That mismatch accounts for a lot of “I already set that” reports.

Binding to all interfaces makes Ollama reachable from your network, which is fine on a trusted LAN and not fine on anything exposed. Restrict it at the firewall rather than leaving an unauthenticated inference endpoint open.

Cause 2: localhost inside the container means the container

This is the trap that catches everyone once. When Open WebUI runs in Docker and you configure the backend as http://localhost:11434, the request is made by the Open WebUI process inside the container, and localhost there is the container itself, where nothing is listening.

Open WebUI’s documentation states the rule directly: for backend and admin-configured connections, use a URL the backend can actually reach. That means a Docker service name for a container on the same compose network, host.docker.internal to reach the host machine from inside a container, or the host’s real LAN address.

Three workable shapes, in rough order of preference:

# Ollama on the host, reached from a bridged container
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

# Host networking: no port mapping, so the UI answers on 8080, not 3000
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

# Ollama on another machine entirely
docker run -d -p 3000:8080 -e OLLAMA_BASE_URL=https://example.com \
  -v open-webui:/app/backend/data --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

The host-networking variant is the one the documentation offers for the Docker connection error, and its side effect is easy to miss: with --network=host there is no published port, so the internal port changes from 3000 to 8080 and the interface is at http://localhost:8080. People conclude the fix broke the site when it merely moved.

The same distinction explains a confusing symptom pair the documentation calls out separately: a URL that works when configured as a user or direct connection from the browser, and fails as an admin or global connection, because the first is resolved by your browser and the second by the backend. A 502 on admin-configured connections while user connections work, or Connect call failed ('127.0.0.1', ...) in the backend logs, is this exact difference.

Cause 3: saved configuration outranks your environment variable

Open WebUI stores parts of its configuration in its own database, and stored values take precedence over environment variables. Change OLLAMA_BASE_URL in a compose file, restart, and nothing happens, because a value saved earlier through the admin panel is still winning.

The documented options:

• RESET_CONFIG_ON_START=true forces environment variables to override database values at the next startup.
• ENABLE_PERSISTENT_CONFIG=false stops database values taking precedence at all, with the tradeoff that changes made in the interface no longer persist across restarts.
• Fix it in Admin Settings, Connections, by correcting or removing the bad base URL.

The documentation lists direct SQLite manipulation as a last resort, behind a backup. Treat it that way; the first two options solve this without touching the database.

Cause 4: the endpoint is reachable but slow, and everything waits

If the model selector spins, /api/models returns a 500, or opening Settings makes the interface unresponsive, the cause may be an endpoint that is configured but unreachable rather than one that is wrong. Open WebUI queries every configured Ollama and OpenAI base URL when it builds the model list, and by default waits ten seconds per unreachable endpoint. Several stale entries compound that into a wait long enough to look like a hang.

Lower it with AIOHTTP_CLIENT_TIMEOUT_MODEL_LIST, for example to 3 seconds, so a dead endpoint fails fast. Then remove the dead endpoints, because a shorter timeout hides the problem rather than fixing it.

Diagnose it in three commands

Test from the place that actually makes the request, not from your laptop.

# 1. Is Ollama answering at all, on the machine that runs it?
curl -s http://127.0.0.1:11434/api/tags

# 2. Is it answering on the interface the container will use?
curl -s http://<host-lan-ip>:11434/api/tags

# 3. Can the Open WebUI container reach it?
docker exec -it open-webui curl -s http://host.docker.internal:11434/api/tags

A JSON list of models from step 1 but a refused connection in step 2 is cause 1. Success in step 2 and failure in step 3 is cause 2, or a firewall between the two. Success in step 3 with an empty dropdown in the interface is cause 3: the application is not using the URL you think it is.

Check the container logs alongside this. Connection error: Cannot connect to host... names the address the backend really tried, which is frequently not the address you configured.

Adjacent problems that look like a connection failure

Models load but the reply is empty or the chat hangs. That is usually WebSocket or proxy configuration rather than the backend. WebSocket support is required from v0.5.0 onwards, and a reverse proxy needs the Upgrade and Connection headers plus proxy_http_version 1.1. Nginx buffering also corrupts streamed markdown, which the documentation fixes with proxy_buffering off. Those settings are collected in installing Open WebUI with Docker.

Replies stop partway or the provider rejects the request. “The prompt is too long” and “context length exceeded” come from the backend, not from Open WebUI. Every turn sends the system prompt, the entire chat history, any inlined attachments, tool definitions and results, and anything injected by retrieval or web search. Ollama’s default context window is 4096 tokens unless OLLAMA_CONTEXT_LENGTH or num_ctx says otherwise, and a long chat plus one large attachment clears that easily. Open WebUI does not silently truncate; it ships an optional Context Compaction feature, disabled by default, that summarises older messages once an estimated token threshold is crossed.

Everything works but generation is slow. Check where the model actually loaded before blaming the network. ollama ps reports a PROCESSOR column showing the GPU and CPU split, and a model reported as partly CPU has spilled out of GPU memory and will stay slow. The VRAM and context sizer estimates whether the model and context you want fit before you pull anything.

The order to check things

1. curl Ollama on its own host. If that fails, the problem is Ollama, not Open WebUI.
2. Confirm OLLAMA_HOST=0.0.0.0 is set where Ollama is actually started, and that Ollama was restarted afterwards.
3. curl from inside the Open WebUI container. If that fails, it is container networking or the firewall.
4. Confirm the base URL the application is really using, and reset persisted configuration if it disagrees with your environment.
5. Remove stale endpoints and shorten the model-list timeout.

If you are still weighing which front end to run before investing more time in one, Open WebUI compared with LibreChat covers how each connects to Ollama and what each costs to operate.