mrsaynothing.devOllama connection refused on 127.0.0.1:11434 — every fix
Connection refused means nothing is listening on 11434. The three causes — server down, OLLAMA_HOST moved, wrong machine — and the checks that settle each one.
Refused is not blocked — refused means nothing answered a door that was open. On a default install the fix is starting the server:
systemctl enable --now ollamaon Linux, orollama servein a terminal. If the port checks empty withss -tln | grep 11434, nothing is listening; if it shows a listener on a different address than you are curling,OLLAMA_HOSTis the culprit.
For anyone who installed Ollama, ran the curl from the README, and got Connection refused instead of a model list. The error is honest: on port 11434 — Ollama's default since its first release, per the project's docs — some process must be listening before any HTTP request can succeed. One confession before the fixes: I tried to reproduce the failure on a fresh microVM this morning and the runner died twice before the install finished, so this piece is the record read closely, not a bench receipt — the test box refused too. Our own search board holds this exact query at position 10 with zero clicks over 28 days (GSC, pulled 2026-10-19), which says plenty of people curl that port and stop at the error.
Why is 127.0.0.1:11434 refusing connections?
A TCP refusal is the kernel speaking, not the app: your packet reached the machine and found no socket bound to that port, so the kernel answered RST and curl printed Connection refused. Three causes cover essentially every case. One: Ollama is not running — the install finished but no serve process ever started. Two: it is running but bound somewhere else, because OLLAMA_HOST moved it to another address or port. Three: you are asking the wrong machine — the classic version is curling 127.0.0.1 from inside a container, where that address means the container, not your host. A firewall almost never produces this exact error; a dropped packet times out instead, it never refuses. I call it the unlocked-door refusal: the door was wide open and nobody was home — lock the door and the story changes to silence.
ss -tln | grep 11434verify: empty output = nobody home (cause 1 or a host mix-up). A line like LISTEN 0 128 127.0.0.1:11434 = somebody is home, and your problem is which address you are asking.
How do I fix Ollama connection refused?
Work down the list and stop when the curl says the magic words.
What is OLLAMA_HOST actually doing?
OLLAMA_HOST is read once, when the server starts — not per request. Default: 127.0.0.1:11434, loopback only. Set it to 0.0.0.0:11434 and Ollama listens on every interface, which is what you want when another machine or container needs to reach it — and what you want to think twice about on a shared network, because the default install has no auth on this endpoint. The trap that generates half the forum threads: exporting OLLAMA_HOST in your shell while the systemd unit keeps serving under the old environment. The unit needs the variable in its own override:
sudo systemctl edit ollama
# add:
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
sudo systemctl restart ollamaverify: after the restart, ss -tln | grep 11434 must show the new bind address — 0.0.0.0:11434, not 127.0.0.1:11434. If the line still shows loopback, the server never picked up the change, and no client fix will help.
Why does it work in the terminal but not from Docker or n8n?
Because 127.0.0.1 is whoever is asking. From inside a container, loopback is the container itself — and Ollama is not running in there. The fixes, in order of honesty: run the container with --add-host=host.docker.internal:host-gateway and point your client at http://host.docker.internal:11434; or use the host's LAN IP directly once Ollama binds 0.0.0.0. This is the entire story behind the "n8n ollama connection refused" threads — the workflow tool is not broken, it is just a container asking its own loopback for a model server that lives one network away.
Is the Windows refusal different?
The error text is identical; the ceremony differs. The Windows install runs Ollama as a background app — the tray icon is the whole service, so an exit from the tray is a stop, and the next curl refuses. Set OLLAMA_HOST through System Properties → Environment Variables (then fully quit and reopen the app — env changes do not reach a running process), and test with the same curl from PowerShell. One reframe worth carrying: on Windows people blame the firewall first, but a firewall that drops gives you a timeout after a hang; a refusal still means nobody home. Check the tray before you check the shield.
| Symptom | Cause | Fix |
|---|---|---|
refused, ss shows nothing | server never started | systemctl enable --now ollama / ollama serve |
refused, ss shows a listener on another address | OLLAMA_HOST moved the bind | curl the address it actually shows, or fix the unit's override |
| works in terminal, refused from a container | container loopback ≠ host loopback | host.docker.internal + OLLAMA_HOST=0.0.0.0 |
| hangs, then times out | firewall dropping (not refusing) | different problem — allowlist the port |
| refused after reboot every time | start without enable | systemctl enable ollama |
The deep cut: refused vs dropped, in kernel terms
A refusal is an active RST from the destination machine's kernel — the packet got there, matched no listening socket, and the kernel answered RST. A drop is silence: a firewall rule ate the packet and nothing ever answers, so curl hangs through its retries and reports a timeout. The asymmetry does the diagnosing: refused convicts the endpoint and clears the network path; a timeout inverts it. (A REJECT rule in nftables can fake a refusal by sending RST itself — rare on home setups, worth knowing on servers.) The same logic tells you OLLAMA_HOST changes always need a restart: env vars are inherited at process birth, and systemctl restart is the birth.