Ollama 'Connection Refused' on Port 11434: Fix It Fast

If you’ve hit Error: dial tcp 127.0.0.1:11434: connect: connection refused — or your app says “ollama could not connect” — the error is more helpful than it looks. It’s not a model problem, a download problem, or a permissions riddle. It means your client tried to open a TCP connection to the Ollama API on port 11434 and nothing on the other end answered. In plain terms: the Ollama server isn’t listening where you’re knocking. This guide walks through the five real causes in the order you should check them, with the exact commands to confirm each one, plus a per-OS quick reference and the safe way to expose Ollama to your other devices once it’s reachable.

Decode the error: who is refusing the connection

“Connection refused” is a specific TCP-level signal, and it’s worth understanding because it rules out half the universe of possible problems. When your machine sends a connection request to 127.0.0.1:11434 and gets refused, it means the packet reached the host but no process is accepting connections on that port. Compare that to a timeout (something is there but slow or firewalled into silence) or name resolution failure (the address itself is bad).

So dial tcp 127.0.0.1:11434: connection refused translates to: the Ollama HTTP server is not running, not bound to that address, or has died. Ollama is a client/server tool — the ollama command you type is just a thin client that talks to a background server over http://127.0.0.1:11434. If that server isn’t up, every command and every API call fails the same way. Your job is simply to figure out why the server isn’t answering on 11434, and there are only a handful of reasons.

A fast first probe — does anything answer at all?

curl http://127.0.0.1:11434

A healthy server returns the plain text Ollama is running. Connection refused here confirms the diagnosis: nothing is listening. Now work through the fixes.

Fix 1: The server isn’t running

This is the cause about 70% of the time, especially right after install or a reboot. How you start the server depends on how Ollama was installed, and people frequently mix the three methods up.

• The Linux install script (curl -fsSL https://ollama.com/install.sh | sh) sets up a systemd service that should auto-start. Check it:

  systemctl status ollama

  If it’s inactive (dead) or failed, start and enable it:

  sudo systemctl start ollama
  sudo systemctl enable ollama

• Manual / foreground mode. If you installed via go install, a tarball, or you just want to see logs live, run the server yourself in its own terminal:

  ollama serve

  Leave that window open — the server runs in the foreground. In a second terminal, ollama run llama3.2 will now work. A classic gotcha here: if systemd is already running Ollama, ollama serve will itself fail with “address already in use” because the port is taken (that’s Fix 2 territory).

• The macOS / Windows desktop app. On these platforms Ollama ships as a tray/menubar app, not a service. If it’s not running, nothing listens on 11434. Look for the llama icon in the menu bar (macOS) or system tray (Windows). No icon? Launch Ollama from Applications / Start Menu and wait for it to appear. Quitting the tray app stops the server entirely.

Rule of thumb: one and only one of these should be running. Don’t run the tray app and ollama serve. If you’re new to all this, the full Ollama install walkthrough covers each platform’s setup cleanly.

Fix 2: Port 11434 is already in use

If ollama serve returns something like Error: listen tcp 127.0.0.1:11434: bind: address already in use, the server can’t start because another process — often a second, forgotten Ollama instance — already holds the port. Find the culprit.

On Linux / macOS:

lsof -i :11434

or

ss -tlnp | grep 11434

On Windows (PowerShell):

netstat -ano | findstr 11434

That last column on Windows is the PID; cross-reference it in Task Manager. On Linux/macOS, lsof names the process directly. Common findings:

What you see	What it means	What to do
A second ollama PID	Duplicate server (e.g. tray app + manual serve)	Stop one of them
ollama under systemd	Service already owns the port	Use it — don’t run ollama serve too
Some unrelated process	A different app grabbed 11434	Reassign Ollama’s port (below)

If you genuinely need to keep the conflicting app, move Ollama to another port via the OLLAMA_HOST environment variable, then point your clients at the new port:

OLLAMA_HOST=127.0.0.1:11500 ollama serve

Remember to set OLLAMA_HOST=http://127.0.0.1:11500 for your client tools too, or they’ll keep dialing the old 11434 and keep getting refused.

Fix 3: Wrong bind address (Docker, WSL2, remote)

This is the sneaky one, and it’s the usual culprit when “ollama 11434 not working” despite the server clearly running. By default Ollama binds to 127.0.0.1 (loopback only), which is correct and private for same-machine use. But the moment a different network namespace is involved, 127.0.0.1 no longer means “the machine running Ollama” — it means “inside this container/VM.”

• Docker: A container’s 127.0.0.1 is the container itself, not the host. If Ollama runs on the host and your app runs in a container, point the app at http://host.docker.internal:11434 (Docker Desktop) or the host’s LAN IP. If Ollama runs inside a container, you must publish the port (-p 11434:11434) and make the server listen on all interfaces by setting OLLAMA_HOST=0.0.0.0 in the container environment — otherwise it binds to the container’s loopback and the published port reaches nothing.

• WSL2: Windows and your WSL2 distro are effectively two machines on a virtual network. If Ollama runs on Windows, code inside WSL2 reaching 127.0.0.1:11434 hits WSL’s own loopback. Use the Windows host IP, or run Ollama inside WSL2 to keep everything on one side.

• Remote server: To reach Ollama on another box, the server must bind beyond loopback. On the Ollama host set the environment variable and restart:

  OLLAMA_HOST=0.0.0.0:11434

  On a systemd install, add it with sudo systemctl edit ollama:

  [Service]
  Environment="OLLAMA_HOST=0.0.0.0:11434"

  Then sudo systemctl daemon-reload && sudo systemctl restart ollama. Binding to 0.0.0.0 exposes Ollama to your whole network — Ollama ships with no authentication, so only do this on a network you trust. More on doing this safely at the end.

Fix 4: A firewall is blocking the connection

Same-machine loopback (127.0.0.1) traffic is almost never firewalled, so if a local curl to 11434 fails, suspect Fixes 1–3 first. Firewalls become the real cause once you’re crossing machines (the LAN/remote case from Fix 3): the server is up and bound to 0.0.0.0, but packets from another device never arrive.

• Linux (ufw): sudo ufw allow 11434/tcp (scope it to your subnet if you can: sudo ufw allow from 192.168.1.0/24 to any port 11434).
• Linux (firewalld): sudo firewall-cmd --add-port=11434/tcp --permanent && sudo firewall-cmd --reload.
• Windows: Windows Defender Firewall prompts on first bind; if you dismissed it, add an inbound rule for TCP 11434 in Windows Defender Firewall with Advanced Security.
• macOS: The application firewall is per-app, not per-port — allow the Ollama app under System Settings → Network → Firewall if you enabled it.

Confirm reachability from the client machine, not the server:

curl http://SERVER_LAN_IP:11434

If that still refuses while a local curl on the server succeeds, the firewall (or Fix 3’s bind address) is your remaining suspect.

Fix 5: The server crashed silently (GPU driver eject)

Sometimes the server was running, then a request — usually loading a model onto the GPU — killed it. From the client’s side this looks identical to “never started”: connection refused. The tell is that it worked a minute ago, or fails only when you load a large model. The most common trigger is a GPU driver eject (NVIDIA Xid errors, an out-of-memory event, or a driver that crashed and dropped the CUDA context), which can take the whole Ollama process down with it.

Read the logs to confirm:

• Linux (systemd): journalctl -u ollama -n 100 --no-pager
• Foreground: the output in your ollama serve terminal
• macOS: cat ~/.ollama/logs/server.log
• Windows: %LOCALAPPDATA%\Ollama\server.log

Look for CUDA error, out of memory, Xid, cudaMalloc failed, or an abrupt exit right after a model-load line. If you find a VRAM error, you asked for a model too big for your card — drop to a smaller quantization (e.g. a Q4_K_M build) or a smaller parameter count. Our guides on Ollama not using the GPU and Ollama CUDA out of memory dig into exactly these failures. After a driver eject, restart the service (sudo systemctl restart ollama) — and if it recurs, that’s a driver/VRAM problem to fix at the source, not a networking one.

Per-OS quick reference

Platform	How Ollama runs	Check it’s up	Start / restart
Linux	systemd service	systemctl status ollama	sudo systemctl restart ollama
macOS	Menubar tray app	Llama icon in menu bar	Launch Ollama.app
Windows	System-tray app	Llama icon in tray	Launch from Start Menu
WSL2	ollama serve in distro, or reach Windows host IP	curl 127.0.0.1:11434 inside WSL	ollama serve
Docker	Container w/ -p 11434:11434 + OLLAMA_HOST=0.0.0.0	docker logs <container>	docker restart <container>

The universal one-liner that works everywhere: curl http://127.0.0.1:11434 should print Ollama is running.

Once it’s reachable: safely exposing it to your other devices

Plenty of people hit this error precisely because they’re trying to do the right thing — run one beefy machine as a home AI server and reach it from a laptop or phone. That’s a great setup, but Ollama has no built-in authentication. Binding to 0.0.0.0 puts an open, unauthenticated LLM endpoint on your network. Do it deliberately:

• Keep it on the LAN, never the open internet. Don’t port-forward 11434 on your router. An exposed Ollama is an open invitation to anyone who finds it.
• Scope the firewall to your subnet, as in Fix 4, rather than allowing the world.
• Reach across networks via a private overlay like Tailscale or WireGuard instead of public exposure — your devices get a private address space and Ollama only ever binds to that.
• Front it with a reverse proxy (Caddy, nginx) if you want HTTPS and a password — the proxy handles auth that Ollama lacks.

Once the endpoint answers, you can point any client at it — Open WebUI for a browser chat, or your own scripts with the Ollama Python API. And if all this connection-wrangling has you wanting an AI companion that just works on your own hardware — private by default, no port-forwarding, no cloud — Ember packages a local model and a polished chat into one install, so you skip straight to talking instead of debugging TCP.