Inicio » Software » Guía definitiva para solucionar el problema del puerto 11434 de Ollama
Guía definitiva para solucionar el problema del puerto 11434 de Ollama
El puerto 11434 es la dirección clave para que Ollama exponga su API y permita integraciones locales o remotas.
Problemas comunes van desde conflictos de procesos a errores de acceso remoto, Docker o CORS, todo solucionable entendiendo la configuración correcta.
La gestión avanzada requiere controlar variables de entorno, usar tunelado o proxies seguros y adaptar el puerto y la red a tu escenario, siempre velando por la seguridad.
Ollama ha irrumpido como la solución predilecta para quienes buscan ejecutar modelos de inteligencia artificial localmente, con una flexibilidad y potencia difícil de igualar. Pero, como suele pasar con cualquier software que apuesta por la simplicidad y el control del usuario, surgen dudas y tropiezos, y uno de los más recurrentes gira en torno al famoso ‘puerto 11434’. Si alguna vez te has preguntado cómo solucionar conflictos, dar acceso remoto, configurar correctamente tus aplicaciones o conectar Ollama a diferentes entornos, este artículo lo cubre todo. Y cuando decimos todo, es TODO: desde la raíz técnica a los trucos menos documentados, pasando por la integración con las apps más punteras y los entornos de escritorio tipo ChatGPT. Aquí tienes la guía definitiva y más actualizada que vas a encontrar en español.
¿Te ha dado guerra el puerto por defecto de Ollama o te preguntas cómo configurarlo para tu homelab, tu app de escritorio o tu equipo de trabajo? Has llegado justo al sitio que necesitabas. Vamos a exprimir tanto la documentación oficial, como la experiencia real de usuarios y desarrolladores, desgranando desde lo básico hasta el despliegue en producción, pasando por soluciones de problemas clásicos (ese ‘bind: address already in use’ que desespera), variables de entorno clave, tunelado seguro y cómo hacer que todo funcione en Docker, Windows, Mac, Linux o incluso desde apps externas como Levante, Cherry Studio y Msty. Todo bajo el prisma de la seguridad, buen rendimiento y con explicaciones fáciles de digerir aunque no seas DevOps.
¿Qué es el puerto 11434 de Ollama y por qué es tan importante?
El puerto 11434 es el punto de acceso por defecto que Ollama usa para exponer su API local REST, tanto la propia como la compatible con OpenAI. ¿Para qué sirve? Básicamente, aquí es donde escucha todas las peticiones procedentes de las apps, interfaces web, herramientas de escritorio e integraciones externas. Esa dirección (http://localhost:11434) es la puerta de entrada y salida para gestionar modelos, ejecutar inferencias, personalizar comportamientos o integrar Ollama en flujos de trabajo. Si tienes varias apps intentando hablar con Ollama, algún otro software ocupando ese puerto o estás intentando acceder desde otra máquina (LAN, internet o Red VPN), entender y saber manejar el puerto 11434 es vital para que todo funcione sin atascos.
De serie, Ollama lo liga solo a la interfaz local (‘localhost’), lo que significa que, a priori, solo la propia máquina puede ‘ver’ ese puerto. Esto es perfecto en términos de seguridad, pero puede ser limitante si necesitas que tu Ollama ‘sirva’ a otras estaciones de trabajo, contenedores, servidores, apps de escritorio remotas o si planeas compartir modelos dentro de tu red. Aquí empieza el verdadero reto y donde este artículo va a ayudarte paso a paso.
Principales problemas con el puerto 11434 en Ollama: causas y cómo detectarlos
Si estás leyendo esto, probablemente te suena alguno de estos escenarios típicos:
Al lanzar Ollama, aparece el error «listen tcp 127.0.0.1:11434: bind: address already in use». Esto significa que otro proceso (la mayoría de las veces otra instancia de Ollama o alguna app conflictiva) ya está ocupando ese puerto. Hasta que no lo liberes, Ollama no podrá arrancar bien.
Intentas conectar desde una app externa (Levante, Cherry Studio, Msty, Open WebUI, CodeGPT, etc.) y recibes mensajes de conexión fallida o ‘no se puede conectar a Ollama’.
El menú de modelos está vacío aunque tienes varios descargados. Al lanzar ‘curl http://localhost:11434/api/tags’ el resultado es correcto, pero la app no los detecta.
Al intentar acceder desde otra máquina de la red local (LAN) o Docker, no ves el puerto abierto.
El modelo responde muy, muy lento, aunque tu hardware debería sobrarle.
Conflictos de CORS al conectar apps web desde otro origen a la API de Ollama.
La clave para diagnosticar y solucionar es entender cómo se está lanzando Ollama, qué apps / instancias pueden estar usando ese puerto, cómo está configurada la variable OLLAMA_HOST y si hay firewalls o cortafuegos filtrando el tráfico local.
Cómo saber si el puerto 11434 de Ollama está libre y operativo
Antes de ponerte a reconfigurar nada, verifica si Ollama está corriendo y el puerto 11434 está disponible:
Comando genérico:curl http://localhost:11434/api/tags — Si devuelve JSON (aunque sea vacío), todo va bien.
Linux / macOS:sudo lsof -i :11434
Windows (CMD):netstat -ano | findstr "11434"
Si ves algún proceso ‘escuchando’, identifica el PID. Si es Ollama, puede que tengas otra instancia ya funcionando (eso es lo habitual tras cierres bruscos, reinicios truncados o actualizaciones). Si es otro programa, tendrás que decidir si puedes moverlo de puerto o cambiar el puerto de Ollama (te enseñaremos cómo).
Guía paso a paso para solucionar problemas con el puerto 11434 de Ollama
1. Cerrar procesos en conflicto y liberar el puerto
Si tienes el error «bind: address already in use»:
En Windows: botón derecho sobre el icono de Ollama en la bandeja → “Salir de Ollama”. O usa el Administrador de tareas para ‘matar’ cualquier instancia de Ollama que siga activa.
En Mac / Linux: pkill ollama (cierras todas las instancias que están corriendo).
Vuelve a arrancar Ollama: en Mac, abre de nuevo la app o ejecuta ollama serve; en Linux, sudo systemctl start ollama; en Windows desde el menú Inicio.
Vuelve a probar el puerto y, si sigue el problema, mira si hay otros servicios ocupando ese mismo hueco de red. Si no puedes liberarlo, tendrás que cambiar el puerto de Ollama.
2. Cambiar el puerto de escucha de Ollama
¿El puerto sigue ocupado o necesitas abrir varios Ollama en la misma máquina? Puedes definir un puerto diferente usando la variable de entorno OLLAMA_HOST:
En Windows: ve a Configuración → Sistema → Configuración avanzada → Variables de entorno, crea una nueva llamada OLLAMA_HOST con el valor 127.0.0.1:11435 (o el que prefieras).
En Mac/Linux desde terminal: export OLLAMA_HOST=127.0.0.1:11435 y luego ollama serve (para esa sesión).
En Linux Systemd, edita el servicio: sudo systemctl edit ollama.service y añade: [Service] Environment=»OLLAMA_HOST=0.0.0.0:11434″ Luego reinicia con sudo systemctl daemon-reload && sudo systemctl restart ollama
No olvides ajustar las apps cliente o UIs web para que apunten al nuevo puerto.
3. Permitir conexiones remotas: hacer el puerto accesible en la red o desde Docker
Por defecto, Ollama solo escucha en localhost por seguridad. Pero si quieres que sea accesible desde otras máquinas de la red (LAN, otra máquina virtual, contenedores en Docker o apps web), debes ligar Ollama a todas las interfaces:
export OLLAMA_HOST=0.0.0.0:11434 antes de ejecutar ollama serve.
En systemd, igual que el ejemplo anterior.
Así Ollama será visible para cualquier dispositivo autorizado en tu red. ¡Ojo! Si tu PC recibe conexiones externas, ponle un firewall y/o ponlo tras un reverse proxy seguro (NGINX, Caddy) porque la API no tiene autenticación nativa por defecto.
Desde otro PC de la LAN podrás conectar a http://IP-DEL-SERVIDOR:11434.
En Docker, asegúrate de mapear el puerto correctamente (-p 0.0.0.0:11434:11434) y revisar el flag –add-host (especialmente si usas Open WebUI).
4. Caso especial: acceso desde contenedores (Open WebUI, Docker Compose, etc.)
Uno de los bloques más frecuentes: la app cliente (Open WebUI, Pipelines, otra) no ve la API de Ollama aunque todo esté bien en local.
En Docker, muchas veces se pierde la referencia ‘localhost’. La solución es usar host.docker.internal (en Mac/Windows) o añadir explícitamente en el run de Docker --add-host=host.docker.internal:host-gateway (imprescindible en Linux).
En la configuración de Open WebUI (o la app Docker cliente), pon la URL de Ollama como http://host.docker.internal:11434.
Si usas Docker Compose y ambos servicios (Ollama y la app cliente) corren como servicios, puedes poner la URL como http://ollama:11434 (el nombre del servicio en el YAML) gracias al DNS interno de Docker-Compose.
Siempre conviene testear conectividad desde dentro del contenedor, por ejemplo:
Verás el JSON de tus modelos locales si está bien la red.
Ollama y el puerto 11434 en combinación con otras apps de escritorio (Levante, Cherry Studio, Msty)
Hoy día, usar Ollama 100% vía terminal se queda corto. El ecosistema de apps de escritorio que consumen la API de Ollama crece cada mes, y la experiencia de usuario sube muchos puntos. Las aplicaciones más conocidas son:
Levante — Enfocada en cumplimiento europeo, integración con RGPD, y una interfaz pulida, mezcla modelos locales y cloud en el mismo chat.
Cherry Studio — Muy visual, con un enorme catálogo de asistentes y plantillas preconfiguradas, fuerte en la comunidad asiática e internacional.
Msty — Orientada a flujo de notas y comparativas side-by-side de varias IAs simultáneamente y uso de «Knowledge Stacks» para consultas RAG.
¿Qué tienes que saber para conectarlas a tu Ollama local?
1. Verifica que Ollama esté en ejecución: usa curl http://localhost:11434/api/tags. Si da error, revisa si tienes que relanzar el proceso (ver apartado anterior para tu OS).
2. Descarga al menos un modelo antes de abrir la app: ollama pull qwen3:4b o el modelo que prefieras.
3. La configuración dentro de la app suele ser trivial: Levante y Msty detectan Ollama automáticamente. Cherry Studio puede requerir poner la base URL http://localhost:11434/v1 como endpoint de «OpenAI compatible» y rellenar la API Key con cualquier cadena (Ollama ignora su valor).
4. Si quieres acceder a Ollama desde otro ordenador de la red, recuerda lanzar Ollama con OLLAMA_HOST=0.0.0.0:11434 ollama serve y que la app cliente apunte a http://IP-SERVIDOR:11434.
5. Si la respuesta es muy lenta, probablemente Ollama está forzando uso de la CPU y no la GPU. Puedes verificarlo con ollama ps (columna PROCESSOR = gpu), nvidia-smi en Windows/Linux NVIDIA, o mirar el ‘Monitor de Actividad’ en Mac. Si ves un cuello de botella de RAM, baja a modelos más pequeños.
Solución de problemas habituales relacionados con el puerto 11434
La app cliente dice “offline”, pero Ollama responde en local: reinicia ambos, asegúrate de que la base URL es exacta y sin espacios, y que no haya proxies o firewalls internos bloqueando la conexión local.
La lista de modelos está vacía desde la app, pero ‘ollama list’ funciona: Puede deberse a que la app espera el endpoint OpenAI-compatible /v1 (usa http://localhost:11434/v1). O estás apuntando a un puerto erróneo.
Problemas de CORS: si usas una UI web servida desde otro puerto/origen, pon OLLAMA_ORIGINS="*" ollama serve para aceptar peticiones externas, o limita por seguridad a los origins que necesitas.
“No puedo conectar desde otra máquina”: revisa que Ollama escucha en 0.0.0.0 y que el cortafuegos del sistema no esté bloqueando el puerto 11434.
El modelo se descarga de RAM tras un rato: setea OLLAMA_KEEP_ALIVE=-1 y así mantendrás el modelo cargado indefinidamente.
Cómo abrir, reenviar o tunelar el puerto 11434 de Ollama para acceso remoto o integración nube
Además de la configuración local, es habitual querer exponer tu Ollama a internet para acceder a tus modelos desde cualquier parte, integrar con apps móviles, equipos o flujos corporativos. Pero ojo: esto implica riesgos si no lo haces bien.
Solución rápida: túneles seguros con Pinggy o cloudflared. Puedes exponer de forma segura el puerto sin abrirlo en el router, usando comandos SSH tipo: ssh -p 443 -R0:localhost:11434 -t [email protected] u:Host:localhost:11434 Esto crea una URL pública segura donde tus apps pueden llamar a tu Ollama de casa o del CPD sin abrir puertos internos.
Reverse proxy con nginx o caddy: Pon en producción Ollama siempre detrás de un reverse proxy, nunca expongas el 11434 directo a internet. Así puedes forzar autenticación, HTTPS, filtrar IPs, limitar peticiones, hacer rate limiting y dejar logs.
Uso empresarial: listas blancas de IP, logs y auditoría. En entornos críticos, no dejes nunca la API abierta. Aplica whitelists y monitorización constante.
Configuración avanzada y personalización: variables de entorno y buenas prácticas
Dominar el uso de variables de entorno en Ollama es la diferencia entre una instalación ‘insuficiente’ o una plataforma profesional lista para producciones complejas.
OLLAMA_HOST – Indica interfaz y puerto de escucha.
OLLAMA_MODELS – Cambia la ubicación donde se descargan y guardan los modelos grandes. Útil si tu disco principal va justo de espacio.
OLLAMA_ORIGINS – Lista de orígenes que pueden hacer llamadas CORS (web UIs, apps externas…)
OLLAMA_DEBUG – Activa logs detallados para depuración a fondo.
OLLAMA_KEEP_ALIVE – Duración en la que el modelo permanece en memoria tras usarlo.
El método óptimo para fijar estas variables depende del sistema:
Mac: launchctl setenv VARIABLE valor
Linux (systemd): sudo systemctl edit ollama.service añadiendo Environment="OLLAMA_HOST=0.0.0.0:11434"
Windows: Editor de Variables de entorno del sistema para usuario o todo el equipo
Docker: añade -e VARIABLE=valor al ‘docker run’
Ollama y aceleración GPU: rendimiento y troubleshooting
Muchos usuarios se quejan de que su IA «va como un caracol» hasta que descubren que Ollama está ejecutando los modelos en la CPU en lugar de la GPU. Controlar dónde se cargan los modelos es esencial para rendimiento realista (y no frustrarte tras un despliegue).
En Mac Apple Silicon, Ollama usa Metal automáticamente. Si el modelo es demasiado grande para tu RAM unificada, va directo a disco y la latencia se dispara.
En Windows y Linux con NVIDIA, revisa que tienes el driver CUDA reciente y que el proceso de Ollama aparece en nvidia-smi cuando haces inferencias.
Las GPUs AMD en Windows aún tienen soporte experimental. En Linux usan ROCm (con la etiqueta :rocm en Docker y el driver correcto).
Para limitar uso de GPU: export CUDA_VISIBLE_DEVICES=0 o variable equivalente para AMD.
Verifica la columna PROCESSOR con ollama ps: debe aparecer ‘gpu’. Si sale ‘cpu’, revisa drivers o configuración, logs con OLLAMA_DEBUG=1 y sesiones de Docker con --gpus=all.
Integración con Open WebUI y otras interfaces web: claves para montar tu ‘propio ChatGPT’ con Ollama
Open WebUI es la puerta de entrada más popular para montar un chat privado tipo ChatGPT, pero a tu manera y en tus propios servidores o portátiles. La combinación estrella hoy es Open WebUI corriendo en Docker y Ollama como backend local o remoto.
Paso 1: Instala Ollama en tu máquina. curl -fsSL https://ollama.com/install.sh | sh para Linux/Mac.
Paso 2: Descarga tu modelo con ollama pull llama3.2:3b, por ejemplo.
Paso 3: Levanta el contenedor de Open WebUI con el comando canónico (con el flag de host-gateway si no usas Mac/Win): docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:main
Configura OLLAMA_BASE_URL como http://host.docker.internal:11434 en los ajustes de Open WebUI para que funcione bien en cualquier SO/Docker.
Si ambos corren por Docker Compose, utiliza OLLAMA_BASE_URL=http://ollama:11434. Revisa que la red de Docker Compose lo permita y que los volúmenes estén bien mapeados para mantener tus modelos y chats después de reiniciar contenedores.
Entradas avanzadas: RAG, audio (voz a texto y texto a voz), Pipelines y MCP
Open WebUI, Levante y otras apps permiten extraer el máximo jugo de Ollama y el puerto 11434 como backend no solo para chats, sino también para:
RAG (Recuperación Aumentada por Recuperación): Haz que tus modelos entiendan y respondan sobre PDFs, Word, Markdown, TXT de tu propio disco. Simplemente los subes y Open WebUI los indexa con modelos tipo nomic-embed-text.
Audio STT (speech-to-text con Whisper local) y TTS (text-to-speech): Puedes hablar con tu IA local y que te lea las respuestas, eligiendo motores locales o en la nube.
Pipelines y Functions: Extiende la funcionalidad con filtros de mensajes, integraciones Python, acciones custom y encadenamiento de modelos de forma totalmente modular.
MCP (Model Context Protocol): Da a tus modelos acceso a herramientas externas (búsqueda web, Slack, GitHub…) mediante el mismo protocolo que usan Claude Desktop o Cursor.
Mejorando la seguridad y escalabilidad: túneles seguros, reverse proxies, autenticación y mantenimiento
Cuando tu deployment ya no es ‘solo para ti’, la seguridad toma el protagonismo. Nunca expongas el puerto 11434 de Ollama directamente a internet, mucho menos en producción. Aplica siempre alguna de estas estrategias:
Reverse proxy (nginx, Caddy, Traefik) con HTTPS autenticado: solo el proxy ve a Ollama y tú controlas acceso (auth básica/token, IP restriction, logs…)
Túneles cloud (Cloudflare Tunnel, Pinggy): Sin puertos abiertos, url segura y TLS, ideal para pequeñas empresas o demos temporales.
En producción, combina registro deshabilitado en UIs (como Open WebUI), IPs restringidas, logs y backup.
Periodos de mantenimiento: Usa volúmenes nombrados en Docker para no perder historial o chats, haz copias antes de upgrades importantes y regenera las imágenes siempre tras un ‘docker pull’ de la última versión de Open WebUI.
Soluciones a problemas menos frecuentes: tips y trucos avanzados
Errores de permisos al acceder a directorios de modelos: Otorga permisos de escritura al usuario/grupo ‘ollama’ (sudo chown -R ollama:ollama /ruta/a/modelos).
Descargas de modelos muy lentas: Revisa tu conexión, configura HTTPS_PROXY si tu red usa proxy o VPNs.
Salida rara en Windows antiguo (←[?25h...): Actualiza a Terminal de Windows o usa WSL2.
Eliminar por completo Ollama: Para desinstalaciones limpias y sin basura residual, sigue los pasos específicos por sistema operativo (ver sección específica más arriba).
Buenas prácticas de integración Ollama + apps externas (VSCode, CodeGPT, OpenAI API y más)
Mucha gente utiliza Ollama a través de extensiones especializadas, sobre todo en entornos de desarrollo:
CodeGPT para VSCode: selecciona Ollama como proveedor y pega la base URL http://localhost:11434. Si la extensión marca «modelos no detectados», actualiza el plugin o revisa que Ollama esté corriendo.
La mayoría de librerías que funcionan con la API de OpenAI pueden apuntar directas a Ollama, poniendo ‘cualquier cosa’ en la API Key (Ollama no valida ese valor).
Si aparece algún error extraño tras actualizar Ollama, elimina la API Key de las variables de entorno y vuelve a probar: suelen quedarse arrastrando configuraciones antiguas.
Comparativa entre las principales apps de escritorio para Ollama y su integración con el puerto 11434
Levante: ideal si buscas cumplimiento europeo, integración con servidores MCP, y opción de mezclar modelos cloud/local en la misma chat. Detecta Ollama sola y acepta configuraciones avanzadas.
Cherry Studio: fuerte en personalización estética, plantillas pre-cargadas y edición de prompts. La configuración manual es simple y soporta múltiples proveedores a la vez.
Msty: si priorizas flujo tipo notas, comparación lado a lado y gestión de documentos/RAG.
Elijas la que elijas, la clave está en tener Ollama lanzado, la base URL bien definida (http://localhost:11434 o http://host.docker.internal:11434 si la app corre en Docker), y al menos un modelo descargado de inicio.
