Fix Open WebUI Docker Connection Refused to Ollama

Q: Should I set OLLAMA_BASE_URL in the Open WebUI settings or as an environment variable?

Set `OLLAMA_BASE_URL` as a Docker environment variable during container deployment. While Open WebUI allows you to modify connections through its web interface settings menu, environment variables set the global startup default. This prevents settings resets when clearing browser cache, changing users, or recreating persistent database volumes.

Q: Is setting OLLAMA_ORIGINS="*" a security risk?

Setting `OLLAMA_ORIGINS="*"` allows any web application running in your browser to send API requests to your local Ollama instance if they know your IP address. On a secure home or local network, this risk is minimal. However, on public cloud servers, restrict `OLLAMA_ORIGINS` to your specific domain (for example, `OLLAMA_ORIGINS="https://chat.yourdomain.com"`) and use a firewall to block public access to port 11434.

Stop Docker networking errors between Open WebUI and Ollama. Clear connection refused errors with exact IP, CORS, and container configs.

Tidqom Editorial

August 4, 2026 · 5 min read

Fix Open WebUI Docker Connection Refused to Ollama

The Root Cause of Docker Loopback Connection Refused

When you spin up Open WebUI in a Docker container and point it to http://127.0.0.1:11434 or http://localhost:11434, your setup fails immediately. You get an ECONNREFUSED error or a generic web interface message stating that Ollama is unreachable.

This happens because of container network namespace isolation. Inside a Docker container, 127.0.0.1 refers to the container's own loopback interface, not the host machine running your operating system. When Open WebUI sends an HTTP GET request to http://127.0.0.1:11434, it queries port 11434 inside its own isolated Linux network namespace. Unless Ollama is installed inside that exact same container, nothing listens on that port. The container kernel responds instantly with TCP RST, triggering the open webui docker connection refused ollama failure.

terminal

+-----------------------------------------------------------------------+
| HOST MACHINE                                                          |
|                                                                       |
|  +---------------------------------+      +------------------------+  |
|  | Open WebUI Container            |      | Ollama Daemon          |  |
|  |                                 |      |                        |  |
|  | Request -> http://127.0.0.1:11434 |      | Listening on:          |  |
|  | (Looks inside THIS container)   |      | 127.0.0.1:11434        |  |
|  | Result: CONNECTION REFUSED      |      |                        |  |
|  +---------------------------------+      +------------------------+  |
+-----------------------------------------------------------------------+

To establish communication between your containerized web interface and your LLM engine, you must solve two independent networking challenges:

Routing: You must tell Open WebUI how to egress the container network bridge and target the host OS IP address.
Interface Binding: You must configure Ollama on the host to accept TCP connections on public or bridge network interfaces instead of binding strictly to 127.0.0.1.

If you change only the URL in Open WebUI without altering Ollama's listening address, your requests will traverse the Docker bridge and hit the host network interface, only to be dropped by the host kernel because Ollama is refusing non-loopback connections.

Reconfiguring the Host Ollama Daemon for Outside Access

By default, Ollama binds its API engine strictly to 127.0.0.1:11434 for local security. To allow containers on the Docker bridge network to reach it, you must force Ollama to bind to 0.0.0.0 or to the specific Docker bridge Gateway IP address (usually 172.17.0.1).

Linux (Systemd Service)

If you installed Ollama on Linux using the standard installation script, it runs as a background service via systemd. Do not attempt to export environment variables directly in your bash shell; the daemon ignores terminal environment state.

Edit the systemd service override configuration:

bash

sudo systemctl edit ollama.service

In the editor window that opens, add the following lines under the [Service] section:

ini

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

Save and exit the editor. Apply the systemd changes and restart the daemon:

bash

sudo systemctl daemon-reload
sudo systemctl restart ollama

Verify that Ollama is listening on all network interfaces by inspecting socket bindings:

bash

sudo ss -tulpn | grep 11434

The output must show 0.0.0.0:11434 or *:11434. If it still displays 127.0.0.1:11434, the service unit override did not load correctly.

macOS (Desktop Engine)

On macOS, Ollama runs as a native GUI background application. Quit Ollama completely from the top menu bar icon.

Open Terminal and execute the following to launch Ollama with expanded bindings:

bash

launchctl setenv OLLAMA_HOST "0.0.0.0:11434"
launchctl setenv OLLAMA_ORIGINS "*"

Relaunch the Ollama application from your Applications folder. To make this persistent across system reboots, add those environment variables to your shell launch profile (~/.zshrc or ~/.bash_profile) or use a launchd plist file.

Advertisement — In Article

Windows (Native Service or Application)

If you run Ollama natively on Windows outside WSL2:

Exit Ollama from the Windows system tray.
Open Windows Control Panel and navigate to System Properties > Environment Variables.
Under System Variables, create a new entry:
- Variable name: OLLAMA_HOST
- Variable value: 0.0.0.0:11434
Create a second variable for cross-origin requests:
- Variable name: OLLAMA_ORIGINS
- Variable value: *
Apply settings and restart Ollama from the Start menu.

Routing Open WebUI to Host with host.docker.internal

Now that the Ollama daemon listens on network adapters accessible outside localhost, you must instruct the Open WebUI container how to locate the host machine IP.

Docker Desktop on macOS and Windows includes a DNS entry named host.docker.internal that automatically resolves to the host's internal network gateway. Linux Docker Engine does not enable this mapping by default.

Running via Docker CLI on Linux

To connect Open WebUI docker to host Ollama under Linux, pass the --add-host flag during container creation. This maps host.docker.internal to the default network bridge gateway IP (host-gateway).

Run the container using this command structure:

bash

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

If you encounter issues where open webui can't connect to ollama despite using this flag, check the container logs to ensure the environment variable loaded correctly:

bash

docker logs open-webui | grep OLLAMA_BASE_URL

Verifying Connectivity Inside the Container

Never guess whether the container can reach the host. Test the connection from inside the running Open WebUI container using curl:

bash

docker exec -it open-webui curl http://host.docker.internal:11434/api/version

If successful, Ollama returns a JSON payload containing its current version:

json

{"version":"0.5.7"}

If this command times out or returns curl: (7) Failed to connect, the network traffic is blocked by a firewall on your host system (such as ufw, iptables, or Windows Defender Firewall) blocking port 11434 on the docker0 bridge interface.

To allow Docker bridge traffic on Linux systems using UFW:

bash

sudo ufw allow in on docker0 to any port 11434 proto tcp

Fixing OLLAMA_ORIGINS and CORS Blocks

Fixing TCP connectivity is only half the battle. When Open WebUI runs in the browser, the frontend application makes Direct Cross-Origin Resource Sharing (CORS) HTTP requests from your browser client to the backend endpoints, or the Open WebUI backend acts as a reverse proxy passing headers.

If Ollama receives a request carrying an HTTP Origin header that does not match its internal whitelist, it drops the request or returns an HTTP 403 Forbidden response. This presents as an intermittent error where Open WebUI loads its interface, but models fail to fetch or populate in the dropdown menu.

Set the OLLAMA_ORIGINS variable on the Ollama host environment to permit incoming header metadata from Open WebUI.

terminal

+------------------------------------------------------------------------+
| BROWSER / CLIENT                                                       |
| Origin: http://localhost:3000                                          |
+------------------------------------------------------------------------+
                                   |
                                   v
+------------------------------------------------------------------------+
| OLLAMA DAEMON                                                          |
| Checks: Does Origin "http://localhost:3000" match OLLAMA_ORIGINS?      |
|                                                                        |
| If OLLAMA_ORIGINS="*"                   -> Allow HTTP 200 OK           |
| If OLLAMA_ORIGINS="http://127.0.0.1"    -> Reject HTTP 403 Forbidden    |
+------------------------------------------------------------------------+

Advertisement — In Article

Common CORS Configuration Patterns

You can configure OLLAMA_ORIGINS strictly or allow broad access:

Wildcard (Best for local development networks): OLLAMA_ORIGINS="*"

Explicit Domain List (Best for hardened production): OLLAMA_ORIGINS="http://localhost:3000,http://192.168.1.150:3000,https://chat.yourdomain.com"

If Open WebUI operates behind a reverse proxy like Nginx or Caddy, ensure your reverse proxy forwards standard HTTP header parameters instead of dropping them:

nginx

# Nginx location block example for forwarding to Open WebUI
location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

If you miss these proxy headers, Open WebUI cannot validate token sessions, causing backend proxy errors when communicating with open webui ollama host docker internal routes.

Production-Ready Docker Compose Configurations

Deploying Open WebUI alongside Ollama requires evaluating architecture options based on performance, GPU acceleration needs, and maintenance preferences.

Deployment Method Matrix

Architectural Mode	Latency & Performance	Setup Complexity	GPU Driver Isolation	Recommended Use Case
Host Ollama + Containerized WebUI	Fast (Direct hardware access)	Medium	Handled natively by Host OS	Local workstations, high-performance GPU setups
Fully Containerized Network Bridge	Medium (Container overhead)	Easy	Requires NVIDIA Container Toolkit	Cloud VPS, Kubernetes, isolated environments
Containerized Host Networking Mode	Native	Easy	Handled by Host OS	Linux-only servers dedicated solely to LLM tasks

Unified Docker Compose Architecture (All-in-One Container Stack)

If you prefer to run both Ollama and Open WebUI entirely inside Docker without installing dependencies on the host OS, use this setup. It automatically establishes an isolated network bridge where Open WebUI connects to Ollama via internal container service names.

Save this content as docker-compose.yml:

yaml

version: '3.8'

services: ollama: image: ollama/ollama:latest container_name: ollama pull_policy: always tty: true restart: unless-stopped environment: - OLLAMA_KEEP_ALIVE=24h - OLLAMA_ORIGINS=* volumes: - ollama_data:/root/.ollama ports: - "11434:11434" # Uncomment below to pass NVIDIA GPUs to the Ollama container # deploy: # resources: # reservations: # devices: # - driver: nvidia # count: all # capabilities: [gpu]

open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui pull_policy: always restart: unless-stopped ports: - "3000:8080" environment: - OLLAMA_BASE_URL=http://ollama:11434 - WEBUI_SECRET_KEY=your_secure_random_string_here volumes: - open-webui_data:/app/backend/data depends_on: - ollama

volumes: ollama_data: open-webui_data:

terminal

Launch the stack using Docker Compose:

bash

docker compose up -d

In this containerized setup, notice that OLLAMA_BASE_URL uses http://ollama:11434. Docker's embedded DNS engine resolves ollama directly to the container's virtual IP on the internal network bridge. You do not need to use host.docker.internal or adjust 0.0.0.0 bindings on your physical host machine.

Docker Compose for Host-Installed Ollama

If Ollama is already running directly on your host machine to leverage native GPU drivers, use this Compose configuration:

yaml

version: '3.8'

services: open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui restart: unless-stopped ports: - "3000:8080" extra_hosts: - "host.docker.internal:host-gateway" environment: - OLLAMA_BASE_URL=http://host.docker.internal:11434 volumes: - open-webui_data:/app/backend/data

Advertisement — In Article

volumes: open-webui_data:

terminal

Step-by-Step Diagnostic Matrix and Verification Commands

When facing persistent connectivity failures, work through this step-by-step diagnostic workflow to isolate where the network drops your packets.

terminal

[Start Debugging]
       |
       v
Step 1: Is host port 11434 listening?
  [ss -tulpn | grep 11434]
       |
       +---> NO  --> Fix OLLAMA_HOST environment variable & restart service
       |
       +---> YES (0.0.0.0:11434)
       |
       v
Step 2: Can Host reach Ollama API natively?
  [curl http://127.0.0.1:11434/api/version]
       |
       +---> NO  --> Check if Ollama service is crashed/hanging
       |
       +---> YES
       |
       v
Step 3: Can Docker container resolve and ping host gateway?
  [docker exec -it open-webui curl http://host.docker.internal:11434/api/version]
       |
       +---> NO  --> Fix firewall (UFW/iptables), check --add-host flag
       |
       +---> YES
       |
       v
Step 4: Are Web API / CORS requests returning 403 Forbidden?
  [Check browser network tab for pre-flight OPTIONS request failure]
       |
       +---> YES --> Apply OLLAMA_ORIGINS="*" fix on Ollama Host
       |
       +---> NO  --> SUCCESS! Connection established.

Diagnostic Command Reference

Execute these exact terminal commands to validate every stage of the connection pipeline.

1. Check host listening status

Confirm that Ollama is bound to all interfaces and not locked strictly to loopback:

bash

# Linux
sudo ss -tulpn | grep 11434

macOS

netstat -anv | grep 11434

terminal

2. Probe host HTTP interface

Test local execution on the host:

bash

curl -i http://localhost:11434/api/tags

You should receive an HTTP/1.1 200 OK header followed by a JSON payload listing installed LLM models.

3. Test Container Egress Path

Execute a network test directly inside the running Open WebUI container environment:

bash

docker exec -it open-webui curl -i http://host.docker.internal:11434/api/tags

If this returns 200 OK, your Docker networking, DNS resolution, and binding configurations are correct. If it hangs or returns a connection timeout, the request is hitting a firewall rule on the host system.

4. Trace Web UI Application Environment Variables

Verify what environment flags Open WebUI recognized during process startup:

bash

docker exec -it open-webui printenv | grep OLLAMA

Ensure the output displays OLLAMA_BASE_URL=http://host.docker.internal:11434. If it displays http://127.0.0.1:11434, remove the container and recreate it with the correct -e environment parameters.

Frequently Asked Questions

Why does Open WebUI connect fine on Windows Docker Desktop but fail on Linux?

Docker Desktop for Windows and macOS runs inside a light virtual machine managed by Docker, which automatically provisions internal DNS routes like host.docker.internal. Native Docker Engine on Linux runs directly on the host kernel without this virtual networking wrapper. On Linux, you must explicitly pass --add-host=host.docker.internal:host-gateway to map the host's bridge IP address to the DNS host entry.

Should I set OLLAMA_BASE_URL in the Open WebUI settings or as an environment variable?

Set OLLAMA_BASE_URL as a Docker environment variable during container deployment. While Open WebUI allows you to modify connections through its web interface settings menu, environment variables set the global startup default. This prevents settings resets when clearing browser cache, changing users, or recreating persistent database volumes.

Is setting OLLAMA_ORIGINS="*" a security risk?

Setting OLLAMA_ORIGINS="*" allows any web application running in your browser to send API requests to your local Ollama instance if they know your IP address. On a secure home or local network, this risk is minimal. However, on public cloud servers, restrict OLLAMA_ORIGINS to your specific domain (for example, OLLAMA_ORIGINS="https://chat.yourdomain.com") and use a firewall to block public access to port 11434.

Why do I see connection errors only when trying to download or pull new models?

Model pulling streams long-running HTTP responses. If Open WebUI successfully lists models but drops connections during downloads, your HTTP proxy or gateway is timing out. If you use Nginx, add proxy_read_timeout 3600; and proxy_connect_timeout 3600; to your location block. Also, ensure your host disk space isn't running low; Ollama will abruptly close connections if it runs out of space while allocating model layers.

مواضيع مقترحة · Suggested Topics

استكشف مواضيع ومحاور ذات صلة بهذا المقال — روابط داخلية لتعميق قراءتك.

Topics

#Open Webui Docker Connection Refused Ollama #Open Webui Can't Connect To Ollama #Open Webui Ollama Host Docker Internal #Ollama Origins Open Webui Docker Fix #Connect Open Webui Docker To Host Ollama #Docker Loopback Network Fix

Explore

More in AI Tools →All articles Trending now

The Daily Pulse

Newsletter delivery is not connected yet. This form only saves your address in this browser; no email is sent.

Get concise, source-linked technology notes without the hype.