If Open WebUI opens but its model list is empty, identify where Ollama is running. The browser’s connection to WebUI is different from WebUI’s connection to Ollama. A healthy Ollama server on the host may still be unreachable from the WebUI container.
This article covers configuring Docker’s Open WebUI backend to connect to Ollama. The confirmation order is: Model list of Ollama → Connection in WebUI container → Administrator connection settings → Model access by user. Screen names may vary slightly depending on the Open WebUI version.
On this page
First check with API whether model exists in Ollama
On the host where you installed Ollama, run: If Ollama is in a container and has not exposed ports to the host, there may be no API at 127.0.0.1 on the host. That configuration checks with the same Docker network path in the next section.
ollama list
curl --fail --show-error --connect-timeout 3 --max-time 10 http://127.0.0.1:11434/api/tagsIf models in the API response is an empty array, the Ollama server has no models to display. If you think you already have a downloaded model, make sure you aren’t looking at a different server or a different save path. If OLLAMA_HOST in the shell points to a remote server, then ollama list and the local curl above may query different servers.
Connection refused is a clue that a connection was not received from that address/port. If ollama list also fails, check the Ollama service before setting up WebUI. Model installation and Linux service configuration are described in Running Ollama on Linux.
Guess which computer localhost is.
| Ollama location | Example address to use in WebUI backend | Conditions to check first |
|---|---|---|
ollama service on the same Compose network | http://ollama:11434 | Service name and shared network |
| Run directly on Docker host | http://host.docker.internal:11434 | Hostname mapping and Ollama’s standby address |
| Separate private server | http://10.20.30.10:11434 | Real server IP, routing, firewall |
| Both WebUI and Ollama run directly on the same host | http://127.0.0.1:11434 | Both processes use the same network space |
The addresses in the table are examples for each configuration. In a typical Docker bridge network, a container’s localhost points to the container itself. There is no Ollama in the WebUI container, but if you enter http://localhost:11434, it will look in the wrong place. Host network modes are distinguished because they have different operating conditions.
If you run it in the same Compose project, it is easier to understand the configuration of connecting by service name. If the container is from a different project, also make sure it is connected to the same custom network. Just because two containers are on the same server doesn’t mean their service names will resolve to each other.
Call the API from within the WebUI container
The following example is where the WebUI container name is open-webui and the Ollama service name is ollama. Replace them with your actual name and address. You can check the connection with the Python 3 standard library even without a separate curl in the container.
docker exec -i open-webui python3 - <<'PY'
import json
import urllib.request
base = "http://ollama:11434"
with urllib.request.urlopen(base + "/api/tags", timeout=5) as response:
data = json.load(response)
print([model["name"] for model in data.get("models", [])])
PYIf the model name is output here, the connection is made from the WebUI container to the API. A name parsing error is a clue to check the service name/network, a connection refusal is a clue to check the address/port/waiting status, and a timeout is a clue to check the route/firewall/server status. A single error phrase does not completely determine the cause.
If HTTP 401/403 or login page returns, check proxy authentication and access policy. If the status code is success but JSON parsing fails, you may have connected to another web page instead of the Ollama API. Check whether the WebUI screen path or unnecessary /api is added to the end of the address.
Check the environment variables and the address saved in the manager together.
In your administrator account, open the Connections menu in Settings and make sure Ollama Connections is enabled. The URL must be the same as the address that was previously successful inside the container. If you have registered multiple addresses, also clean up unused servers or unresponsive addresses. Delays in one connection can affect model list loading.
If you specify an address in Compose, merge it into the configuration of the existing open-webui service as shown below. This code is not the entire Compose file and should not be erased and replaced with image, volume, and port settings.
services:
open-webui:
environment:
OLLAMA_BASE_URL: http://ollama:11434Open WebUI can maintain settings saved on the administrator screen in its database. In this case, even if you just change the environment variable and restart, the previous address may continue to be used. Modify the actual storage address of the administrator screen first, and the Compose change is reflected as docker compose up -d open-webui. The simple docker restart does not change the environment variables of an existing container.
We don’t delete data volumes or entire settings to fix a single connection. If you cannot access the administrator screen, back up your data and review the recovery procedures in the official connection error document for your version. Resetting global settings may also affect other connectivity and authentication settings.
If you’re connecting to host Ollama, you’ll also see the standby address
There is a configuration in Linux Docker Engine where host.docker.internal is not created automatically. In that case, you can specify the host gateway name by merging the entry below into your WebUI service. This setting alone will not change Ollama’s standby address.
services:
open-webui:
extra_hosts:
- "host.docker.internal:host-gateway"
environment:
OLLAMA_BASE_URL: http://host.docker.internal:11434If Ollama only listens to 127.0.0.1 on the host, it may not be reachable from containers on the bridged network. Check the listening address of port 11434 with ss -lntp on the host, and adjust the OLLAMA_HOST setting on the Ollama server when necessary. You must also set up the firewall and the access paths you want to allow.
The Ollama local API has no authentication by default. To troubleshoot connectivity issues, port 11434 is not open to the entire Internet. Connect within the same Docker network, or prefer a configuration that allows only the private routes you need. OLLAMA_ORIGINS is a setting related to the browser’s cross-origin request, so it distinguishes it from an issue where the connection itself cannot be made on the backend.
If only visible to administrators, check model access settings
If the model list is retrieved from the container but is not visible to general users, check the model access rights and public scope rather than the network. Make sure you see the same connections in your administrator and regular user accounts, and that your model isn’t disabled or restricted to specific groups. At this stage, you don’t have to wonder if you need to download the model again.
At the end, you’ll see the list display and short dialogue responses separately. If you see the list but fail to generate an answer, investigate model loading, memory, and request timeouts. By matching the failure time in the WebUI log with the same time in the Ollama log, you can narrow down which section the request went to.
docker logs --since 10m --tail 100 open-webui
# Ollama도 컨테이너로 실행한 경우
docker logs --since 10m --tail 100 ollamaDuring the writing process, we used a separate HTTP response server to check for connectivity differences between the container’s localhost and the shared network service name. This is not a verification that involves creating the actual Open WebUI screen and model. If you need basic configuration, you can continue to Open WebUI and Ollama Web Chat Configuration.
reference document
Open WebUI: Connection errors and saved settings
.jpg){kind=link}