Port Ollama : valeur par défaut 11434, comment le modifier et résoudre les conflits

Ollama écoute sur le port 11434 par défaut, via HTTP, lié à l’adresse de bouclage (loopback) 127.0.0.1. Ainsi, l’URL de base de l’API sur la machine elle-même est http://127.0.0.1:11434. Comme il est lié à l’adresse de bouclage plutôt qu’à toutes les interfaces, aucune machine extérieure ne peut y accéder tant que vous ne modifiez pas explicitement l’adresse de liaison.

Ce qui s’exécute réellement sur le port 11434

Le port 11434 héberge le serveur HTTP d’Ollama — le même processus que celui qui ollama serve démarre, et le même que l’application de bureau lance en arrière-plan. Tous les composants d’Ollama communiquent avec lui : l’interface en ligne de commande (CLI), la fenêtre de discussion de l’application de bureau, ainsi que tout client tiers que vous y pointez. Ollama l’interface en ligne de commande (CLI), la fenêtre de discussion sur le bureau et tout client tiers que vous y pointez.

Notez la ligne correspondant à /api/pull et /api/delete. Toute personne pouvant atteindre ce port peut télécharger sur votre disque des modèles de plusieurs gigaoctets ou supprimer ceux que vous possédez déjà. Voilà, en une phrase, la problématique de sécurité, et c’est précisément pourquoi la liaison par défaut se fait uniquement sur l’adresse de bouclage. Si vous hésitez encore sur les modèles à installer localement, le Liste des modèles Ollama répertorie les modèles disponibles ainsi que leur taille respective.

OLLAMA_HOST : la seule variable qui contrôle le port

L’adresse de liaison et le port proviennent d’une seule variable d’environnement, OLLAMA_HOST. Il n’existe aucune configuration séparée du port ni de fichier de configuration permettant de la remplacer.

Indiquez-la toujours sous la forme hôte:port. Certaines versions acceptent des formes abrégées, mais la notation explicite « hôte:port » garantit un comportement cohérent sur toutes les versions.

Un piège courant touche presque tous les utilisateurs : OLLAMA_HOST est lue à la fois par le client et par le serveur. Si vous déplacez le serveur sur le port 11435, mais que votre terminal conserve encore la valeur par défaut, ollama list échouera avec une erreur de connexion alors que le serveur est parfaitement fonctionnel. Définissez la variable aux deux endroits, ou exécutez l’interface en ligne de commande (CLI) comme suit : OLLAMA_HOST=127.0.0.1:11435 ollama list.

Modifier le port d’Ollama sous Linux

Le script d’installation Linux enregistre un service systemd, donc les variables d’environnement définies dans votre interpréteur de commandes sont sans effet — vous devez les placer dans l’unité systemd. Utilisez plutôt un fichier de substitution (drop-in override) plutôt que de modifier directement le fichier d’unité fourni, car les mises à jour du paquet l’écraseront :

sudo systemctl edit ollama.service

Ajoutez ce bloc (sur les versions récentes de systemd, placez-le entre les commentaires ### Tout ce qui se trouve ici... ) :

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

Cela écrit le fichier /etc/systemd/system/ollama.service.d/override.conf. Appliquez la modification :

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo systemctl status ollama

Ajoutez une Environment= ligne par variable — une deuxième ligne ne remplace pas la première. Si vous déplacez également le stockage des modèles, Environment="OLLAMA_MODELS=/mnt/models" doit être placée dans le même bloc.

Si vous lancez ollama serve manuellement

sans impliquer systemd, il suffit de l’exporter ainsi : OLLAMA_HOST=0.0.0.0:11434 ollama serve. Assurez-vous d’avoir d’abord arrêté le service systemd (sudo systemctl stop ollama) ; sinon, les deux processus entreront en conflit sur le port.

Modifier le port d’Ollama sous macOS

L’application macOS est lancée par la session graphique (GUI), qui n’hérite pas de votre profil shell. L’exportation de la variable dans OLLAMA_HOST le fichier .zshrc modifie bien l’interface CLI, mais pas le serveur en arrière-plan. Utilisez plutôt launchctl :

launchctl setenv OLLAMA_HOST "0.0.0.0:11434"

Ensuite, quittez Ollama via l’icône de la barre de menus, puis relancez-le. La nouvelle valeur ne s’applique qu’aux processus démarrés ultérieurement.

launchctl setenv ne pas survit pas à un redémarrage. Pour une modification permanente, vous devez la réexécuter au moment de la connexion — par exemple à l’aide d’un LaunchAgent (fichier plist), ou d’un élément de démarrage qui exécute cette commande. Les versions récentes de l’application macOS exposent également un interrupteur d’accès réseau dans les paramètres ; si votre version en dispose, privilégiez-le, car il persiste correctement. Vérifiez d’abord le panneau de paramètres intégré de l’application avant de créer un LaunchAgent, et consultez la documentation relative à Guide complet d’Ollama ce qui y est configuré.

Modifier le port d’Ollama sous Windows

Sur Windows, Ollama s’exécute comme un processus utilisateur normal avec une icône dans la zone de notification, donc une variable d’environnement au niveau utilisateur suffit.

1. Presse Win, tapez variables d’environnement, puis ouvrez Modifier les variables d’environnement système → Variables d’environnement…
2. Sous Variables utilisateur, cliquez sur Nouveau.
3. Nom : OLLAMA_HOSTValeur : 0.0.0.0:11434 (ou le port de votre choix).
4. Cliquez sur OK dans les deux boîtes de dialogue.
5. Faites un clic droit sur l’icône Ollama dans la zone de notification, puis choisissez « Quitter », puis relancez Ollama depuis le menu Démarrer.

L’étape 5 est celle que les utilisateurs sautent le plus souvent. Fermer la fenêtre n’arrête pas le serveur, qui continue de s’exécuter avec l’ancienne valeur. De façon équivalente, depuis un terminal : setx OLLAMA_HOST "0.0.0.0:11434" — toutefois, la commande setx n’affecte que les processus lancés après après son exécution, donc la procédure de fermeture puis de relancement reste indispensable. Si vous configurez cela pour la première fois, le guide d’installation d’Ollama vous accompagne pas à pas dans l’utilisation de l’installeur Windows.

Vérifier que le serveur écoute bien

Deux vérifications, dans cet ordre : quelque chose est-il déjà lié au port, et s’agit-il bien d’Ollama ?

Examinez attentivement la colonne « adresse locale ». 127.0.0.1:11434 signifie bouclage uniquement — aucune machine distante ne pourra jamais se connecter, quelle que soit la configuration du pare-feu. 0.0.0.0:11434 ou *:11434 signifie toutes les interfaces.

Rendre Ollama accessible depuis d’autres machines

L’association à 0.0.0.0 est nécessaire, mais généralement insuffisante. Trois conditions doivent être remplies simultanément : le serveur doit être associé à une adresse non locale (non bouclage), le pare-feu hôte doit autoriser les connexions entrantes TCP sur ce port, et le client doit utiliser l’adresse IP locale (LAN) de l’hôte plutôt que localhost.

Règles de pare-feu

Restreignez la portée de la règle à votre sous-réseau autant que possible, comme dans l’exemple ufw, plutôt que d’autoriser l’accès depuis n’importe où.

Les implications pour la sécurité, clairement exposées

L’API Ollama ne comporte aucune authentification, aucune clé API ni aucun chiffrement TLS. Liaison à 0.0.0.0 ce qui accorde un contrôle total à toute personne pouvant router vers cette adresse : exécution d’inférences, lecture de la liste des modèles, téléchargement de nouveaux modèles ou suppression des modèles existants. Les instances Ollama exposées sur Internet sont rapidement détectées par des outils d’analyse automatisés, car le port 11434 est bien connu.

Options plus sûres, classées approximativement par ordre croissant d’effort requis :

• Tunnel SSH — conservez l’association à l’adresse de bouclage et effectuez une redirection : ssh -L 11434:127.0.0.1:11434 utilisateur@serveur. Rien n’est exposé ; le client communique avec son propre localhost.
• Réseau superposé (overlay) — Tailscale, WireGuard ou solution similaire. Associez le serveur à l’adresse IP de l’interface superposée afin que seuls les appareils appartenant à votre réseau privé (tailnet) puissent s’y connecter.
• Proxy inverse — Caddy ou nginx placé en amont, gérant la terminaison TLS et appliquant une authentification basique ou un jeton porteur (bearer token), tandis qu’Ollama lui-même reste associé à l’adresse de bouclage.

Si vous hésitez entre l’utilisation partagée d’un serveur domestique dédié et le paiement à l’usage (par jeton), le calculateur du seuil de rentabilité entre auto-hébergement et utilisation d’une API quantifie précisément ce compromis, et le Calculateur de VRAM vous indique si la machine que vous souhaitez partager peut effectivement charger le modèle souhaité.

Diagnostiquer un conflit de port

Le symptôme est un échec au démarrage mentionnant l’adresse concernée, par exemple :

Erreur : listen tcp 127.0.0.1:11434 : bind : adresse déjà utilisée

Identifiez le processus propriétaire du port :

# Linux
sudo ss -tlnp | grep 11434

# macOS
lsof -nP -iTCP:11434 -sTCP:LISTEN

# Windows — récupérez d’abord le PID, puis identifiez le processus
netstat -ano | findstr :11434
tasklist /FI "PID eq 12345"

En pratique, la cause est presque toujours Ollama lui-même, lancé deux fois. Voici les cas les plus fréquents :

• L’application bureau est déjà active dans la zone de notification (tray) ou la barre de menus, et vous avez saisi la commande ollama serve dans un terminal. Le serveur intégré à l’application fonctionne correctement — utilisez-le simplement.
• Sur Linux, le service systemd est actif et vous avez lancé manuellement la commande ollama serve . Arrêtez-en un des deux : sudo systemctl stop ollama.
• Un conteneur Docker publie le port -p 11434:11434 et occupe ainsi le port hôte. Vérifiez-le avec la commande docker ps.

Si un autre logiciel utilise réellement ce port, modifiez plutôt la configuration d’Ollama que de tenter de le faire cohabiter — choisissez un port élevé libre, par exemple 127.0.0.1:11435 et définissez la variable d’environnement OLLAMA_HOST comme décrit précédemment. N’oubliez pas de mettre à jour l’URL de base de chaque client, y compris toute configuration SDK compatible OpenAI.

Docker et WSL

Dans le conteneur officiel, le serveur est déjà associé à 0.0.0.0:11434 par défaut, donc vous ne choisissez que la correspondance côté hôte : docker run -d -p 127.0.0.1:11434:11434 --name ollama ollama/ollama le maintient local, tandis que -p 11434:11434 l’expose sur toutes les interfaces hôtes. Pour modifier le port côté hôte, changez uniquement le premier nombre — -p 11435:11434 — et laissez le port interne du conteneur inchangé.

Depuis WSL2 vers une instance Ollama exécutée sur l’hôte Windows, localhost ne résout pas toujours en l’adresse de l’hôte. Liez Ollama côté Windows à 0.0.0.0:11434, autorisez le port dans le pare-feu Windows Defender, puis connectez-vous depuis WSL à l’aide de l’adresse IP hôte figurant dans /etc/resolv.conf ou de l’adresse réseau miroir, selon votre configuration WSL.

Questions fréquemment posées

Existe-t-il une variable d’environnement OLLAMA_PORT ?

Non. Le port et l’adresse de liaison sont tous deux définis via OLLAMA_HOST, spécifiée sous la forme hôte:port. Définir OLLAMA_PORT n’a aucun effet — Ollama l’ignore et continue d’utiliser le port 11434, ce qui explique pourquoi la modification semble échouer en silence.

J’ai défini OLLAMA_HOST sur 0.0.0.0, mais les machines distantes ne parviennent toujours pas à se connecter. Pourquoi ?

Vérifiez les trois couches dans cet ordre. Assurez-vous que le serveur est effectivement lié à 0.0.0.0 et non à 127.0.0.1 en utilisant ss, lsof ou netstat; vérifiez que le pare-feu hôte autorise les connexions entrantes TCP sur ce port ; et confirmez que le client utilise l’adresse IP locale (LAN) de l’hôte, et non localhost. La cause la plus fréquente est un redémarrage incomplet du processus Ollama après avoir défini la variable.

Modifier le port empêche-t-il le fonctionnement de l’interface CLI ollama ?

Cela peut arriver. La CLI lit la même variable OLLAMA_HOST pour déterminer où se connecter ; ainsi, si le serveur a changé de port mais que votre interpréteur de commandes n’a pas été mis à jour, des commandes telles que ollama list échouent avec une erreur de connexion. Définissez également cette variable dans le profil de votre interpréteur de commandes, ou préfixez chaque commande individuelle avec celle-ci.

Puis-je exécuter deux instances Ollama sur des ports différents ?

Oui — lancez chacune avec une valeur différente de OLLAMA_HOST. Elles partageront le même répertoire de modèles, sauf si vous leur attribuez également un chemin OLLAMA_MODELS distinct. Notez que les deux instances chargent les poids sur la même carte graphique : deux modèles volumineux exécutés simultanément se feront concurrence pour la mémoire vidéo (VRAM) ; la référence Exigences en VRAM selon le modèle indique précisément la marge disponible.

Quelle URL de base les clients compatibles OpenAI doivent-ils utiliser ?

Renseignez l’URL de base du SDK sur http://localhost:11434/v1 (en ajustant l’hôte et le port si vous les avez modifiés). La plupart des clients exigent également que le champ clé API soit renseigné, même si Ollama l’ignore : fournissez donc une chaîne factice quelconque, telle que Ollama.

Est-il sécurisé d’exposer le port 11434 à Internet ?

Non. Aucune authentification ni chiffrement intégrés ne sont fournis, et l’API exposée permet notamment de télécharger et de supprimer des modèles. Si vous avez besoin d’un accès distant, privilégiez un tunnel SSH ou un réseau superposé privé, ou placez un proxy inverse authentifiant avec chiffrement TLS devant Ollama. Si l’accès distant constitue votre besoin principal, comparez le coût d’exécution avec celui de l’inférence hébergée proposée par Calculateur des coûts d’API avant de développer votre propre infrastructure.

Référence rapide

Une fois le port configuré, la question suivante porte généralement sur le modèle à déployer derrière celui-ci — les meilleurs modèles locaux pour Ollama dresse un état des options actuelles par niveau matériel.