Fix Ollama port already in use (11434)

You run ollama serve (or start the Ollama app) and immediately hit one of these:

• macOS / Linux: Error: listen tcp 127.0.0.1:11434: bind: address already in use
• Windows: Error: listen tcp 127.0.0.1:11434: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.

The server never comes up, and ollama run <model> fails with a connection error. Ollama binds 127.0.0.1:11434 by default (confirmed in the official FAQ as of June 2026), and the message means something already owns that port.

Fastest fix: in almost every case the something is another Ollama you forgot about — the desktop app or a background/service instance. You usually do not need ollama serve at all: just run ollama run <model> and let the existing instance answer. If you do need to restart, find the owner with lsof -i :11434 (macOS/Linux) or netstat -ano | findstr :11434 (Windows), stop it, then start one instance.

Which bucket are you in?

Run the one-liner for your OS first, then match the output to the table.

# macOS / Linux
lsof -i :11434 -P -n

# Windows (PowerShell) — note the PID in the last column
netstat -ano | findstr :11434

What you see	Most likely cause	Fix below
Owner is ollama / ollama.exe, and you started the app or service	Desktop app or service is already serving	Step 2A — don’t run ollama serve, just use ollama run
Owner is ollama, no app/service started, terminal was force-quit last time	Stale ollama serve process	Step 2B — kill it
systemctl is-active ollama returns active (Linux)	systemd unit owns the port	Step 2C — manage via systemctl, not a manual serve
Owner is NOT ollama (some other binary)	Real port conflict	Step 3 — move Ollama to another port
lsof shows nothing, but binding still fails for ~30-60s	Socket in TIME-WAIT after a crash/kill -9	Step 4 — wait it out
Two ollama binaries exist (app + Homebrew, or Windows Startup app)	Duplicate installs both auto-start	Step 5 — keep one

Step 1: Identify what owns port 11434

# macOS / Linux
lsof -i :11434 -P -n

# Linux alternative (shows the PID and process name)
ss -tlnp | grep :11434

# Windows (PowerShell): get the PID, then resolve it to a name
netstat -ano | findstr :11434
Get-Process -Id <PID>

If the COMMAND / process name is ollama (or ollama.exe), it is an Ollama instance — go to Step 2. If it is anything else, go to Step 3.

Step 2A: It’s the Ollama app or service — don’t double-serve

This is the single most common case. The macOS/Windows desktop app and the Linux systemd unit each run their own server in the background. Starting a second one with ollama serve is what triggers the error.

You do not need ollama serve when the app/service is running. Just use the client directly:

ollama run llama3.2
ollama pull qwen3

To confirm the existing server is healthy:

curl -s http://localhost:11434/api/version

Step 2B: It’s a stale ollama serve — kill it

A previous ollama serve is still bound because the terminal was force-quit instead of stopped with Ctrl+C (which sends SIGINT and lets it release the socket).

# macOS / Linux — graceful first
kill -15 "$(lsof -ti :11434)"
sleep 2
lsof -i :11434          # expect no output

# If it survives, force it
pkill -9 -f ollama

# Windows (PowerShell): kill by the PID from Step 1
taskkill /F /PID <PID>

On macOS specifically: quitting the desktop app from the menu bar (Ollama icon -> Quit Ollama) is the supported stop, but a known quirk leaves the server process running with no Dock item. If lsof -i :11434 still shows ollama after quitting, fall back to pkill -9 -f ollama or stop it from Activity Monitor (search “ollama”, select it, click the stop button). Then restart cleanly:

ollama serve

Step 2C: Linux — manage it through systemd, not a manual serve

The Linux install script registers ollama.service and starts it at boot. If it is active, a manual ollama serve will always lose the race for the port.

systemctl is-active ollama        # "active" means the service owns 11434

# Restart or stop via the unit — not by killing the PID
sudo systemctl restart ollama
sudo systemctl stop ollama

# Only when you need a foreground/debug run, stop the service first
sudo systemctl stop ollama
OLLAMA_DEBUG=1 ollama serve

If you prefer to always run manually, disable the service so it stops claiming the port at boot:

sudo systemctl disable --now ollama

Step 3: A different program owns 11434 — move Ollama

If Step 1 shows a non-ollama owner (a dev tool, a Docker port-mapping, a stray script), the cleanest fix is to give Ollama its own port via OLLAMA_HOST.

For a quick one-off:

OLLAMA_HOST=127.0.0.1:11435 ollama serve

To make it stick, set the variable the way Ollama actually reads it on each platform (per the official FAQ, June 2026):

# Linux (systemd): edit the unit, add the env line, reload
sudo systemctl edit ollama.service
#   [Service]
#   Environment="OLLAMA_HOST=127.0.0.1:11435"
sudo systemctl daemon-reload
sudo systemctl restart ollama

# macOS (desktop app): set it for the launch environment, then restart the app
launchctl setenv OLLAMA_HOST "127.0.0.1:11435"

On Windows: quit Ollama from the system tray, open Edit environment variables for your account, add a user variable OLLAMA_HOST with value 127.0.0.1:11435, then relaunch Ollama from the Start menu.

Then point every client at the new port:

# CLI in this shell
export OLLAMA_HOST=127.0.0.1:11435
ollama run llama3.2

# Open WebUI:  OLLAMA_BASE_URL=http://localhost:11435
# LangChain:   OllamaLLM(base_url="http://localhost:11435")
curl http://localhost:11435/api/version

Step 4: Socket stuck in TIME-WAIT after a crash

If you hard-killed Ollama (OOM killer, kill -9, power loss) and lsof -i :11434 now shows nothing yet binding still fails for half a minute, the kernel is holding the socket in TIME-WAIT while in-flight packets drain.

# Confirm the state
ss -tan | grep 11434        # look for TIME-WAIT (not LISTEN)

The fix is to wait: the socket releases on its own, typically within 60 seconds. Re-running ollama serve after that succeeds. There is no need to tune kernel sysctls for a normal single-instance setup — just retry once the state clears.

Step 5: Two Ollama installs both auto-start — keep one

If lsof keeps showing ollama even right after a reboot, you likely have two installs that both launch themselves.

• macOS: the desktop app and brew install ollama are two separate binaries. Pick one. Run which ollama and check /Applications for Ollama.app. To keep the app, brew uninstall ollama; to keep Homebrew, move Ollama.app to the Trash.
• Windows: the installer adds an entry to Task Manager -> Startup apps that silently launches ollama.exe and holds 11434 even when no tray icon is visible. Disable that Startup entry if you want to control startup yourself, or stop fighting it and just use ollama run.

How to confirm it’s fixed

# 1) Exactly one owner on the port
lsof -i :11434          # (or: netstat -ano | findstr :11434 on Windows)

# 2) The API answers
curl -s http://localhost:11434/api/version

# 3) A model actually responds
ollama run llama3.2 "say hi in one word"

If all three pass, the port conflict is resolved.

Prevention

• Don’t run ollama serve by hand when the desktop app or systemd service is already running — use ollama run / ollama pull and let the existing server answer.
• On Linux, manage Ollama through systemctl (start/stop/restart) instead of mixing in manual serve runs.
• On macOS, pick the app or the Homebrew/manual install, not both. On Windows, decide whether the Startup app or your terminal owns the process — not both.
• Gate your start scripts on the port being free: lsof -i :11434 -t >/dev/null || ollama serve.
• After a crash, wait ~60s before restarting so any TIME-WAIT socket can clear.
• Pin OLLAMA_HOST in your project’s .env.example so teammates know the port and can spot conflicts early.

FAQ

Q: Can I run two Ollama instances on one machine? A: Yes — give the second one a different port, e.g. OLLAMA_HOST=127.0.0.1:11435 ollama serve. Each instance has its own loaded-model pool, so they can serve different models at once. Set a different OLLAMA_MODELS path for each if you also want separate model storage.

Q: I killed the process but still get “address already in use” for ~30 seconds. Why? A: The TCP socket is in TIME-WAIT after a forced close. Confirm with ss -tan state time-wait | grep 11434. It releases automatically; wait 30-60 seconds and retry. Don’t kill -9 repeatedly — that only resets the timer.

Q: ollama serve started fine, but ollama run still says “connection refused.” Why? A: The CLI talks to whatever OLLAMA_HOST points at (default http://localhost:11434). If you started the server on a custom port (say 11435), export OLLAMA_HOST=127.0.0.1:11435 in the same shell before running ollama run, or the client will keep dialing 11434.

Q: How do I expose Ollama on my LAN without binding 0.0.0.0? A: Set OLLAMA_HOST=<your-LAN-IP>:11434 (for example 192.168.1.50:11434). That binds only that interface, which avoids the all-interfaces behavior of 0.0.0.0 that can collide with Docker port mappings. Add a firewall rule before exposing it.

Q: On Windows there’s no tray icon, but the port is still taken. What’s holding it? A: The installer’s Startup apps entry launches ollama.exe in the background with no visible tray icon. Find it with netstat -ano | findstr :11434, kill it with taskkill /F /PID <PID>, and disable the Startup entry in Task Manager if you don’t want it auto-launching.

Related

• Ollama Model Download Stalls at Some Percentage
• Ollama Doesn’t Detect the GPU, Falls Back to CPU
• Ollama Pull Succeeds but the Model Isn’t Listed
• Ollama Modelfile SYSTEM Prompt Is Ignored
• claude-mcp-server-disconnect

Tags: #local-llm #ollama #Troubleshooting

Related Articles

Troubleshooting

llama.cpp mmap Fails on a Network Drive

llama.cpp crashes or stalls loading a GGUF model from an NFS or SMB share. Fastest fix: add --no-mmap (and --no-direct-io if DirectIO is on), or copy the model to local disk.

May 25, 2026 #local-llm #llama.cpp

Troubleshooting

llama.cpp Quality Drops After Switching to a More Aggressive Quant

Responses degrade after moving from Q5_K_M or Q8_0 to Q4_0, IQ4_XS, or lower in llama.cpp. Pick the right quant tier, fix bad re-quants, and confirm with perplexity.

May 25, 2026 #local-llm #llama.cpp

Troubleshooting

LM Studio Out of Memory When Loading a Model

LM Studio crashes or shows out of memory loading a GGUF. Fix it fast by cutting context length, enabling Flash Attention, and tuning GPU offload — with a VRAM sizing table.

May 25, 2026 #local-llm #lmstudio

Troubleshooting

Local Embedding Server Crashes Under Batched Requests

Ollama, llama-server, vLLM, or sentence-transformers crashes or OOMs on batched embeddings. Fix batch size, num_batch, sequence length, and concurrency — with the exact flags.

May 25, 2026 #local-llm #ollama

Troubleshooting

Chat-Template Mismatch Produces Garbage Local LLM Output

A local LLM echoes your prompt, prints literal [INST] or <|im_start|> tags, or loops the same sentence. That is a chat-template mismatch. Find the model's real template and force the engine to use it.

May 25, 2026 #local-llm #llama.cpp

Troubleshooting

Multi-GPU Not Used — Local LLM Runs Only on GPU 0

Your local LLM uses one GPU while the others sit at 0%. Fix it with llama.cpp --split-mode, vLLM --tensor-parallel-size, Ollama auto-spread, and the NCCL flags PCIe rigs need.

May 25, 2026 #local-llm #ollama