mrsaynothing.dev
Connection refused en 11434: quien llama, quien escucha, seis causas
Un curl parte el problema en dos — causas del lado del servidor rankeadas, la trampa del localhost en el contenedor, el binding LAN, y la instancia perdida que roba el puerto.
■ space · carril de prosa
Connection refused = nada escucha en el puerto 11434 donde llamaste. Lo dice el sistema; Ollama nunca vio la petición.
Ejecuta curl http://localhost:11434 — Ollama is running significa que el servidor está bien y que el cliente está llamando al sitio equivocado.
¿Rechazado también en el host? Baja por las seis causas de abajo — la más probable primero, un comando cada una.
EL MAPA DE QUIEN LLAMA
La mitad de los reportes son un problema de colocación: el que escucha está bien — quien llama llama desde un sitio que el escucha no alcanza.
un contenedor en Linux pelado necesita --add-host=host.docker.internal:host-gateway — la propia documentación de Docker nombra esa bandera exactamente para este caso · contenedor-a-contenedor en una misma red: http://<nombre-servicio>:11434
LAS SEIS CAUSAS, RANKEADAS
De arriba abajo — la primera fila que calce con tu error trae el arreglo:
| Dónde lo ves | Causa probable | Arreglo |
|---|---|---|
ollama list también se rehúsa; servicio inactivo | Ollama nunca arrancó (o murió al bootear) | sudo systemctl enable --now ollama |
| Arranca, y minutos después se rehúsa otra vez | Bucle de crash — puerto tomado, disco lleno, env mala | journalctl -u ollama -n 50, arregla lo que nombre |
| El servidor responde en 11435, los clientes llaman al 11434 | Un OLLAMA_HOST a medida movió el puerto | Apunta a los clientes al puerto real |
127.0.0.1 funciona, localhost se rehúsa | localhost resuelve primero a IPv6 ::1 primero | Llama a 127.0.0.1, o bindea ambos |
| Host bien, contenedor rehusado | localhost dentro = el propio contenedor | host.docker.internal + host-gateway |
| Contenedor-a-contenedor rehusado | Usaste localhost en vez del nombre del servicio | http://<service-name>:11434 |
| Otra máquina de la LAN rehusada | Servidor bindeado solo al loopback (por defecto) | OLLAMA_HOST=0.0.0.0:11434 en el override |
| Funciona días, y un día se rehúsa sin avisar | Una segunda instancia arrancada a mano robó el puerto | ss -ltnp, mata al extraño, deja el servicio |
¿OLLAMA ESTÁ CORRIENDO?
Las versiones de escritorio (macOS, Windows) corren Ollama como aplicación en la bandeja, y es más fácil de cerrar de lo que la gente espera. La instalación Linux corre un servicio systemd que puede que jamás se haya habilitado tras un reboot. ollama list hacia el servidor responde con una tabla de modelos; si responde también con error de conexión, arranca el servidor y haz el arranque permanente:
systemctl status ollama
sudo systemctl enable --now ollama # start + survive reboots
journalctl -u ollama -n 50 # if it keeps dying, read whyverificación: systemctl is-active ollama → active · ollama list → una tabla de modelos
EL PUERTO, EL HOST, LA LAN
Ollama escucha en 127.0.0.1:11434 salvo aviso contrario. Un puerto a medida: si alguna vez pusiste OLLAMA_HOST=127.0.0.1:11435, el servidor responde en 11435 y cada cliente que sigue llamando al 11434 se come un rechazo — confirma qué está realmente escuchando con ss -ltn | grep 1143. La trampa IPv6: en algunas máquinas localhost resuelve primero a ::1 y un servidor bindeado 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 mientras curl http://localhost:11434 se rehúsa. Llama a 127.0.0.1, bindea ambos, o apunta a los clientes a la IP cruda.
Exponer a la LAN: por defecto Ollama se bindea solo al loopback — a propósito, porque la API no trae autenticación. Ponlo en el override de systemd y no en tu shell, para que el servicio lo vea de verdad:
sudo systemctl edit ollama
# [Service]
# Environment="OLLAMA_HOST=0.0.0.0:11434"
sudo systemctl restart ollamaverificación: ss -ltn | grep 11434 → 0.0.0.0:11434 · desde otra máquina: curl http://<host-ip>:11434 → «Ollama is running»
Dos vecinos del «refused» que son fallas distintas: un firewall que sigue bloqueando el 11434 produce timeouts, no rechazos — el rechazo significa un «no» activo, el timeout significa que los paquetes nunca llegaron. Y JavaScript de navegador llamando a la API desde otro origen necesita OLLAMA_ORIGINS configurado: esas llamadas llegan y se las devuelve la capa CORS, lo que se ve idéntico desde afuera.
Una conexión rechazada es un problema de colocación, no un programa roto: algo que debería escuchar no escucha, o quien llama llama desde un sitio que el escucha no alcanza.
VUELVE UNA Y OTRA VEZ
Entonces un proceso posee el puerto y el otro pierde la carrera sin parar. ss -ltnp | grep 11434 muestra el proceso que sostiene el socket; una segunda instancia de Ollama arrancada a mano es el ladrón de siempre. Mata al extraño, deja al servicio como único dueño, y el error se queda fuera.
verificación: ss -ltnp | grep 11434 → una línea, un PID — el servicio
Ollama superó las 181.000 estrellas en GitHub en septiembre de 2026 — más máquinas corriendo significa más de estas seis respuestas siendo necesitadas la misma semana que se buscan. Una vez que el server responde, el GPU que se rehúsa a usar es la próxima queja más común. El triaje está a un curl de distancia.
connect: Connection refused del núcleo se reprodujo en un banco de descarte donde nada escuchaba — antes que cualquier aplicación se metiera en escena.
fin del mapa de quién llama · nada fetchado · todo local