~/ / Articles sur l'IA / LLM locaux sur un VPS / Placer nginx devant Ollama : authentification basique, HTTPS et réglages pour le streaming

Placer nginx devant Ollama : authentification basique, HTTPS et réglages pour le streaming

Par défaut, Ollama écoute sur le serveur lui-même, ce qui est l'endroit le plus sûr. Lorsqu'une autre machine doit pouvoir l'atteindre, la FAQ d'Ollama renvoie vers un serveur proxy tel que nginx. Cet article construit cette configuration à partir de la documentation de nginx : un mot de passe, HTTPS, les réglages qui comptent pour les réponses diffusées en continu, et un pare-feu qui ferme les autres accès.

Publié: 2026-10-26 · 6 min de lecture · Vérifié par rapport à la documentation officielle d'Ollama et de nginx le 2026-10-26. Les valeurs par défaut des directives dépendent de la version de nginx : vérifiez la version que vous utilisez.

Ce que dit la FAQ d'Ollama

La FAQ d'Ollama indique qu'Ollama exécute un serveur HTTP et qu'il peut être exposé à l'aide d'un serveur proxy tel que Nginx. Son exemple écoute sur le port 80, définit un server_name, transmet les requêtes avec proxy_pass http://localhost:11434 et fixe l'en-tête Host à localhost:11434.

La page de la FAQ que nous avons consultée ne décrit aucune authentification pour le serveur Ollama. C'est pourquoi le mot de passe doit venir du proxy placé devant lui. Par défaut, Ollama se lie à 127.0.0.1 sur le port 11434 ; un nginx installé sur le même serveur peut donc l'atteindre sans modifier cette adresse.

Un mot de passe avec l'authentification basique

Le module ngx_http_auth_basic_module limite l'accès en vérifiant un nom d'utilisateur et un mot de passe. Deux directives font le travail : auth_basic, dont la chaîne sert de realm et qui vaut off par défaut, et auth_basic_user_file, qui désigne le fichier de mots de passe.

Directive	Valeur par défaut	Ce que dit la documentation
auth_basic string \| off;	off	Le paramètre est utilisé comme realm d'authentification. La valeur off annule un réglage hérité d'un niveau précédent.
auth_basic_user_file file;	aucune	Le fichier contient une entrée name:password par ligne, et les lignes commençant par # sont des commentaires.

Types de mots de passe pris en charge : mots de passe chiffrés par crypt() et hachages apr1, tous deux générés avec l'utilitaire htpasswd d'Apache ou avec openssl passwd.
La syntaxe {SCHEME}data est également prise en charge. La page indique que PLAIN n'est qu'un exemple et ne doit pas être utilisé, et que SHA, un SHA-1 sans sel, ne doit pas l'être non plus car il est vulnérable aux attaques par tables arc-en-ciel. SSHA est un SHA-1 salé.
L'exemple de la documentation : location / { auth_basic "closed site"; auth_basic_user_file conf/htpasswd; }

La page cite htpasswd et openssl passwd mais ne donne aucune commande. Les formes couramment utilisées, qui sont de nous et non de la page, sont htpasswd -c /etc/nginx/ollama.htpasswd alice, qui demande un mot de passe, et openssl passwd -apr1, qui affiche un hachage à coller après le nom d'utilisateur et deux-points.

Le chiffrement avec HTTPS

Notre lecture, et non une affirmation des documents : l'authentification basique envoie le mot de passe à chaque requête ; ne l'utilisez donc que derrière HTTPS. D'après la documentation de nginx, un serveur a besoin du paramètre ssl sur son socket d'écoute, ainsi que de l'emplacement du certificat et de la clé privée.

Directive	Exemple tiré de la documentation
listen	listen 443 ssl;
server_name	server_name www.example.com;
ssl_certificate	ssl_certificate www.example.com.crt;
ssl_certificate_key	ssl_certificate_key www.example.com.key;

Par défaut, nginx utilise ssl_protocols TLSv1.2 TLSv1.3 et ssl_ciphers HIGH:!aNULL:!MD5 ; les configurer explicitement n'est donc généralement pas nécessaire.
La clé privée doit être stockée dans un fichier à accès restreint, mais elle doit rester lisible par le processus maître de nginx.
Si les navigateurs signalent des erreurs pour un certificat délivré par une autorité reconnue, le serveur doit peut-être envoyer les certificats intermédiaires. Le certificat du serveur doit apparaître avant les certificats de la chaîne dans le fichier combiné, faute de quoi nginx ne démarre pas et affiche une erreur key values mismatch.
La page de démarrage de Let's Encrypt indique que, si votre hébergeur n'obtient pas les certificats pour vous et que vous pouvez administrer votre serveur, vous pouvez exécuter un client ACME, et qu'elle recommande Certbot pour la plupart des gens.

Réglages pour les réponses diffusées en continu et lentes

Un modèle écrit sa réponse morceau par morceau, et le premier morceau peut mettre du temps à arriver, par exemple pendant le chargement d'un gros modèle en mémoire. Trois réglages de nginx déterminent ce que l'on voit de l'extérieur.

Directive	Valeur par défaut	Ce que dit la documentation
proxy_buffering	on	Lorsque la mise en mémoire tampon est désactivée, la réponse est transmise au client de façon synchrone, dès qu'elle est reçue. Lorsqu'elle est activée, nginx enregistre d'abord la réponse dans des tampons.
proxy_read_timeout	60s	Le délai s'applique uniquement entre deux opérations de lecture successives, et non à l'ensemble de la réponse. Si le serveur mandaté ne transmet rien dans ce délai, la connexion est fermée.
proxy_http_version	1.1 depuis nginx 1.29.7	Avant la version 1.29.7, la valeur par défaut était 1.0. La version 1.1 ou 2 est recommandée pour les connexions keepalive.

Notre lecture, et non une affirmation des documents : pour voir une réponse apparaître au fur et à mesure de son écriture, désactivez proxy_buffering (off) pour l'emplacement d'Ollama, et si le modèle peut rester silencieux plus d'une minute pendant son chargement, augmentez proxy_read_timeout. Définir explicitement proxy_http_version 1.1 est sans effet néfaste sur toutes les versions.

Tout assembler

Cette configuration combine les directives ci-dessus pour un seul nom de serveur. Il s'agit de notre composition à partir des directives documentées ; testez-la donc avec nginx -t avant de recharger.

Ligne	Pourquoi
server {	un bloc server pour le nom d'Ollama
listen 443 ssl;	HTTPS
server_name ollama.example.com;	votre propre nom
ssl_certificate /etc/ssl/ollama.crt;	le certificat, suivi des certificats intermédiaires
ssl_certificate_key /etc/ssl/ollama.key;	la clé privée, lisible uniquement si nécessaire
auth_basic "ollama";	active le mot de passe
auth_basic_user_file /etc/nginx/ollama.htpasswd;	où sont conservés les utilisateurs
location / {	tout est envoyé à Ollama
proxy_pass http://localhost:11434;	tiré de la FAQ d'Ollama
proxy_set_header Host localhost:11434;	tiré de la FAQ d'Ollama
proxy_http_version 1.1;	recommandé pour keepalive
proxy_buffering off;	pour que la réponse soit diffusée en continu
proxy_read_timeout 300s;	tolère un premier morceau lent
}	fin de location
}	fin de server

Fermer les autres accès

Le proxy ne sert que si personne ne peut atteindre Ollama, ni l'application située derrière lui, par un autre chemin. Ollama reste sur son adresse par défaut, et un pare-feu n'admet que les adresses que vous utilisez.

Tâche	Commande issue de la documentation d'Ubuntu
Activer le pare-feu	sudo ufw enable
Autoriser un port	sudo ufw allow 22
Autoriser une adresse vers un port	sudo ufw allow proto tcp from 192.168.0.2 to any port 22
Autoriser un sous-réseau entier	remplacez l'adresse par 192.168.0.0/24
Vérifier l'état	sudo ufw status

La page d'Ubuntu indique qu'UFW est désactivé au départ. Elle ne contient aucun avertissement sur le risque de se verrouiller l'accès en SSH. Notre recommandation : autorisez votre port SSH avant d'activer le pare-feu sur un serveur auquel vous accédez à distance, et n'autorisez le port 443 que depuis les adresses qui en ont besoin.