~/ / Articoli sull'IA / LLM locali su un VPS / Mettere nginx davanti a Ollama: autenticazione basic, HTTPS e impostazioni per lo streaming

Mettere nginx davanti a Ollama: autenticazione basic, HTTPS e impostazioni per lo streaming

Per impostazione predefinita Ollama resta in ascolto sul server stesso, che è il posto più sicuro per lui. Quando un'altra macchina deve raggiungerlo, le FAQ di Ollama indicano un server proxy come nginx. Questo articolo costruisce quella configurazione a partire dalla documentazione di nginx: una password, HTTPS, le impostazioni che contano per le risposte in streaming e un firewall che chiude le altre porte.

Pubblicato: 2026-10-26 · 5 min di lettura · Verificato sulla documentazione ufficiale di Ollama e di nginx il 2026-10-26. I valori predefiniti delle direttive dipendono dalla versione di nginx, quindi controlla la versione che usi.

Cosa dicono le FAQ di Ollama

Le FAQ di Ollama dicono che Ollama esegue un server HTTP e può essere esposto tramite un server proxy come Nginx. Il loro esempio ascolta sulla porta 80, imposta un server_name, inoltra le richieste con proxy_pass http://localhost:11434 e imposta l'intestazione Host su localhost:11434.

La pagina delle FAQ che abbiamo controllato non descrive alcuna autenticazione per il server Ollama. Per questo la password deve arrivare dal proxy che gli sta davanti. Ollama si associa per impostazione predefinita a 127.0.0.1 sulla porta 11434, quindi un nginx sullo stesso server può raggiungerlo senza cambiare quell'indirizzo.

Una password con l'autenticazione basic

Il modulo ngx_http_auth_basic_module limita l'accesso verificando nome utente e password. Il lavoro è svolto da due direttive: auth_basic, la cui stringa viene usata come realm e che per impostazione predefinita è off, e auth_basic_user_file, che indica il file delle password.

Direttiva	Predefinito	Cosa dice la documentazione
auth_basic string \| off;	off	Il parametro è usato come realm di autenticazione. Il valore off annulla un'impostazione ereditata da un livello precedente.
auth_basic_user_file file;	nessuno	Il file contiene una voce nome:password per riga, e le righe che iniziano con # sono commenti.

Tipi di password supportati: password cifrate con crypt() e hash apr1, entrambi generati con l'utility htpasswd di Apache o con openssl passwd.
È supportata anche la sintassi {SCHEME}data. La pagina dice che PLAIN è solo un esempio e non va usato, e che nemmeno SHA, un SHA-1 senza salt, va usato perché è vulnerabile agli attacchi con rainbow table. SSHA è un SHA-1 con salt.
L'esempio della documentazione: location / { auth_basic "closed site"; auth_basic_user_file conf/htpasswd; }

La pagina nomina htpasswd e openssl passwd ma non riporta comandi. Le forme di uso comune, che sono nostre e non della pagina, sono htpasswd -c /etc/nginx/ollama.htpasswd alice, che chiede una password, e openssl passwd -apr1, che stampa un hash da incollare dopo il nome utente e i due punti.

HTTPS e certificato

Nostra lettura, non un'affermazione dei documenti: l'autenticazione basic invia la password a ogni richiesta, quindi usala solo dietro HTTPS. Secondo la documentazione di nginx, un server ha bisogno del parametro ssl sul socket di ascolto e dei percorsi del certificato e della chiave privata.

Direttiva	Esempio dalla documentazione
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;

Per impostazione predefinita nginx usa ssl_protocols TLSv1.2 TLSv1.3 e ssl_ciphers HIGH:!aNULL:!MD5, quindi in genere non serve configurarli esplicitamente.
La chiave privata dovrebbe essere conservata in un file ad accesso limitato, ma deve essere leggibile dal processo master di nginx.
Se i browser segnalano errori per un certificato di un'autorità nota, il server potrebbe dover inviare i certificati intermedi. Nel file combinato il certificato del server deve comparire prima dei certificati della catena, altrimenti nginx non si avvia con un errore di mancata corrispondenza dei valori della chiave.
La pagina introduttiva di Let's Encrypt dice che, se il tuo provider non ottiene i certificati per te e puoi amministrare il tuo server, puoi eseguire un client ACME, e che per la maggior parte delle persone consiglia Certbot.

Impostazioni per le risposte in streaming e lente

Un modello scrive la risposta un pezzo alla volta, e il primo pezzo può richiedere un po' di tempo, per esempio mentre un modello grande viene caricato in memoria. Tre impostazioni di nginx decidono come appare tutto questo dall'esterno.

Direttiva	Predefinito	Cosa dice la documentazione
proxy_buffering	on	Quando il buffering è disattivato, la risposta viene passata al client in modo sincrono, subito mentre viene ricevuta. Quando è attivato, nginx salva prima la risposta nei buffer.
proxy_read_timeout	60s	Il timeout è impostato solo tra due operazioni di lettura successive, non per l'intera risposta. Se il server proxato non trasmette nulla entro questo tempo, la connessione viene chiusa.
proxy_http_version	1.1 da nginx 1.29.7	Prima della 1.29.7 il valore predefinito era 1.0. Per le connessioni keepalive si consiglia la versione 1.1 o 2.

Nostra lettura, non un'affermazione dei documenti: per vedere la risposta comparire mentre viene scritta, disattiva proxy_buffering per la location di Ollama, e se il modello può restare in silenzio per più di un minuto durante il caricamento, aumenta proxy_read_timeout. Impostare proxy_http_version 1.1 in modo esplicito è innocuo su qualsiasi versione.

Mettere tutto insieme

Questa configurazione combina le direttive viste sopra per un solo nome di server. È una nostra composizione a partire dalle direttive documentate, quindi provala con nginx -t prima di ricaricare.

Riga	Perché
server {	un blocco server per il nome di Ollama
listen 443 ssl;	HTTPS
server_name ollama.example.com;	il tuo nome
ssl_certificate /etc/ssl/ollama.crt;	il certificato, con gli intermedi dopo di esso
ssl_certificate_key /etc/ssl/ollama.key;	la chiave privata, leggibile solo dove serve
auth_basic "ollama";	attiva la password
auth_basic_user_file /etc/nginx/ollama.htpasswd;	dove sono conservati gli utenti
location / {	tutto va a Ollama
proxy_pass http://localhost:11434;	dalle FAQ di Ollama
proxy_set_header Host localhost:11434;	dalle FAQ di Ollama
proxy_http_version 1.1;	consigliato per keepalive
proxy_buffering off;	così la risposta arriva in streaming
proxy_read_timeout 300s;	consente un primo pezzo lento
}	fine della location
}	fine del server

Chiudere le altre porte

Il proxy serve solo se nessuno può raggiungere Ollama, o l'applicazione che sta dietro, in un altro modo. Ollama resta sul suo indirizzo predefinito e un firewall ammette solo gli indirizzi che usi.

Operazione	Comando dalla documentazione di Ubuntu
Attivare il firewall	sudo ufw enable
Consentire una porta	sudo ufw allow 22
Consentire un indirizzo verso una porta	sudo ufw allow proto tcp from 192.168.0.2 to any port 22
Consentire un'intera sottorete	sostituisci l'indirizzo con 192.168.0.0/24
Controllare lo stato	sudo ufw status

La pagina di Ubuntu dice che UFW è inizialmente disattivato. Non contiene alcun avviso sul rischio di bloccarsi fuori via SSH. Nostra raccomandazione: consenti la tua porta SSH prima di attivare il firewall su un server che raggiungi da remoto, e consenti la porta 443 solo dagli indirizzi che ne hanno bisogno.