Ollama: “address already in use” on Port 11434

Almost everyone who hits this typed ollama serve on a machine where Ollama was already serving. The error is correct, the port is genuinely taken, and the fix is usually to stop trying to start a second one.

The string

Error: listen tcp 127.0.0.1:11434: bind: address already in use

On Windows the same condition produces the operating system’s own wording instead:

Error: listen tcp 127.0.0.1:11434: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.

Both are a bind() failure. Ollama’s HTTP server asked the kernel for TCP port 11434 on the loopback address and the kernel refused because something already holds it. Nothing has been attempted with a model; this happens before any of that.

The usual cause: it is already running

Ollama installs itself as a background service on every platform it supports, and the service starts on boot. Meanwhile every tutorial opens with ollama serve, which starts a server in the foreground. On a normal install those are two servers competing for one port, and the second one loses.

The important consequence is that you probably do not need to run it at all. Test before you kill anything:

curl http://localhost:11434/api/tags

A JSON list of your installed models means the server is up and healthy and the error was purely about starting a redundant second copy. Connection refused means something else holds the port, and the next section applies.

The specific shapes this takes per platform: on macOS the menu-bar app launches the server, so quitting the app is what stops it. On Linux there is a systemd unit named ollama. On Windows there is a tray application that starts at login. In a container, the image’s entrypoint is usually ollama serve already, so adding your own is what collides.

There is a design detail worth knowing, because it explains why this collides at all rather than being handled gracefully. Ollama is one binary that is both the client and the server: ollama run, ollama pull and ollama list are HTTP clients that talk to the server over this port, and ollama serve is the server itself. The client does not start a server on demand and the server does not detect a sibling and defer to it. Two serve invocations are simply two programs asking for the same socket, and the kernel arbitrates by refusing the second.

Finding what holds the port

Do not skip this step even when you are confident, because the answer is occasionally not Ollama, and killing the wrong process is a worse afternoon than the one you are having.

# macOS and Linux
lsof -i :11434
# or, without lsof
ss -tulpn | grep 11434

# Windows PowerShell
Get-NetTCPConnection -LocalPort 11434 | Select-Object OwningProcess
Get-Process -Id <pid>

Read the process name. If it is ollama, you are in the ordinary case. If it is something else, you have a port conflict rather than a duplicate service, and the right answer is to move Ollama rather than to evict the other program.

Two things that make this check come back empty even though the port is plainly taken. First, on Linux lsof and ss only show you the owning process for sockets you have permission to inspect, so a server running as the ollama system user is invisible to an unprivileged shell — run the check with sudo before concluding nothing holds it. Second, the address matters as well as the port: a process bound to 0.0.0.0:11434 occupies the port on every interface including loopback, so a filter written for 127.0.0.1 specifically can miss it.

Releasing it, or moving off it

1. Stop the managed service rather than killing the process. A supervised service that you kill gets restarted by its supervisor, and you will conclude the port is haunted.

   # Linux
   sudo systemctl stop ollama
   
   # macOS: quit the Ollama menu-bar app
   # Windows: exit Ollama from the system tray

2. Confirm the port is free by re-running the lsof or Get-NetTCPConnection check. A socket in TIME_WAIT from a process that just exited can hold it for a short interval; waiting is the correct response.
3. Or move Ollama to another port instead. OLLAMA_HOST sets the bind address and port for the server, and it also tells the client where to look, so it must be set for both:

   OLLAMA_HOST=127.0.0.1:11500 ollama serve
   
   # in another shell, the client needs to agree
   OLLAMA_HOST=127.0.0.1:11500 ollama list

   Forgetting the second half is why people report that the server started on a new port and the CLI cannot see it. Note also that OLLAMA_HOST is doing double duty as a bind address and as a client target, which means a value that is meaningful to one is not always meaningful to the other: 0.0.0.0 is a valid thing to bind to and not a valid thing to connect to. That mismatch is one of the causes behind the CLI working while the API does not.
4. Make it permanent, in the right place. Exporting a variable in your shell does not reach a systemd service; that needs a unit override with an Environment= line and a daemon reload.

Two variants that are not this

A permissions refusal. On Windows some users see bind: An attempt was made to access a socket in a way forbidden by its access permissions. That is not a port collision. It usually means the port falls inside a reserved range the operating system has set aside, often for Hyper-V or WSL, and the fix is to choose a port outside that range rather than to hunt for a process — there is not one to find.

A container publishing the wrong thing. Inside Docker, the bind happens in the container’s own network namespace, so a host process on 11434 does not conflict with it. If you see this error from a container, something inside the container is already listening — most likely the image’s entrypoint, with your command adding a second. Conversely, a container that binds only to loopback will not be reachable from the host even when published, so set OLLAMA_HOST=0.0.0.0:11434 inside it.

If the server starts fine and the failure comes later, when a model is actually loaded, you are looking at the runner process terminating instead. General setup is covered in the Ollama guide.