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 interface and the model backend are separate processes that talk over HTTP. An empty dropdown can mean the connection failed, a saved URL is wrong, or Ollama has no models installed. Start with how Open WebUI and local models fit together to identify which process owns the symptom.
ollama: network problem
Check Ollama on its own host with curl -s http://127.0.0.1:11434/api/tags, then repeat from the Open WebUI container using its configured Ollama URL. If only the host request succeeds, check the bind address and container networking below. A response with an empty model list means the endpoint answered; confirm that a model is installed on that server.
ollama: cannot connect to host host.docker.internal:11434 …
The ellipsis represents the rest of the reported error; inspect the full log for a name-resolution failure, refusal, or timeout. For host-based Ollama, check the --add-host=host.docker.internal:host-gateway mapping and its listening address. If Ollama runs in another container, use its service name on a shared Docker network. Docker documents that containers on a user-defined bridge can resolve each other by name.
open webui: server connection error
Check which request failed in the browser’s Network panel. If /api/config fails, verify the route to Open WebUI’s container port 8080; if chat fails through a proxy, check WebSocket forwarding. An Ollama connection error instead calls for the backend checks below. The Open WebUI connection documentation distinguishes these paths.
502 bad gateway
Identify the failing upstream. If a direct browser connection works but the admin connection returns 502, check the URL from inside Open WebUI: localhost resolves there differently. If the entire site fails through a reverse proxy, inspect its upstream address and port. Follow the Docker installation and reverse-proxy guide for that configuration.
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, addEnvironment="OLLAMA_HOST=0.0.0.0:11434"under[Service], thensystemctl daemon-reloadandsystemctl 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:mainThe 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=trueforces environment variables to override database values at the next startup.ENABLE_PERSISTENT_CONFIG=falsestops 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/tagsA JSON list of models from step 1 but a refused connection in step 2 points to the bind address or firewall. Success in step 2 and failure in step 3 points to container networking or the firewall. If step 3 returns models but the dropdown stays empty, inspect the application’s saved connection settings. If the response itself contains no models, install one on that Ollama server first.
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. Check the allocated context with ollama ps: the Ollama context-length documentation describes defaults that vary with available VRAM, plus the OLLAMA_CONTEXT_LENGTH override. 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. The PROCESSOR column in ollama ps reports CPU/GPU placement. Follow Ollama not using GPU: diagnose model placement for device detection, GPU support and memory checks. The VRAM and context sizer estimates whether the model and context you want fit before you pull anything.
The order to check things
curlOllama on its own host. If that fails, the problem is Ollama, not Open WebUI.- Confirm
OLLAMA_HOST=0.0.0.0is set where Ollama is actually started, and that Ollama was restarted afterwards. curlfrom inside the Open WebUI container. If that fails, it is container networking or the firewall.- Confirm the base URL the application is really using, and reset persisted configuration if it disagrees with your environment.
- 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.
