> Ollama connection refused？60 秒定位法▋

The error never lies about what it means: curl: (7) Failed to connect to localhost port 11434: Connection refused is your operating system reporting that nothing is listening on port 11434. Ollama is not "broken", the model is not corrupted, and the internet's reflex answer — reinstall — misses six boring causes that take a minute each to rule out.

Run the triage command first. It splits the problem in half before you read another section:

curl http://localhost:11434

Ollama is running means the server is fine and your client is calling the wrong place — skip to the host questions. Connection refused means the server side needs work. I reproduced the refusal itself on a throwaway bench box with nothing listening: the kernel answers bash: connect: Connection refused before any application ever gets involved.

Why does Ollama say connection refused?

Because a TCP connect arrived at a host where no socket holds port 11434. That is the whole mechanism — one of six things is true, and they are ranked here by how often each one is the answer, most likely first.

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.

# Linux: is the service alive?
systemctl status ollama

# The direct check that works everywhere:
ollama list

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:

sudo systemctl enable --now ollama   # Linux: start + survive reboots
journalctl -u ollama -n 50           # if it keeps dying, read why

A service that starts and immediately dies shows up here as a crash loop, and journalctl prints the reason — port already taken, disk full, bad environment override.

Is it the port, or the host you're calling?

Ollama listens on 127.0.0.1:11434 unless told otherwise. Two classic mismatches:

A custom port. If you (or a tutorial you followed) 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:

ss -ltn | grep 1143

Expect one line holding 127.0.0.1:11434. No line at all means the server is down (previous section). A different port or address means your clients are the ones out of date.

localhost versus 127.0.0.1. On some machines localhost resolves to the IPv6 address ::1 first, and a server bound only to 127.0.0.1 never sees those connection attempts. The discriminating test costs two seconds:

curl http://127.0.0.1:11434   # works,  and curl http://localhost:11434 refuses

If the raw IP works and the name does not, bind the server to both or point your clients at 127.0.0.1 directly.

Why does it work on the host but not from Docker?

This is the most common flavor in the wild — it is why the autocomplete for this error is full of n8n, Open WebUI and VS Code extensions. Every container that calls http://localhost:11434 is calling itself: inside the container, 127.0.0.1 is the container's own loopback, where nothing listens.

Caller	Correct URL for the host's Ollama
Container on Docker Desktop	http://host.docker.internal:11434
Container on plain Linux	http://host.docker.internal:11434 plus --add-host=host.docker.internal:host-gateway
Container on the same Docker network	http://<service-name>:11434
Another machine on your LAN	http://<machine-ip>:11434 (see next section)

The host-gateway flag comes from Docker's own documentation for exactly this case, and it is the one line that fixes half of all "Ollama connection refused" reports filed from containers.

How do I expose Ollama to other machines?

By default Ollama binds to loopback only — by design, since the API has no authentication. Exposing it is one environment variable, 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"

Then sudo systemctl restart ollama and confirm with ss -ltn | grep 11434 — the address column should now read 0.0.0.0:11434. Two follow-ups people skip: a firewall still blocking 11434 produces timeouts rather than refusals (different failure, same port), and browser JavaScript calling the API from another origin needs OLLAMA_ORIGINS set, per Ollama's own FAQ — the browser 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.

What if 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.

For the rest of the cluster: once the server answers, the GPU it refuses to use is the next most common complaint, and running GGUF models locally covers the load side. Both live in the local LLM hub.

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. The triage is one curl away.