Ollama offline total: bloquea toda telemetría y tráfico externo

Una de las razones principales para ejecutar AI localmente es la soberanía sobre los datos — tus prompts, documentos y respuestas se quedan en tu hardware, no en un servidor de terceros. Ollama está diseñado con esto en mente: la inferencia ocurre completamente en el dispositivo y ningún contenido de los prompts se transmite externamente por defecto.

Dicho esto, como la mayoría del software, Ollama puede realizar conexiones de red salientes para fines ajenos a la inferencia — comprobaciones de actualizaciones, pings de versión y tareas de mantenimiento similares. Para uso personal esto no suele ser un problema. Para entornos corporativos, industrias reguladas o cualquiera que maneje datos sensibles en una red air-gapped, vale la pena entender qué sale de la máquina y cómo bloquearlo completamente.

Qué envía Ollama por defecto

El tráfico saliente de Ollama es mínimo y no invasivo para la privacidad según los estándares de los servicios en la nube, pero conviene saber qué esperar:

• BAJA
  Comprobaciones de actualización

  Ollama comprueba periódicamente su propio endpoint de versiones para notificarte de nuevas versiones. Esto envía tu versión actual de Ollama y el tipo de sistema operativo — sin datos de usuario, sin contenido de prompts.

• DESCARGA
  Descarga de manifiestos de modelos

  Cuando ejecutas "ollama pull" u "ollama run" con un nuevo modelo, Ollama contacta el registro de modelos de Ollama (registry.ollama.ai) para descargar el manifiesto y los pesos del modelo. Este es el comportamiento esperado durante la adquisición del modelo — no durante la inferencia.

• NINGUNA
  Sin telemetría de prompts

  Ollama no transmite el contenido de los prompts, las respuestas ni el historial de conversación. La inferencia es completamente local. Esto ha sido confirmado por análisis independientes del tráfico de red del código fuente abierto.

Desactivar las comprobaciones de actualización

El paso más sencillo es desactivar el mecanismo de comprobación de actualizaciones mediante una variable de entorno. Configura OLLAMA_NO_UPDATE_CHECK=1 antes de iniciar Ollama y omitirá completamente las comprobaciones de versión salientes.

Linux y macOS

# Solo para la sesión actual de shell
export OLLAMA_NO_UPDATE_CHECK=1

# Configuración permanente — agrega a ~/.bashrc o ~/.zshrc
echo 'export OLLAMA_NO_UPDATE_CHECK=1' >> ~/.zshrc
source ~/.zshrc

# Verifica que esté configurada
echo $OLLAMA_NO_UPDATE_CHECK
1

Windows

# PowerShell — solo para la sesión actual
$env:OLLAMA_NO_UPDATE_CHECK = "1"

# PowerShell — permanente (ámbito de usuario, persiste tras reinicios)
[System.Environment]::SetEnvironmentVariable("OLLAMA_NO_UPDATE_CHECK", "1", "User")

# Alternativa: Panel de control → Sistema → Configuración avanzada → Variables de entorno
# Agrega nueva variable de usuario: OLLAMA_NO_UPDATE_CHECK = 1

Linux con servicio systemd

Si Ollama corre como servicio systemd (el comportamiento por defecto en Linux tras usar el script de instalación oficial), las variables de entorno configuradas en tu shell no serán heredadas por el servicio. Usa un archivo de override de systemd en su lugar:

# Si Ollama corre como servicio systemd (por defecto con el script de instalación de Linux)
# Edita el archivo de override del servicio
sudo systemctl edit ollama

# Agrega el siguiente bloque en el editor que se abre:
[Service]
Environment="OLLAMA_NO_UPDATE_CHECK=1"
Environment="OLLAMA_ORIGINS=http://localhost"

# Recarga y reinicia
sudo systemctl daemon-reload && sudo systemctl restart ollama

Reglas de firewall para aislamiento total

Para entornos donde las variables de entorno por sí solas no son suficientes — o donde quieres una garantía a nivel de red — usa reglas de firewall para bloquear todo el tráfico saliente del proceso de Ollama manteniendo el puerto de la API local accesible. En Linux con ufw:

# Permite el puerto de la API de Ollama solo desde localhost
sudo ufw allow from 127.0.0.1 to any port 11434

# Deniega todo el tráfico saliente del binario de ollama
# Primero, busca la ruta del binario de ollama
which ollama
/usr/local/bin/ollama

# Bloquea las conexiones salientes por usuario (Ollama corre como usuario del sistema 'ollama')
sudo ufw deny out from any to any user ollama

# Habilita y verifica las reglas
sudo ufw enable
sudo ufw status numbered

En macOS, el Firewall de aplicaciones integrado (Configuración del sistema → Privacidad y seguridad → Firewall → Opciones del firewall) permite bloquear conexiones entrantes por aplicación. Para control del tráfico saliente necesitarás una herramienta de terceros como Little Snitch o Lulu (gratuito, open-source) — ambas te permiten crear reglas salientes por proceso con una ventana de confirmación la primera vez que la app intenta conectarse.

En Windows, el Firewall de Windows Defender integrado admite reglas de salida. Abre Firewall de Windows Defender con seguridad avanzada, añade una Regla de salida, selecciona "Programa", apúntalo a %LOCALAPPDATA%\Programs\Ollama\ollama.exe y establece la acción en "Bloquear".

Verificar con netstat o ss

Después de aplicar tu configuración, confirma que Ollama solo mantiene conexiones locales. Ejecuta lo siguiente mientras Ollama está corriendo y sirviendo activamente un modelo:

# Linux — lista las conexiones activas del proceso ollama
ss -tupn | grep ollama

# Salida esperada (solo conexiones a localhost — sin IPs externas):
tcp   LISTEN  0  128  127.0.0.1:11434  0.0.0.0:*  users:(("ollama",pid=12345,fd=7))

# macOS — verificación equivalente
lsof -i -n -P | grep ollama

# Windows PowerShell
Get-NetTCPConnection | Where-Object { $_.OwningProcess -eq (Get-Process ollama).Id }

La salida debería listar solo conexiones a 127.0.0.1 o ::1 (localhost IPv6). Cualquier conexión a una IP externa requiere investigación. Para una inspección más profunda, Wireshark con el filtro udp.port != 5353 && ip.src == <tu-ip-de-máquina> capturará todo el tráfico saliente no-mDNS durante una sesión de inferencia.

¿Es necesario para la mayoría de los usuarios?

Para uso personal cotidiano, no — Ollama ya es órdenes de magnitud más privado que los servicios de AI en la nube. Tus prompts nunca salen de la máquina, y el tráfico de comprobación de actualizaciones que existe es mínimo y no identificativo.

Los pasos de esta guía son más relevantes para despliegues corporativos que manejan datos regulados (sanidad, legal, financiero), equipos que construyen sobre infraestructura air-gapped, o cualquiera con un requisito de cumplimiento específico que prohíbe cualquier tráfico saliente de herramientas de AI. Si ese es tu contexto, el enfoque de variables de entorno y firewall descrito arriba te proporciona una base verificable y auditable.