Open WebUI ou n8n no Docker não consegue conectar ao Ollama

Por MV2 da Munim, Inc. Conferido em 12 de outubro de 2026 com a documentação do Open WebUI e do n8n e o código-fonte do Ollama. Esta página foi traduzida com IA a partir do original em inglês; em caso de divergência, vale o original.

Erros típicos: o Open WebUI mostra "Ollama: Network Problem" ou "Server Connection Error", ou os logs dizem Connect call failed ('127.0.0.1', 11434). O teste da credencial do Ollama no n8n falha com ECONNREFUSED 127.0.0.1:11434 ou ECONNREFUSED ::1:11434. Dify, Flowise e AnythingLLM dão erros parecidos de "connection refused".

A causa: dentro de um contêiner, localhost e 127.0.0.1 são o próprio contêiner, não o seu computador. Por padrão, o Ollama escuta em 127.0.0.1:11434 no host, então um contêiner que usa http://localhost:11434 está batendo na porta errada.

A solução rápida que muitos guias dão é OLLAMA_HOST=0.0.0.0. Funciona, mas também abre o Ollama, que não tem login, para todos os dispositivos da sua rede. Tente antes as soluções abaixo.

Primeiro, teste: um comando

No host, confira se o Ollama está no ar: curl http://127.0.0.1:11434/api/version. Depois teste o endereço que o seu app usa de dentro de um contêiner descartável:

docker run --rm --add-host=host.docker.internal:host-gateway curlimages/curl -s http://host.docker.internal:11434/api/version

Uma resposta como {"version":"0.x.y"} significa que essa URL funciona a partir dos contêineres. "Connection refused" ou um timeout significa que não; continue lendo conforme a sua configuração. A imagem do Open WebUI inclui o curl, então você também pode rodar docker exec open-webui curl -s http://host.docker.internal:11434/api/version.

Qual solução serve para a sua configuração

A sua configuração	URL base no app	Observações
Docker Desktop (Mac ou Windows), app do Ollama no host	`http://host.docker.internal:11434`	Funciona de cara; o Ollama pode continuar em 127.0.0.1. Solução 1.
Linux, Ollama instalado no host, app no Docker	`http://host.docker.internal:11434` mais `--add-host`	O Ollama também precisa escutar onde os contêineres alcançam. Solução 2 ou 3.
Ollama e o app no mesmo arquivo Compose	`http://ollama:11434` (o nome do serviço)	A melhor opção; o Ollama não precisa de porta publicada. Solução 4.
Ollama no Docker, app instalado no host (por exemplo, n8n via npm)	`http://127.0.0.1:11434`	Publique com `-p 127.0.0.1:11434:11434`. Use 127.0.0.1, não localhost, para evitar o erro `::1`.

Solução 1: Docker Desktop (Mac, Windows)

O Docker Desktop oferece host.docker.internal a todos os contêineres e o encaminha para o seu computador, então defina a URL do Ollama no app como http://host.docker.internal:11434. No Open WebUI, é a variável de ambiente OLLAMA_BASE_URL (ou "Admin Settings" → "Connections"). No n8n, edite a "Base URL" da credencial do Ollama. Não é preciso mudar o OLLAMA_HOST do Ollama.

docker run -d -p 127.0.0.1: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

127.0.0.1:3000 restringe o Open WebUI a este computador. Use -p 3000:8080 só se outros dispositivos precisarem abri-lo e, nesse caso, desative os cadastros abertos. Para acessar pelo celular sem abri-lo para a rede, veja Open WebUI pelo Tailscale Serve.

Solução 2: Linux, o jeito seguro mais simples: rede do host para o app

No Linux, --network=host coloca o contêiner na rede do host, então 127.0.0.1:11434 é de fato o Ollama do host e o Ollama pode continuar vinculado ao localhost. A documentação do Open WebUI traz essa solução; repare que a porta passa a ser 8080:

docker run -d --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

Abra http://localhost:8080. Com a rede do host, o Open WebUI escuta na porta 8080 como um programa comum, e aqui o firewall do host (ufw, firewalld) vale. Libere a 8080 só a partir de onde você precisa.

Solução 3: Linux, host.docker.internal com o Ollama acessível só pelos contêineres

No Linux, --add-host=host.docker.internal:host-gateway (ou extra_hosts: ["host.docker.internal:host-gateway"] no Compose) aponta esse nome para o endereço da bridge do Docker, normalmente 172.17.0.1. O Ollama em 127.0.0.1 não escuta ali, então ele precisa escutar de forma mais ampla, e um firewall deve barrar todo mundo menos os contêineres:

Faça o Ollama escutar em todas as interfaces: sudo systemctl edit ollama.service, adicione
```
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
```
e depois sudo systemctl daemon-reload && sudo systemctl restart ollama.
Libere só as redes do Docker e bloqueie o resto (exemplo com ufw; as redes padrão do Docker ficam em 172.16.0.0/12):
```
sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp
sudo ufw deny 11434/tcp
```
A ordem importa: a regra allow precisa vir primeiro (sudo ufw status numbered mostra a ordem). Se o ufw está ativo com o "deny incoming" padrão, é a regra allow que deixa os contêineres entrarem. Um contêiner bloqueado costuma ver um timeout, e não "refused".
De outro dispositivo da sua rede, curl http://<this machine's LAN IP>:11434/api/version (com o IP desta máquina na rede local) agora deve falhar, enquanto o teste do contêiner descartável acima funciona.

Diferente das portas publicadas com docker -p, que passam por fora do ufw, o Ollama instalado no host é um programa comum, então essas regras do ufw valem para ele.

Solução 4: coloque o Ollama no mesmo arquivo Compose

Contêineres na mesma rede do Compose se alcançam pelo nome do serviço, então o Ollama não precisa de porta publicada e nada fora do Docker consegue alcançá-lo:

services:
  ollama:
    image: ollama/ollama
    volumes: [ "ollama:/root/.ollama" ]
    # no "ports:" - only containers on this network can reach it
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    ports: [ "127.0.0.1:3000:8080" ]
    volumes: [ "open-webui:/app/backend/data" ]
volumes:
  ollama: {}
  open-webui: {}

(O comentário no arquivo diz: sem "ports:", só contêineres desta rede conseguem alcançá-lo.) n8n, Dify, Flowise ou AnythingLLM no mesmo arquivo também usam http://ollama:11434. Para usar uma GPU, adicione ao serviço ollama a reserva de dispositivo da documentação do Ollama para Docker. Se o app roda em outro projeto do Compose, conecte os dois a uma mesma rede externa compartilhada.

Ainda falhando?

n8n no host, ECONNREFUSED ::1:11434: localhost foi resolvido para IPv6 e o Ollama escuta em IPv4. A documentação do n8n sugere 127.0.0.1 no lugar de localhost.
Podman: o nome do host é host.containers.internal.
"403 Forbidden" em vez de "refused": não é problema de rede: o Ollama respondeu e recusou. Há duas causas comuns. (1) Uma página web ou extensão do navegador chama o Ollama e o OLLAMA_ORIGINS a bloqueia; veja a verificação no navegador (em inglês). Open WebUI, n8n e Dify chamam o Ollama a partir do servidor deles e não precisam de OLLAMA_ORIGINS. (2) Um proxy reverso ou túnel repassa o próprio nome de host a um Ollama que escuta em 127.0.0.1. Nesse modo, o Ollama só aceita nomes de Host no estilo localhost, e é por isso que host.docker.internal funciona (termina em .internal). Faça o proxy enviar Host: localhost:11434, como fazem os exemplos do FAQ do Ollama. O Tailscale Serve esbarra na mesma verificação; veja por que o tailscale serve retorna 403.
Funciona, mas lento: veja Ollama slow or not using the GPU (em inglês).

Depois que conectar, confira se você não abriu mais do que pretendia: rode o script gratuito local-ai-checkup (só lê e não envia nada para fora da máquina), que mostra o endereço em que o Ollama escuta, as portas publicadas do Docker e as versões. Veja também Meu Ollama está exposto?

Prefere que alguém verifique para você?

MV2 da Munim, Inc. faz uma verificação de IA local por US$ 49 para uma máquina, ou uma verificação para pequenos escritórios por US$ 199 para até 5 máquinas ou um servidor compartilhado de Ollama, Open WebUI ou n8n. Você recebe um relatório escrito do que está exposto, arriscado ou lento e do que corrigir primeiro, com os comandos exatos para o seu sistema operacional. O relatório é em inglês. Veja um relatório de exemplo (em inglês). Pague US$ 49 ou pague US$ 199 no Stripe e depois envie para munimversion2@gmail.com a saída de python3 local_ai_checkup.py --json, o seu sistema operacional e para que você o usa. MV2 nunca pede senhas, chaves ou acesso remoto.