~/ / Artículos de IA / LLM locales en un VPS / Poner nginx delante de Ollama: autenticación básica, HTTPS y ajustes para el streaming

Poner nginx delante de Ollama: autenticación básica, HTTPS y ajustes para el streaming

De forma predeterminada, Ollama escucha en el propio servidor, que es el lugar más seguro para él. Cuando otra máquina necesita acceder a Ollama, las preguntas frecuentes de Ollama remiten a un servidor proxy como nginx. Este artículo construye esa configuración a partir de la documentación de nginx: una contraseña, HTTPS, los ajustes que importan para las respuestas en streaming y un cortafuegos que cierra las demás puertas.

Publicado: 2026-10-26 · 6 min de lectura · Comprobado con la documentación oficial de Ollama y de nginx el 2026-10-26. Los valores predeterminados de las directivas dependen de la versión de nginx, así que comprueba la versión que utilizas.

Lo que dicen las preguntas frecuentes de Ollama

Las preguntas frecuentes de Ollama indican que Ollama ejecuta un servidor HTTP y que se puede exponer mediante un servidor proxy como Nginx. Su ejemplo escucha en el puerto 80, define un server_name, reenvía las solicitudes con proxy_pass http://localhost:11434 y establece la cabecera Host en localhost:11434.

La página de preguntas frecuentes que hemos consultado no describe ninguna autenticación para el servidor de Ollama. Por eso la contraseña tiene que venir del proxy que se coloca delante. Ollama se enlaza de forma predeterminada a 127.0.0.1, puerto 11434, de modo que un nginx en el mismo servidor puede acceder a él sin cambiar esa dirección.

Una contraseña con autenticación básica

El módulo ngx_http_auth_basic_module limita el acceso comprobando un nombre de usuario y una contraseña. Dos directivas hacen el trabajo: auth_basic, cuya cadena se usa como realm y que por defecto está en off, y auth_basic_user_file, que indica el archivo de contraseñas.

Directiva	Valor predeterminado	Lo que dice la documentación
auth_basic string \| off;	off	El parámetro se usa como realm de autenticación. El valor off cancela un ajuste heredado de un nivel anterior.
auth_basic_user_file file;	ninguno	El archivo contiene una entrada name:password por línea, y las líneas que empiezan por # son comentarios.

Tipos de contraseña admitidos: contraseñas cifradas con crypt() y hashes apr1, ambos generados con la utilidad htpasswd de Apache o con openssl passwd.
También se admite la sintaxis {SCHEME}data. La página indica que PLAIN es solo un ejemplo y no debe usarse, y que SHA, un SHA-1 sin sal, tampoco debe usarse porque es vulnerable a ataques con tablas arcoíris. SSHA es SHA-1 con sal.
El ejemplo de la documentación: location / { auth_basic "closed site"; auth_basic_user_file conf/htpasswd; }

La página nombra htpasswd y openssl passwd, pero no da ningún comando. Las formas de uso habitual, que son nuestras y no de la página, son htpasswd -c /etc/nginx/ollama.htpasswd alice, que solicita una contraseña, y openssl passwd -apr1, que imprime un hash que se pega después del nombre de usuario y dos puntos.

Conexión HTTPS

Nuestra lectura, no una afirmación de los documentos: la autenticación básica envía la contraseña con cada solicitud, así que úsala solo detrás de HTTPS. Según la documentación de nginx, un servidor necesita el parámetro ssl en su socket de escucha y las ubicaciones del certificado y de la clave privada.

Directiva	Ejemplo de la documentación
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;

De forma predeterminada, nginx usa ssl_protocols TLSv1.2 TLSv1.3 y ssl_ciphers HIGH:!aNULL:!MD5, por lo que, en general, no hace falta configurarlos explícitamente.
La clave privada debe guardarse en un archivo con acceso restringido, pero tiene que poder leerla el proceso maestro de nginx.
Si los navegadores muestran errores con un certificado de una autoridad conocida, puede que el servidor tenga que enviar los certificados intermedios. El certificado del servidor debe aparecer antes de los certificados encadenados en el archivo combinado; de lo contrario, nginx no arranca y muestra un error de discrepancia de valores de clave (key values mismatch).
La página de primeros pasos de Let's Encrypt indica que, si tu proveedor no obtiene los certificados por ti y puedes administrar tu servidor, puedes ejecutar un cliente ACME, y que recomienda Certbot para la mayoría de las personas.

Ajustes para respuestas en streaming y lentas

Un modelo escribe su respuesta pieza a pieza, y la primera pieza puede tardar en llegar, por ejemplo mientras se carga un modelo grande en la memoria. Tres ajustes de nginx deciden cómo se ve esto desde fuera.

Directiva	Valor predeterminado	Lo que dice la documentación
proxy_buffering	on	Cuando el almacenamiento en búfer está desactivado, la respuesta se pasa al cliente de forma síncrona, en cuanto se recibe. Cuando está activado, nginx guarda primero la respuesta en búferes.
proxy_read_timeout	60s	El tiempo de espera se aplica solo entre dos operaciones de lectura sucesivas, no a toda la respuesta. Si el servidor proxificado no transmite nada en ese tiempo, la conexión se cierra.
proxy_http_version	1.1 desde nginx 1.29.7	Antes de la 1.29.7, el valor predeterminado era 1.0. Se recomienda la versión 1.1 o 2 para las conexiones keepalive.

Nuestra lectura, no una afirmación de los documentos: para ver cómo aparece la respuesta a medida que se escribe, desactiva proxy_buffering (off) en la ubicación de Ollama y, si el modelo puede permanecer en silencio durante más de un minuto mientras se carga, aumenta proxy_read_timeout. Establecer proxy_http_version 1.1 explícitamente no hace daño en ninguna versión.

Todo junto

Esta configuración combina las directivas anteriores para un nombre de servidor. Es composición nuestra a partir de las directivas documentadas, así que pruébala con nginx -t antes de recargar.

Línea	Por qué
server {	un bloque server para el nombre de Ollama
listen 443 ssl;	HTTPS
server_name ollama.example.com;	tu propio nombre
ssl_certificate /etc/ssl/ollama.crt;	el certificado, con los intermedios a continuación
ssl_certificate_key /etc/ssl/ollama.key;	la clave privada, legible solo si es necesario
auth_basic "ollama";	activa la contraseña
auth_basic_user_file /etc/nginx/ollama.htpasswd;	dónde se guardan los usuarios
location / {	todo va a Ollama
proxy_pass http://localhost:11434;	de las preguntas frecuentes de Ollama
proxy_set_header Host localhost:11434;	de las preguntas frecuentes de Ollama
proxy_http_version 1.1;	recomendado para keepalive
proxy_buffering off;	para que la respuesta fluya en streaming
proxy_read_timeout 300s;	permite una primera pieza lenta
}	fin de location
}	fin de server

Cerrar las demás puertas

El proxy solo sirve si no se puede llegar a Ollama ni a la aplicación que hay detrás de otra manera. Ollama se queda en su dirección predeterminada y un cortafuegos admite solo las direcciones que utilizas.

Tarea	Comando de la documentación de Ubuntu
Activar el cortafuegos	sudo ufw enable
Permitir un puerto	sudo ufw allow 22
Permitir una dirección hacia un puerto	sudo ufw allow proto tcp from 192.168.0.2 to any port 22
Permitir una subred completa	sustituye la dirección por 192.168.0.0/24
Comprobar el estado	sudo ufw status

La página de Ubuntu indica que UFW está inicialmente desactivado. No incluye ninguna advertencia sobre quedarse sin acceso por SSH. Nuestra recomendación: permite tu puerto SSH antes de activar el cortafuegos en un servidor al que accedes de forma remota, y permite el puerto 443 solo desde las direcciones que lo necesiten.