mrsaynothing.devOllama connection refused: el triaje en 60 segundos
Connection refused significa que nada escucha en el puerto 11434. Las seis causas reales, ordenadas, más el comando curl que te dice cuál te tocó.
El error nunca miente sobre lo que significa: curl: (7) Failed to connect to localhost port 11434: Connection refused es tu sistema operativo reportando que nada escucha en el puerto 11434. Ollama no está "roto", el modelo no está corrompido, y la respuesta refleja de internet — reinstalar — pasa de largo ante seis causas aburridas que se descartan de a un minuto cada una.
Corre primero el comando de triaje. Parte el problema por la mitad antes de leer otra sección:
curl http://localhost:11434
Ollama is running significa que el servidor está bien y tu cliente llama al lugar equivocado — salta a las preguntas de host. Connection refused significa que el lado del servidor necesita trabajo. Reproduje el rechazo en sí en una máquina de bench desechable sin nada escuchando: el kernel responde bash: connect: Connection refused antes de que una aplicación se entere.
¿Por qué Ollama dice connection refused?
Porque una conexión TCP llegó a una máquina donde ningún socket sostiene el puerto 11434. Ese es todo el mecanismo — una de estas seis cosas es cierta, y están ordenadas por frecuencia, la más probable primero.
¿Ollama está corriendo de verdad?
Las versiones de escritorio (macOS, Windows) corren Ollama como aplicación de bandeja, y es más fácil de cerrar de lo que la gente cree. La instalación en Linux usa un servicio systemd que quizá nunca se habilitó después de un reinicio.
# Linux: ¿el servicio está vivo?
systemctl status ollama
# El chequeo directo que funciona en todos lados:
ollama list
Si ollama list alcanza el servidor, responde con una tabla de modelos. Si también responde error de conexión, arranca el servidor y vuelve permanente el arranque:
sudo systemctl enable --now ollama # Linux: arrancar + sobrevivir reinicios
journalctl -u ollama -n 50 # si sigue muriendo, lee por qué
Un servicio que arranca y muere enseguida aparece aquí como un crash loop, y journalctl imprime la razón — puerto ya tomado, disco lleno, override de entorno incorrecto.
¿Es el puerto, o la máquina que llamas?
Ollama escucha en 127.0.0.1:11434 salvo indicación contraria. Dos desajustes clásicos:
Un puerto personalizado. Si tú — o un tutorial que seguiste — pusiste alguna vez OLLAMA_HOST=127.0.0.1:11435, el servidor responde en 11435 y cada cliente que sigue llamando al 11434 recibe un rechazo. Confirma qué escucha realmente:
ss -ltn | grep 1143
Deberías ver una línea con 127.0.0.1:11434. Ninguna línea: el servidor está caído (sección anterior). Otro puerto u otra dirección: tus clientes son los que están desactualizados.
localhost contra 127.0.0.1. En algunas máquinas localhost resuelve primero a la dirección IPv6 ::1, y un servidor atado solo a 127.0.0.1 nunca ve esos intentos. El test que discrimina cuesta dos segundos:
curl http://127.0.0.1:11434 # funciona, y curl http://localhost:11434 rechaza
Si la IP cruda funciona y el nombre no, ata el servidor a ambos o apunta tus clientes a 127.0.0.1 directamente.
¿Por qué funciona en el host pero no desde Docker?
Esta es la variante más común en la calle — por eso el autocompletado de este error está lleno de n8n, Open WebUI y extensiones de VS Code. Todo contenedor que llama a http://localhost:11434 se llama a sí mismo: dentro del contenedor, 127.0.0.1 es el loopback del contenedor, donde nada escucha.
| Quién llama | URL correcta hacia el Ollama del host |
|---|---|
| Contenedor en Docker Desktop | http://host.docker.internal:11434 |
| Contenedor en Linux puro | http://host.docker.internal:11434 más --add-host=host.docker.internal:host-gateway |
| Contenedor en la misma red Docker | http://<nombre-del-servicio>:11434 |
| Otra máquina de tu LAN | http://<ip-de-máquina>:11434 (siguiente sección) |
El flag host-gateway viene de la propia documentación de Docker para exactamente este caso, y es la única línea que arregla la mitad de los reportes de "Ollama connection refused" que llegan desde contenedores.
¿Cómo expongo Ollama a otras máquinas?
Por defecto Ollama se ata solo al loopback — a propósito, porque la API no tiene autenticación. Exponerlo es una variable de entorno; ponla en el override de systemd y no en tu shell para que el servicio la vea de verdad:
sudo systemctl edit ollama
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Luego sudo systemctl restart ollama y confirma con ss -ltn | grep 11434 — la columna de dirección debe leer 0.0.0.0:11434. Dos continuaciones que la gente salta: un firewall que sigue bloqueando el 11434 produce timeouts en vez de rechazos (otro fallo, mismo puerto), y el JavaScript del navegador que llama a la API desde otro origen necesita OLLAMA_ORIGINS, según la FAQ de Ollama — las llamadas del navegador llegan y las rechaza la capa CORS, lo que se ve idéntico desde afuera.
Un rechazo de conexión es un problema de ubicación, no un programa roto: algo que debería estar escuchando no escucha, o quien llama llama desde un lugar al que el que escucha no llega.
¿Y si sigue volviendo?
Entonces un proceso tiene el puerto y otro pierde la carrera cada vez. ss -ltnp | grep 11434 muestra el proceso que sostiene el socket; una segunda instancia de Ollama arrancada a mano es la ladrona habitual. Mata a la intrusa, deja al servicio como único dueño, y el error desaparece.
Para el resto del clúster: una vez que el servidor responde, la GPU que se niega a usar es la queja más común que sigue, y correr modelos GGUF en local cubre el lado de la carga. Ambos viven en el hub de LLM local.
Ollama cruzó las 181.000 estrellas en GitHub en septiembre de 2026 — más máquinas corriendo implica más de estas seis respuestas buscadas la misma semana en que se tipean. El triaje está a un curl de distancia.