Open WebUI ou n8n dans Docker n'arrive pas à se connecter à Ollama

Par MV2 de Munim, Inc. Vérifié le 12 octobre 2026 d'après la documentation d'Open WebUI et de n8n et le code source d'Ollama. Cette page a été traduite avec une IA à partir de l'original en anglais ; en cas d'écart, l'original fait foi.

Erreurs typiques : Open WebUI affiche « Ollama: Network Problem » ou « Server Connection Error », ou ses journaux indiquent Connect call failed ('127.0.0.1', 11434). Le test de l'identifiant Ollama dans n8n échoue avec ECONNREFUSED 127.0.0.1:11434 ou ECONNREFUSED ::1:11434. Dify, Flowise et AnythingLLM affichent des erreurs « connection refused » similaires.

La cause : dans un conteneur, localhost et 127.0.0.1 désignent le conteneur lui-même, pas votre ordinateur. Par défaut, Ollama écoute sur 127.0.0.1:11434 sur l'hôte, donc un conteneur qui utilise http://localhost:11434 frappe à la mauvaise porte.

La solution rapide que donnent beaucoup de guides est OLLAMA_HOST=0.0.0.0. Elle fonctionne, mais elle ouvre aussi Ollama, qui n'a pas d'authentification, à tous les appareils de votre réseau. Essayez d'abord les solutions ci-dessous.

D'abord, tester : une commande

Depuis l'hôte, vérifiez qu'Ollama tourne : curl http://127.0.0.1:11434/api/version. Testez ensuite l'adresse qu'utilise votre application depuis un conteneur jetable :

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

Une réponse comme {"version":"0.x.y"} signifie que cette URL fonctionne depuis les conteneurs. « Connection refused » ou un délai dépassé signifie que non ; lisez la suite selon votre installation. L'image d'Open WebUI contient curl, vous pouvez donc aussi lancer docker exec open-webui curl -s http://host.docker.internal:11434/api/version.

Quelle solution pour votre installation

Votre installation	URL de base dans l'application	Remarques
Docker Desktop (Mac ou Windows), application Ollama sur l'hôte	`http://host.docker.internal:11434`	Fonctionne tel quel ; Ollama peut rester sur 127.0.0.1. Solution 1.
Linux, Ollama installé sur l'hôte, application dans Docker	`http://host.docker.internal:11434` plus `--add-host`	Ollama doit aussi écouter là où les conteneurs peuvent le joindre. Solution 2 ou 3.
Ollama et l'application dans le même fichier Compose	`http://ollama:11434` (le nom du service)	La meilleure option ; Ollama n'a besoin d'aucun port publié. Solution 4.
Ollama dans Docker, application installée sur l'hôte (par exemple n8n via npm)	`http://127.0.0.1:11434`	Publiez avec `-p 127.0.0.1:11434:11434`. Utilisez 127.0.0.1 et non localhost pour éviter l'erreur `::1`.

Solution 1 : Docker Desktop (Mac, Windows)

Docker Desktop fournit host.docker.internal à chaque conteneur et le redirige vers votre ordinateur : réglez donc l'URL Ollama de l'application sur http://host.docker.internal:11434. Pour Open WebUI, c'est la variable d'environnement OLLAMA_BASE_URL (ou « Admin Settings » → « Connections »). Dans n8n, modifiez la « Base URL » de l'identifiant Ollama. Inutile de changer OLLAMA_HOST côté 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 limite Open WebUI à cet ordinateur. N'utilisez -p 3000:8080 que si d'autres appareils doivent l'ouvrir, et dans ce cas désactivez les inscriptions ouvertes. Pour y accéder depuis votre téléphone sans l'ouvrir au réseau, voir Open WebUI via Tailscale Serve.

Solution 2 : Linux, la voie sûre la plus simple : le réseau de l'hôte pour l'application

Sous Linux, --network=host place le conteneur sur le réseau de l'hôte : 127.0.0.1:11434 est alors vraiment l'Ollama de l'hôte, et Ollama peut rester lié à localhost. La documentation d'Open WebUI donne cette solution ; notez que le port devient 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

Ouvrez http://localhost:8080. Avec le réseau de l'hôte, Open WebUI écoute sur le port 8080 comme un programme ordinaire, et ici le pare-feu de l'hôte (ufw, firewalld) s'applique bien. N'autorisez le 8080 que depuis là où vous en avez besoin.

Solution 3 : Linux, host.docker.internal avec Ollama joignable uniquement depuis les conteneurs

Sous Linux, --add-host=host.docker.internal:host-gateway (ou extra_hosts: ["host.docker.internal:host-gateway"] dans Compose) fait pointer ce nom vers l'adresse du pont Docker, en général 172.17.0.1. Un Ollama sur 127.0.0.1 n'écoute pas à cette adresse : il doit donc écouter plus largement, et un pare-feu doit tenir à l'écart tout le monde sauf les conteneurs :

Faites écouter Ollama sur toutes les interfaces : sudo systemctl edit ollama.service, ajoutez
```
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
```
puis sudo systemctl daemon-reload && sudo systemctl restart ollama.
N'autorisez que les réseaux de Docker, puis bloquez le reste (exemple avec ufw ; les réseaux par défaut de Docker sont dans 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
```
L'ordre compte : la règle allow doit venir en premier (sudo ufw status numbered montre l'ordre). Si ufw est actif avec son « deny incoming » par défaut, c'est la règle allow qui laisse entrer les conteneurs. Un conteneur bloqué voit en général un délai dépassé plutôt que « refused ».
Depuis un autre appareil de votre réseau, curl http://<this machine's LAN IP>:11434/api/version (avec l'adresse IP locale de cette machine) doit maintenant échouer, alors que le test du conteneur jetable ci-dessus réussit.

Contrairement aux ports publiés avec docker -p, qui contournent ufw, un Ollama installé sur l'hôte est un programme ordinaire : ces règles ufw s'appliquent donc bien à lui.

Solution 4 : mettre Ollama dans le même fichier Compose

Les conteneurs d'un même réseau Compose se joignent par le nom du service : Ollama n'a donc besoin d'aucun port publié, et rien hors de Docker ne peut l'atteindre :

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: {}

(Le commentaire du fichier signifie : pas de « ports: », seuls les conteneurs de ce réseau peuvent le joindre.) n8n, Dify, Flowise ou AnythingLLM dans le même fichier utilisent aussi http://ollama:11434. Pour un GPU, ajoutez au service ollama la réservation de périphérique indiquée dans la documentation Docker d'Ollama. Si l'application tourne dans un autre projet Compose, rattachez les deux à un même réseau externe partagé.

Toujours en échec ?

n8n sur l'hôte, ECONNREFUSED ::1:11434 : localhost a été résolu en IPv6 alors qu'Ollama écoute en IPv4. La documentation de n8n conseille 127.0.0.1 au lieu de localhost.
Podman : le nom d'hôte est host.containers.internal.
« 403 Forbidden » au lieu de « refused » : ce n'est pas un problème de réseau : Ollama a répondu, et a refusé. Il y a deux causes habituelles. (1) Une page web ou une extension de navigateur appelle Ollama et OLLAMA_ORIGINS la bloque ; voir la vérification dans le navigateur (en anglais). Open WebUI, n8n et Dify appellent Ollama depuis leur serveur et n'ont pas besoin d'OLLAMA_ORIGINS. (2) Un proxy inverse ou un tunnel transmet son propre nom d'hôte à un Ollama qui écoute sur 127.0.0.1. Dans ce mode, Ollama n'accepte que des noms Host de type localhost, ce qui explique que host.docker.internal fonctionne (il se termine par .internal). Faites envoyer Host: localhost:11434 par le proxy, comme dans les exemples de la FAQ d'Ollama. Tailscale Serve se heurte à la même vérification ; voir pourquoi tailscale serve renvoie 403.
Ça marche, mais lentement : voir Ollama slow or not using the GPU (en anglais).

Une fois la connexion établie, vérifiez que vous n'avez pas ouvert plus que prévu : lancez le script gratuit local-ai-checkup (lecture seule, rien n'est envoyé hors de la machine), qui indique l'adresse d'écoute d'Ollama, les ports Docker publiés et les versions. Voir aussi Mon Ollama est-il exposé ?

Vous préférez une vérification faite pour vous ?

MV2 de Munim, Inc. propose un bilan d'IA locale à 49 USD pour une machine, ou un bilan petit bureau à 199 USD pour jusqu'à 5 machines ou un serveur Ollama, Open WebUI ou n8n partagé. Vous recevez un rapport écrit sur ce qui est exposé, risqué ou lent et sur ce qu'il faut corriger en premier, avec les commandes exactes pour votre système. Le rapport est rédigé en anglais. Voir un exemple de rapport (en anglais). Payer 49 USD ou payer 199 USD sur Stripe, puis envoyez à munimversion2@gmail.com la sortie de python3 local_ai_checkup.py --json, votre système d'exploitation et l'usage que vous en faites. MV2 ne demande jamais de mots de passe, de clés ni d'accès à distance.