Porta Ollama: valore predefinito 11434, come modificarla e risolvere i conflitti

Ollama ascolta sulla porta 11434 per impostazione predefinita, tramite HTTP, associata all’indirizzo di loopback 127.0.0.1. Pertanto, l’URL base dell’API sulla macchina stessa è http://127.0.0.1:11434. Poiché l’associazione avviene sull’indirizzo di loopback e non su tutte le interfacce, nessun dispositivo esterno alla macchina può accedervi finché non si modifica intenzionalmente l’indirizzo di binding.

Cosa viene effettivamente eseguito sulla porta 11434

La porta 11434 ospita il server HTTP di Ollama — lo stesso processo avviato manualmente ollama serve e lo stesso che l’applicazione desktop avvia in background. Tutti i componenti di Ollama comunicano con esso: l’interfaccia a riga di comando (CLI), la finestra di chat desktop e qualsiasi client di terze parti configurato per puntare ad esso. ollama CLI, la finestra di chat desktop e qualsiasi client di terze parti che vi puntiate.

Nota la riga relativa a /api/pull e /api/delete. Chiunque possa raggiungere la porta può scaricare modelli di diverse gigabyte sul tuo disco o eliminarne quelli già presenti. Questa è, in una frase, la situazione relativa alla sicurezza, motivo per cui l’associazione predefinita avviene sull’indirizzo di loopback. Se stai ancora decidendo quali modelli installare localmente, la Elenco modelli Ollama pagina dedicata copre ciò che è disponibile e le dimensioni di ciascun modello.

OLLAMA_HOST: la variabile che controlla univocamente la porta

Sia l’indirizzo di binding sia la porta derivano da un’unica variabile d’ambiente, OLLAMA_HOST. Non esiste una configurazione separata per la porta né un file di configurazione che la sovrascriva.

Scrivere sempre nel formato host:port. Alcune versioni accettano forme abbreviate, ma la coppia esplicita garantisce un comportamento coerente su tutte le versioni.

Un dettaglio che inganna quasi tutti: OLLAMA_HOST viene letta sia dal client sia dal server. Se sposti il server sulla porta 11435 ma il tuo terminale conserva ancora il valore predefinito, ollama list fallirà con un errore di connessione anche se il server è perfettamente funzionante. Imposta la variabile in entrambi i posti oppure esegui l'interfaccia a riga di comando (CLI) come OLLAMA_HOST=127.0.0.1:11435 ollama list.

Modifica della porta di Ollama su Linux

Lo script di installazione per Linux registra un servizio systemd, quindi le variabili d'ambiente della tua shell non hanno alcun effetto: devono essere inserite direttamente nell'unità. Usa un file di override (drop-in) invece di modificare direttamente il file dell'unità fornito, poiché gli aggiornamenti del pacchetto lo sovrascriveranno:

sudo systemctl edit ollama.service

Aggiungi questo blocco (su versioni più recenti di systemd, inseriscilo tra i commenti ### Qualsiasi cosa tra qui... ):

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

Ciò crea il file /etc/systemd/system/ollama.service.d/override.conf. Applica le modifiche con:

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

Aggiungi una Environment= riga per ogni variabile — una seconda riga non sostituisce la prima. Se stai anche spostando la cartella di archiviazione dei modelli, Environment="OLLAMA_MODELS=/mnt/models" va inserita nello stesso blocco.

Se esegui ollama serve manualmente

senza coinvolgere systemd, basta esportarla così: OLLAMA_HOST=0.0.0.0:11434 ollama serve. Assicurati innanzitutto che il servizio systemd sia arrestato (sudo systemctl stop ollama) altrimenti i due processi entreranno in conflitto per l'utilizzo della stessa porta.

Modifica della porta di Ollama su macOS

L'app macOS viene avviata dalla sessione grafica (GUI), che non eredita il profilo della tua shell. Esportare la variabile in OLLAMA_HOST in .zshrc modifica l'interfaccia a riga di comando (CLI), ma non il server in background. Usa invece launchctl :

launchctl setenv OLLAMA_HOST "0.0.0.0:11434"

Quindi esci da Ollama facendo clic sull'icona nella barra dei menu e riavvialo. Il nuovo valore verrà applicato soltanto ai processi avviati successivamente.

launchctl setenv non non resiste a un riavvio. Per un cambiamento permanente devi rieseguire il comando all'accesso — ad esempio tramite un LaunchAgent (file plist) o un elemento di avvio (login item) che esegua il comando. Le versioni più recenti dell'app macOS offrono inoltre un interruttore per l'accesso alla rete nelle Impostazioni; se la tua versione lo include, utilizzalo preferibilmente, poiché il valore viene salvato correttamente. Controlla prima il pannello delle impostazioni integrato nell'app prima di creare un LaunchAgent e consulta la Guida completa a Ollama documentazione ufficiale

Modifica della porta di Ollama su Windows

Su Windows, Ollama viene eseguito come processo utente normale con un'icona nella barra delle applicazioni (system tray), quindi è sufficiente impostare una variabile d'ambiente a livello utente.

1. Stampa Win, digita variabili d'ambiente, quindi apri Modifica le variabili d'ambiente di sistema → Variabili d'ambiente…
2. Nella sezione Variabili utente, fai clic su Nuovo.
3. Nome: OLLAMA_HOSTValore: 0.0.0.0:11434 (o sulla porta da te scelta).
4. Fai clic su OK in entrambe le finestre di dialogo.
5. Fai clic destro sull'icona di Ollama nella barra delle applicazioni e scegli Esci, quindi avvia nuovamente Ollama dal menu Start.

Il passaggio 5 è quello che spesso viene saltato. Chiudere la finestra non arresta il server, che continua a eseguirsi con il vecchio valore. In alternativa, da terminale: setx OLLAMA_HOST "0.0.0.0:11434" — tuttavia setx ha effetto soltanto sui processi avviati dopo dopo la sua esecuzione, quindi è comunque necessario uscire e riavviare. Se stai configurando Ollama da zero, la guida all'installazione di Ollama illustra passo dopo passo l'intero processo di installazione su Windows.

Verifica che il server stia effettivamente ascoltando

Esegui due controlli, in quest'ordine: qualcosa sta utilizzando la porta? E quel qualcosa è effettivamente Ollama?

Leggi attentamente la colonna dell'indirizzo locale. 127.0.0.1:11434 significa loopback esclusivamente — una macchina remota non riuscirà mai a connettersi, indipendentemente dalle regole del firewall. 0.0.0.0:11434 o *:11434 significa tutti gli interfaccia.

Rendere Ollama accessibile da altre macchine

Il binding su 0.0.0.0 è necessario ma solitamente non sufficiente. Devono essere contemporaneamente vere tre condizioni: il server deve essere associato a un indirizzo non-loopback, il firewall host deve consentire le connessioni TCP in entrata sulla porta specificata e il client deve utilizzare l’indirizzo IP LAN dell’host anziché localhost.

Regole del firewall

Delimita l’ambito della regola alla tua sottorete, quando possibile — come nell’esempio con ufw — invece di consentire l’accesso da qualsiasi parte del mondo.

Le implicazioni per la sicurezza, espresse chiaramente

L’API di Ollama non prevede autenticazione, né chiavi API né TLS. Associato a 0.0.0.0 ciò concede a chiunque possa raggiungere quell’indirizzo il pieno controllo: eseguire inferenze, leggere l’elenco dei modelli, scaricare nuovi modelli o eliminarne di esistenti. Le istanze di Ollama esposte su Internet vengono individuate rapidamente dagli scanner, poiché la porta 11434 è ben nota.

Opzioni più sicure, ordinate approssimativamente in base allo sforzo richiesto:

• Tunnel SSH — lascia il binding sul loopback e inoltralo: ssh -L 11434:127.0.0.1:11434 user@server. Nulla viene esposto; il client comunica con il proprio localhost.
• Rete sovrapposta (overlay network) — Tailscale, WireGuard o soluzioni analoghe. Esegui il binding sull’indirizzo IP dell’interfaccia sovrapposta, in modo che solo i dispositivi presenti nella tua tailnet possano connettersi.
• Proxy inverso (reverse proxy) — Caddy o nginx in posizione frontale, che gestiscono la terminazione TLS e applicano autenticazione di base o un token bearer, mentre Ollama rimane in ascolto sul loopback.

Se stai valutando la possibilità di condividere un server domestico per laboratorio rispetto al pagamento per token, il calcolatore del punto di pareggio tra auto-hosting e utilizzo di API quantifica numericamente questo compromesso, mentre il Calcolatore VRAM ti indica se il sistema che intendi condividere possiede effettivamente la capacità di caricare il modello richiesto.

Diagnosi di un conflitto sulla porta

Il sintomo è un errore all’avvio che menziona l’indirizzo, simile a questo:

Errore: listen tcp 127.0.0.1:11434: bind: l’indirizzo è già in uso

Trova il processo proprietario della porta:

# Linux
sudo ss -tlnp | grep 11434

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

# Windows — ottieni il PID, quindi identifica il processo
netstat -ano | findstr :11434
tasklist /FI "PID eq 12345"

Nella pratica, la causa è quasi sempre Ollama stesso, eseguito due volte. Le varianti più comuni sono:

• L’applicazione desktop è già in esecuzione nella barra delle applicazioni o nella barra dei menu e hai digitato ollama serve in un terminale. Il server integrato nell’app funziona correttamente — basta utilizzarlo.
• Su Linux, il servizio systemd è attivo e hai lanciato manualmente ollama serve . Arrestane uno dei due: sudo systemctl stop ollama.
• Un contenitore Docker pubblicato con -p 11434:11434 occupa la porta sull’host. Verificalo con docker ps.

Se si tratta effettivamente di un’altra applicazione, sposta piuttosto Ollama anziché cercare di risolvere il conflitto — scegli una porta elevata libera, ad esempio 127.0.0.1:11435 e imposta OLLAMA_HOST come descritto sopra. Ricorda di aggiornare l’URL base di ogni client, inclusa qualsiasi configurazione SDK compatibile con OpenAI.

Docker e WSL

All’interno del contenitore ufficiale, il server è già configurato per il binding su 0.0.0.0:11434 pertanto devi solo scegliere la mappatura sull’host: docker run -d -p 127.0.0.1:11434:11434 --name ollama ollama/ollama mantiene l’accesso locale, mentre -p 11434:11434 espone il servizio su tutte le interfacce dell’host. Per modificare la porta sull’host, cambia solo il numero a sinistra — -p 11435:11434 — e lasciare invariata la porta interna del contenitore.

Da WSL2 a un'istanza di Ollama in esecuzione sull’host Windows, localhost non risolve sempre l’indirizzo dell’host. Associare Ollama lato Windows all’indirizzo 0.0.0.0:11434, autorizzare la porta nel firewall di Windows Defender e connettersi da WSL utilizzando l’indirizzo IP dell’host presente in /etc/resolv.conf o l’indirizzo della rete speculare (mirrored-networking), a seconda della configurazione di WSL.

Domande frequenti

Esiste una variabile d’ambiente OLLAMA_PORT?

No. La porta e l’indirizzo di binding sono entrambi impostati tramite OLLAMA_HOST, specificato come host:port. Impostare OLLAMA_PORT non ha alcun effetto: Ollama lo ignora e continua a usare la porta 11434, motivo per cui la modifica sembra fallire in modo silenzioso.

Ho impostato OLLAMA_HOST su 0.0.0.0, ma i dispositivi remoti non riescono comunque a connettersi. Perché?

Verificare i tre livelli nell’ordine indicato. Accertarsi innanzitutto che il server sia effettivamente associato a 0.0.0.0 e non a 127.0.0.1 utilizzando ss, lsof o netstat; verificare quindi che il firewall dell’host consenta il traffico TCP in entrata sulla porta specificata; infine, assicurarsi che il client utilizzi l’indirizzo IP LAN dell’host e non localhost. La causa più comune è il mancato riavvio completo del processo Ollama dopo aver impostato la variabile.

Modificare la porta compromette il funzionamento dell’interfaccia a riga di comando (CLI) di ollama?

Può accadere. La CLI legge la stessa variabile OLLAMA_HOST per determinare l’indirizzo a cui connettersi; pertanto, se il server è stato spostato su un’altra porta ma la shell non è stata aggiornata, comandi come ollama list falliscono con un errore di connessione. Impostare la variabile anche nel profilo della shell oppure anteporre la variabile ai singoli comandi.

È possibile eseguire due istanze distinte di Ollama su porte diverse?

Sì: avviarne ciascuna con un diverso valore di OLLAMA_HOST. Condivideranno la stessa directory dei modelli, a meno che non si specifichi anche un percorso OLLAMA_MODELS distinto per ciascuna istanza. Tenere presente che entrambe le istanze caricano i pesi sullo stesso GPU, quindi l’esecuzione simultanea di due modelli di grandi dimensioni comporterà una competizione per la VRAM; la tabella di riferimento Requisiti di VRAM per modello mostra quanto spazio disponibile rimane effettivamente.

Qual è l’URL base richiesto dai client compatibili con OpenAI?

Impostare l’URL base dell’SDK su http://localhost:11434/v1 (aggiustando l’indirizzo host e la porta, se queste sono state modificate). La maggior parte dei client richiede inoltre che il campo della chiave API non sia vuoto, anche se Ollama lo ignora: è sufficiente fornire una stringa segnaposto qualsiasi, ad esempio ollama.

È sicuro esporre la porta 11434 a Internet?

No. Non è prevista alcuna autenticazione né crittografia integrata, e l’API esposta consente operazioni di download ed eliminazione dei modelli. Se è necessario un accesso remoto, utilizzare un tunnel SSH o una rete sovrapposta privata, oppure posizionare davanti a Ollama un reverse proxy autenticante con TLS. Se l’accesso remoto è il requisito principale, confrontare i costi operativi con quelli dell’inferenza ospitata offerta da Calcolatore costi API prima di sviluppare l’infrastruttura necessaria.

Riferimento rapido

Una volta risolta la questione della porta, la domanda successiva riguarda solitamente quale modello utilizzare: i migliori modelli locali per Ollama illustra le opzioni attualmente disponibili suddivise per fascia hardware.