■ space · prose lane
Connection refused = nothing is listening on port 11434 where you called. The OS says so; Ollama never saw the request.
Run curl http://localhost:11434 — Ollama is running means the server is fine and the client is calling the wrong place.
Refused on the host too? Work down the six causes below — most likely first, one command each.
THE CALLER MAP
Half of all reports are a placement problem: the listener is fine — the caller is calling from a place the listener doesn't reach.
container on plain Linux needs --add-host=host.docker.internal:host-gateway — Docker's own docs name that flag for exactly this case · container-to-container on one network: http://<service-name>:11434
THE SIX CAUSES, RANKED
Work top to bottom — the first row that matches your error carries the fix:
| Where you see it | Likely cause | Fix |
|---|---|---|
ollama list refuses too; service inactive | Ollama never started (or died at boot) | sudo systemctl enable --now ollama |
| Starts, then refuses again minutes later | Crash loop — port taken, disk full, bad env | journalctl -u ollama -n 50, fix what it names |
| Server answers on 11435, clients call 11434 | A custom OLLAMA_HOST moved the port | Point clients at the real port |
127.0.0.1 works, localhost refuses | localhost resolves to IPv6 ::1 first | Call 127.0.0.1, or bind both |
| Host fine, container refused | localhost inside = the container itself | host.docker.internal + host-gateway |
| Container-to-container refused | Used localhost instead of the service name | http://<service-name>:11434 |
| Other machine on the LAN refused | Server bound to loopback only (default) | OLLAMA_HOST=0.0.0.0:11434 in the override |
| Works for days, refused without warning | A hand-started second instance stole the port | ss -ltnp, kill the stray, keep the service |
IS OLLAMA ACTUALLY RUNNING?
The desktop builds (macOS, Windows) run Ollama as a tray application, and it is easier to quit than people expect. The Linux install runs a systemd service that may never have been enabled after a reboot. ollama list reaching the server answers with a model table; if it answers with a connection error too, start the server and make the start permanent:
systemctl status ollama
sudo systemctl enable --now ollama # start + survive reboots
journalctl -u ollama -n 50 # if it keeps dying, read whyverify: systemctl is-active ollama → active · ollama list → a model table
THE PORT, THE HOST, THE LAN
Ollama listens on 127.0.0.1:11434 unless told otherwise. A custom port: if you ever set OLLAMA_HOST=127.0.0.1:11435, the server answers on 11435 and every client still calling 11434 gets refused — confirm what is actually listening with ss -ltn | grep 1143. The IPv6 trap: on some machines localhost resolves to ::1 first and a server bound only to 127.0.0.1 never sees those attempts — the discriminating test costs two seconds: curl http://127.0.0.1:11434 works while curl http://localhost:11434 refuses. Call 127.0.0.1, bind both, or point clients at the raw IP.
Exposing to the LAN: by default Ollama binds to loopback only — by design, since the API has no authentication. Set it in the systemd override rather than your shell so the service actually sees it:
sudo systemctl edit ollama
# [Service]
# Environment="OLLAMA_HOST=0.0.0.0:11434"
sudo systemctl restart ollamaverify: ss -ltn | grep 11434 → 0.0.0.0:11434 · from another machine: curl http://<host-ip>:11434 → "Ollama is running"
Two neighbours of "refused" that are different failures: a firewall still blocking 11434 produces timeouts, not refusals — refused means an active "no", timeout means the packets never arrived. And browser JavaScript calling the API from another origin needs OLLAMA_ORIGINS set: those calls arrive and are turned away at the CORS layer, which looks identical from the outside.
A refused connection is a placement problem, not a broken program: something that should be listening isn't, or the caller is calling from a place the listener doesn't reach.
IT KEEPS COMING BACK
Then one process owns the port and another keeps losing the race. ss -ltnp | grep 11434 shows the process holding the socket; a second Ollama instance started by hand is the usual thief. Kill the stray, leave the service as the single owner, and the error stays gone.
verify: ss -ltnp | grep 11434 → one line, one PID — the service
Ollama crossed 181,000 GitHub stars in September 2026 — more machines running it means more of these six answers being needed the same week they are searched. Once the server answers, the GPU it refuses to use is the next most common complaint. The triage is one curl away.
connect: Connection refused was reproduced on a throwaway bench box with nothing listening — before any application got involved.
end of the caller map · nothing fetched · everything local