Ollama Port 11434 Already in Use on Windows: Why ollama serve Fails and How to Fix It

When ollama serve fails on Windows with “bind: Only one usage of each socket address (protocol/network address/port) is normally permitted”, port 11434 is almost always held by Ollama itself: the desktop app starts a server in the background when you sign in. Quit Ollama from the notification area, or simply skip ollama serve and use the server that is already running. If you are not sure what owns the port, Port Detective shows the process name, PID and path behind 11434 in one lookup, so you can tell Ollama from something else before you end anything.

This guide covers the exact error, how to confirm the owner, and the three clean fixes.

Type 11434 and see the process, PID and path that hold the port.

Get it from Microsoft

What does the error look like?

The full message reads:

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

The first half comes from Ollama: it tried to listen on 127.0.0.1, port 11434. The second half is the standard Windows text for socket error 10048, which means another socket already holds that address and port. Our explainer on the 10048 “only one usage of each socket address” error covers the Windows side in general. This page is about the Ollama case, which has a specific and usually harmless cause.

Why is port 11434 already in use?

Ollama’s documentation answers this directly. The Ollama FAQ says Ollama binds 127.0.0.1 port 11434 by default, and that Ollama for Windows registers as a login item during installation. The Windows guide adds that after installing, Ollama runs in the background and the API is served on http://localhost:11434.

So the sequence is usually:

1. You sign in to Windows and Ollama starts in the background, holding 11434.
2. You open a terminal and run ollama serve, because a tutorial says to.
3. The second server tries to bind the same address and port, and Windows refuses.

This exact report appears in Ollama’s own issue tracker, in issue 3575, where users found that quitting the Ollama icon in the notification area freed the port. A later report, issue 10713, describes the startup instance holding 11434, and an Ollama collaborator explains there that the desktop app does not register a system-wide service, by design, so it can run without admin rights. It launches as a user startup item instead. That is why you will not find an “Ollama” entry in services.msc.

How do I confirm what owns port 11434?

Do not assume. Another local AI tool, a container or a proxy can also be listening there. Check first:

Get-NetTCPConnection -LocalPort 11434 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess,
    @{n='Process';e={(Get-Process -Id $_.OwningProcess).ProcessName}}

Or the classic pair:

netstat -ano | findstr :11434
tasklist /fi "PID eq 1234"

Replace 1234 with the PID from the last column of the netstat line.

What you see	What it means	Next step
ollama or ollama app owns 11434	The background Ollama server is running	Use it, or quit it before ollama serve
A different program owns 11434	Something else took Ollama’s default port	Move Ollama with OLLAMA_HOST, or stop the other program
com.docker.backend or wslrelay	A container or WSL publishes 11434	Check docker ps for a published 11434
Nothing listening, error persists	A stale process or a reserved range	Re-check after a restart; see the 10048 guide

Port Detective does the same lookup in one step: type 11434 and it shows the process name, PID, executable path and connection state. The path matters here, because it tells you whether the owner is the copy of Ollama under %LOCALAPPDATA%\Programs\Ollama, which is where the Windows guide says the binaries live, or something else entirely.

Fix 1: Do not run ollama serve at all

If the owner is Ollama, the simplest fix is to stop fighting it. The server you wanted is already up. Run your commands against it:

ollama list
ollama run llama3.2

Any app or script that calls http://localhost:11434 will reach the background server too. Ollama collaborators make the same point in issue 8261 and issue 10063: if a server is already running, there is no need to run ollama serve, and ollama --version is a quick way to check whether one is.

Fix 2: Quit the app, then run ollama serve

You may want the server in a terminal so you can watch its output, or start it with different settings. Then:

1. Click the up arrow in the notification area, right-click the Ollama icon and choose Quit.
2. Check the port is free with the command above, or in Port Detective.
3. Run ollama serve in your terminal.

If you want this every time, stop the app from starting at sign-in. The Ollama FAQ gives the steps: in Task Manager, open the Startup apps tab, find Ollama and choose Disable. Ollama says it respects that setting across upgrades unless you uninstall.

If the port is still held after you quit, look for both ollama.exe and ollama app.exe in Task Manager. Users in issue 3575 describe the app process restarting the server if only the server process is ended, so quit from the icon rather than ending one process at a time.

End the right process by port, checked against its process token first.

Get it from Microsoft

Fix 3: Move Ollama to another port

If something else needs 11434, or you want two servers side by side, change the bind address. Ollama reads the OLLAMA_HOST environment variable. The FAQ’s Windows steps are:

1. Quit Ollama from the notification area.
2. Open Settings on Windows 11 or Control Panel on Windows 10 and search for “environment variables”.
3. Choose “Edit environment variables for your account”.
4. Create or edit OLLAMA_HOST, for example 127.0.0.1:11500.
5. Select OK, then start Ollama from the Start menu.

Every client then needs the new address. The Ollama CLI reads the same variable, so set it in the terminal where you run commands too. Other apps, such as a chat front end, need their Ollama URL changed to http://localhost:11500.

Be careful with 0.0.0.0. The FAQ uses 0.0.0.0:11434 as an example of exposing Ollama on your network. Do that only when you mean to, and only on a network you trust, because it lets other machines reach the API.

What if I need Ollama as a real Windows service?

The Windows guide describes a standalone CLI zip for this case and mentions running it as a system service with NSSM. If you go that way, uninstall or disable the desktop app’s startup entry first. Otherwise you will have two servers competing for 11434 at every sign-in, which is the same error again in a new form.

The guide also lists where to look when something still fails: logs live in %LOCALAPPDATA%\Ollama, where server.log holds the most recent server logs and app.log holds the app’s. The guide also states Ollama for Windows needs Windows 10 22H2 or newer.

How do I keep 11434 from being taken again?

If you rely on Ollama all day, a second program grabbing 11434 is the failure you notice last, usually when a script times out. Port Detective Pro’s Port Guard watches pinned ports from the system tray, checking every 250 milliseconds, and sends a Windows notification when something that should not be there takes one. With a rule set, it can shut down the intruder, relaunch the process that should own the port and confirm it rebound. Leave yourself a note on the port, such as “11434 = Ollama”, and it is searchable later.

When you want to script the fix instead, Port Detective can copy any row as a ready-to-run netstat, taskkill or PowerShell command.

Frequently asked questions

Is it safe to end the process on 11434?

If the path shows it is Ollama, yes, though quitting from the notification area icon is cleaner. If it is another program, find out what it is first. Port Detective tells you plainly when a process is a protected OS process.

Why does the error say 127.0.0.1 and not localhost?

Ollama binds 127.0.0.1 by default, per its FAQ. localhost resolves to that loopback address, so clients reach the same server.

Does changing OLLAMA_HOST move my models?

No. Models are controlled by a separate variable, OLLAMA_MODELS, which the FAQ lists alongside OLLAMA_HOST.

Can a Docker container cause this?

Yes, if a container publishes 11434 on the host. Port Detective Pro maps host ports back to the container and image that published them when Docker is running.

Try Port Detective

Port Detective Free is in the Microsoft Store for live TCP and UDP tracking and instant port lookup. Port Detective Pro, a one-time purchase with a free trial in the Microsoft Store, adds Port Guard, one-click termination, remote scanning and Docker mapping. Our guide to finding the process using a port covers other ports, and the Port Detective product page has the full feature list.

See who holds 11434, then keep the port for Ollama.

Get it from Microsoft

Ollama is a trademark of its owner. Automata Labs is not affiliated with Ollama.

Last updated 23 October 2026. Published by Automata Labs, a software company in Canada.