mrsaynothing.devOllama connection refused ? Le triage en 60 secondes
Connection refused signifie qu'aucun processus n'écoute sur le port 11434. Les six vraies causes, classées, plus la commande curl qui dit laquelle tu as.
L'erreur ne ment jamais sur ce qu'elle veut dire : curl: (7) Failed to connect to localhost port 11434: Connection refused est ton système d'exploitation qui signale qu'aucun processus n'écoute sur le port 11434. Ollama n'est pas « cassé », le modèle n'est pas corrompu, et la réponse réflexe d'Internet — réinstaller — passe à côté de six causes ennuyeuses qui se éliminent en une minute chacune.
Lance d'abord la commande de triage. Elle coupe le problème en deux avant que tu lises la suite :
curl http://localhost:11434
Ollama is running signifie que le serveur va bien et que c'est ton client qui appelle le mauvais endroit — passe aux questions d'hôte. Connection refused signifie que c'est le côté serveur qu'il faut soigner. J'ai reproduit le refus lui-même sur une machine de bench jetable sans rien à l'écoute : le noyau répond bash: connect: Connection refused avant même qu'une application soit impliquée.
Pourquoi Ollama répond connection refused ?
Parce qu'une connexion TCP est arrivée sur une machine où aucun socket ne détient le port 11434. C'est tout le mécanisme — l'une de ces six choses est vraie, et elles sont classées ici par fréquence, la plus probable d'abord.
Ollama tourne-t-il vraiment ?
Les versions bureautiques (macOS, Windows) font tourner Ollama comme une application dans la barre des tâches, et il est plus facile à quitter qu'on ne croit. Sous Linux, l'installation passe par un service systemd qui n'a peut-être jamais été activé après un redémarrage.
# Linux : le service est-il vivant ?
systemctl status ollama
# Le contrôle direct qui marche partout :
ollama list
Si ollama list atteint le serveur, il répond avec une table de modèles. S'il répond lui aussi une erreur de connexion, démarre le serveur et rends le démarrage permanent :
sudo systemctl enable --now ollama # Linux : démarrer + survivre aux reboots
journalctl -u ollama -n 50 # s'il meurt en boucle, lire pourquoi
Un service qui démarre et meurt aussitôt apparaît ici comme une boucle de crash, et journalctl imprime la raison — port déjà pris, disque plein, mauvais override d'environnement.
Est-ce le port, ou la machine que tu appelles ?
Ollama écoute sur 127.0.0.1:11434 sauf ordre contraire. Deux décalages classiques :
Un port personnalisé. Si toi — ou un tuto que tu as suivi — as un jour posé OLLAMA_HOST=127.0.0.1:11435, le serveur répond sur 11435 et chaque client qui appelle encore 11434 se fait refuser. Confirme ce qui écoute réellement :
ss -ltn | grep 1143
Tu dois voir une ligne avec 127.0.0.1:11434. Aucune ligne : le serveur est éteint (section précédente). Un autre port ou une autre adresse : ce sont tes clients qui ont pris du retard.
localhost contre 127.0.0.1. Sur certaines machines, localhost résout d'abord vers l'adresse IPv6 ::1, et un serveur attaché uniquement à 127.0.0.1 ne voit jamais ces tentatives. Le test qui tranche coûte deux secondes :
curl http://127.0.0.1:11434 # marche, tandis que curl http://localhost:11434 refuse
Si l'IP brute marche et pas le nom, attache le serveur aux deux ou vise 127.0.0.1 directement dans tes clients.
Pourquoi ça marche sur l'hôte mais pas depuis Docker ?
C'est la variante la plus fréquente sur le terrain — c'est pourquoi l'autocomplétion de cette erreur déborde de n8n, Open WebUI et extensions VS Code. Chaque conteneur qui appelle http://localhost:11434 s'appelle lui-même : dans le conteneur, 127.0.0.1 est le loopback du conteneur, où rien n'écoute.
| Qui appelle | Bonne URL vers l'Ollama de l'hôte |
|---|---|
| Conteneur sur Docker Desktop | http://host.docker.internal:11434 |
| Conteneur sur Linux nu | http://host.docker.internal:11434 plus --add-host=host.docker.internal:host-gateway |
| Conteneur sur le même réseau Docker | http://<nom-du-service>:11434 |
| Une autre machine du LAN | http://<ip-machine>:11434 (section suivante) |
Le flag host-gateway vient de la documentation de Docker elle-même pour exactement ce cas, et c'est la seule ligne qui règle la moitié des rapports « Ollama connection refused » venus des conteneurs.
Comment exposer Ollama aux autres machines ?
Par défaut, Ollama s'attache au loopback uniquement — voulu, puisque l'API n'a pas d'authentification. L'exposer tient en une variable d'environnement ; pose-la dans l'override systemd plutôt que dans ton shell pour que le service la voie vraiment :
sudo systemctl edit ollama
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Puis sudo systemctl restart ollama et confirme avec ss -ltn | grep 11434 — la colonne d'adresse doit afficher 0.0.0.0:11434. Deux suites qu'on saute trop souvent : un pare-feu qui bloque encore 11434 produit des timeouts plutôt que des refus (autre échec, même port), et le JavaScript d'un navigateur qui appelle l'API depuis une autre origine a besoin de OLLAMA_ORIGINS, selon la FAQ d'Ollama — les appels du navigateur arrivent et se font rejeter à la couche CORS, ce qui se voit identiquement de l'extérieur.
Un refus de connexion est un problème de placement, pas un programme cassé : quelque chose qui devrait écouter n'écoute pas, ou l'appelant appelle depuis un endroit que l'auditeur n'atteint pas.
Et si ça revient sans arrêt ?
Alors un processus détient le port et un autre perd la course à chaque fois. ss -ltnp | grep 11434 montre le processus qui tient le socket ; une deuxième instance d'Ollama lancée à la main est la voleuse habituelle. Tue l'étrangère, laisse le service comme seul propriétaire, et l'erreur disparaît.
Pour le reste du cluster : une fois le serveur répondu, le GPU qu'il refuse d'utiliser est la plainte suivante la plus courante, et faire tourner des modèles GGUF en local couvre le côté chargement. Les deux vivent dans le hub LLM local.
Ollama a dépassé 181 000 étoiles GitHub en septembre 2026 — plus de machines qui le font tourner, plus de ces six réponses recherchées la semaine même où on les tape. Le triage tient à un curl.