mrsaynothing.dev
Connection refused sur 11434 : l'appelant, l'écouteur, six causes
Un curl coupe le problème en deux — le classement des causes côté serveur, le piège du localhost en conteneur, le binding LAN, et l'instance égarée qui vole le port.
■ space · la voie du texte
Connection refused = rien n'écoute sur le port 11434 là où vous avez appelé. L'OS le dit ; Ollama n'a jamais vu la requête.
Lancez curl http://localhost:11434 — Ollama is running signifie que le serveur va bien et que c'est le client qui appelle le mauvais endroit.
Refusé aussi sur l'hôte ? Parcourez les six causes ci-dessous — la plus probable d'abord, une commande chacune.
LA CARTE DE L'APPELANT
La moitié des rapports sont un problème de placement : l'écouteur va bien — l'appelant appelle depuis un endroit que l'écouteur n'atteint pas.
un conteneur sur Linux nu a besoin de --add-host=host.docker.internal:host-gateway — les propres docs de Docker nomment ce drapeau pour exactement ce cas · conteneur-vers-conteneur sur un même réseau : http://<nom-du-service>:11434
LES SIX CAUSES, CLASSÉES
Du haut vers le bas — la première ligne qui colle à votre erreur porte la réparation :
| Où vous la voyez | Cause probable | Réparation |
|---|---|---|
ollama list refuse aussi ; service inactif | Ollama n'a jamais démarré (ou est mort au boot) | sudo systemctl enable --now ollama |
| Démarre, puis refuse encore des minutes plus tard | Boucle de crash — port pris, disque plein, env mauvais | journalctl -u ollama -n 50, répare ce qu'il nomme |
| Le serveur répond sur 11435, les clients appellent 11434 | Un OLLAMA_HOST personnalisé a déplacé le port | Montrez aux clients le vrai port |
127.0.0.1 marche, localhost refuse | localhost se résout d'abord en IPv6 ::1 d'abord | Appelez 127.0.0.1, ou liez les deux |
| Hôte ok, conteneur refusé | localhost dedans = le conteneur lui-même | host.docker.internal + host-gateway |
| Conteneur-vers-conteneur refusé | Utilisé localhost au lieu du nom du service | http://<service-name>:11434 |
| Autre machine du LAN refusée | Serveur lié au loopback seulement (défaut) | OLLAMA_HOST=0.0.0.0:11434 dans la dérogation |
| Marche des jours, refusé sans prévenir | Une deuxième instance lancée à la main a volé le port | ss -ltnp, tuez l'égaré, gardez le service |
OLLAMA TOURNE-T-IL JUSTEMENT ?
Les déclinaisons bureau (macOS, Windows) font tourner Ollama en application de barre de menus, et l'on quitte plus facilement qu'on ne croit. L'installation Linux fait tourner un service systemd que reboot parfois laisse désactivé. ollama list adressé au serveur répond avec une table de modèles ; s'il répond lui aussi par une erreur de connexion, lancez le serveur et rendez le démarrage permanent :
systemctl status ollama
sudo systemctl enable --now ollama # start + survive reboots
journalctl -u ollama -n 50 # if it keeps dying, read whyvérification : systemctl is-active ollama → active · ollama list → une table de modèles
LE PORT, L'HÔTE, LE LAN
Ollama écoute sur 127.0.0.1:11434 à moins qu'on lui ait dit autre chose. Un port personnalisé : si vous avez un jour posé OLLAMA_HOST=127.0.0.1:11435, le serveur répond sur 11435 et tout client qui appelle encore 11434 se fait refuser — confirmez ce qui écoute réellement avec ss -ltn | grep 1143. Le piège IPv6 : sur certaines machines localhost se résout en ::1 d'abord, et un serveur lié seulement à 127.0.0.1 ne voit jamais ces tentatives — le test discriminant coûte deux secondes : curl http://127.0.0.1:11434 marche pendant que curl http://localhost:11434 refuse. Appelez 127.0.0.1, liez les deux, ou montrez aux clients l'IP brute.
Exposer au LAN : par défaut Ollama se lie au loopback seulement — à dessein, puisque l'API n'a aucune authentification. Posez-le dans la dérogation systemd plutôt que dans votre shell, pour que le service le voie vraiment :
sudo systemctl edit ollama
# [Service]
# Environment="OLLAMA_HOST=0.0.0.0:11434"
sudo systemctl restart ollamavérification : ss -ltn | grep 11434 → 0.0.0.0:11434 · depuis une autre machine : curl http://<host-ip>:11434 → «Ollama is running»
Deux voisins du «refused» qui sont des pannes différentes : un pare-feu qui bloque encore 11434 produit des timeouts, pas des refus — refusé veut dire un «non» actif, timeout veut dire que les paquets ne sont jamais arrivés. Et du JavaScript de navigateur qui appelle l'API depuis une autre origine a besoin de OLLAMA_ORIGINS posé : ces appels arrivent et se font refouler à la couche CORS, ce qui ressemble au même de l'autre bord.
Une connexion refusée est un problème de placement, pas un programme cassé : ce qui devrait écouter n'écoute pas, ou l'appelant appelle depuis un endroit que l'écouteur n'atteint pas.
ÇA REVIENT
Alors un processus possède le port et l'autre perd la course à répétition. 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. Tuez l'égaré, laissez le service seul propriétaire, et l'erreur s'en va pour de bon.
vérification : ss -ltnp | grep 11434 → une ligne, un PID — le service
Ollama a dépassé 181 000 étoiles GitHub en septembre 2026 — plus de machines qui le font tourner, c'est plus de ces six réponses dont la même semaine se retrouve dans le besoin. Quand le serveur répond, le GPU qu'il refuse d'utiliser est la plainte suivante la plus courante. Le triage est à un curl de distance.
connect: Connection refused du noyau a été reproduit sur une boîte de banc jetable où rien n'écoutait — avant que quelque application ne se mêle de quoi que ce soit.
fin de la carte de l'appelant · rien de fetché · tout est local