← All troubleshooting guides

Ollama "connection refused" — API not reachable, ports & fixes

作者： Jakub Rusinowski · 最后更新： 2026年7月10日

Founder, LLM Configurator — AI educator & workshop leader on local LLM deployment

The error

curl: (7) Failed to connect to localhost port 11434: Connection refused

When you see it

Your app, script, or UI can't reach the Ollama API (or LM Studio's server on port 1234). curl fails with "connection refused", Open WebUI shows no models, VS Code extensions report the server is unreachable, or a phone/laptop on your network can't connect while the host machine itself can. The model runs fine when you chat in the terminal — only the API connection is broken.

What's actually going on

"Connection refused" means nothing is listening at the address you dialed — this is a networking problem, never a model problem. There are only four real causes: the server process isn't actually running; it's running but bound to 127.0.0.1 (localhost-only) while you're connecting from another machine, container, or VM; something else occupies the port so the server never started cleanly; or a firewall/Docker/WSL2 network boundary sits between client and server. The fixes below check them in that order — fastest first.

How to fix it

1. Confirm something is actually listening on the port Most common fix

Don't guess — look. If nothing is listening on 11434, start the server and watch the output for errors (a fresh install that was never started, a crashed service after an update, and a closed system-tray app are the boring, common realities). If this shows a listener, skip to the bind-address fix.

# macOS / Linux
lsof -i :11434        # or: ss -ltnp | grep 11434

# Windows (PowerShell)
Get-NetTCPConnection -LocalPort 11434 -State Listen

# Nothing listening? Start it and read the output:
ollama serve
# Linux service install:
sudo systemctl status ollama

2. Connecting from another device? Bind to 0.0.0.0 instead of localhost

By default Ollama listens on 127.0.0.1 — reachable only from the same machine. Any connection from your phone, another PC, or a VM gets refused by design. Set OLLAMA_HOST=0.0.0.0:11434 and restart, then connect using the host's real IP (e.g. http://192.168.1.50:11434), never "localhost" from the remote device. LM Studio has the same switch: enable "Serve on Local Network" in the server tab. And never expose these ports to the internet — the APIs have no authentication; for remote access use a VPN/tailnet setup instead.

# Linux (systemd)
sudo systemctl edit ollama
#   [Service]
#   Environment="OLLAMA_HOST=0.0.0.0:11434"
sudo systemctl restart ollama

# macOS
launchctl setenv OLLAMA_HOST "0.0.0.0:11434"
# then quit & reopen the Ollama app

# Windows: set OLLAMA_HOST=0.0.0.0:11434 in Environment Variables, restart Ollama

3. Docker containers: "localhost" is the container, not your machine

The #1 Open WebUI issue: inside a container, localhost:11434 points at the container itself — where Ollama is not running. Use host.docker.internal (Docker Desktop on Mac/Windows) or the host-gateway mapping on Linux. If Ollama itself runs in a container, publish the port with -p 11434:11434.

docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  ghcr.io/open-webui/open-webui:main

4. WSL2: Windows and Linux are two different "localhost"es — sometimes

Recent WSL2 forwards localhost automatically (Windows apps can reach a server started inside WSL at localhost:11434, and WSL can reach a Windows Ollama the same way) — but the forwarding breaks after hibernation, under VPNs, and with networkingMode changes. If localhost fails across the boundary, dial the other side's real address: from WSL, the Windows host is reachable at the gateway IP; from Windows, WSL is at the address wsl hostname -I prints. wsl --shutdown and restarting also resets broken forwarding.

# From inside WSL2, find and use the Windows host:
ip route show | grep default   # e.g. 172.29.0.1
curl http://172.29.0.1:11434/api/tags

# Forwarding glitched? Reset WSL entirely:
wsl --shutdown

5. Port already in use: find the squatter or move Ollama

If ollama serve dies with "address already in use", another process owns the port — very often a *second* copy of Ollama (the desktop app running in the tray while you launch ollama serve in a terminal). Quit the tray app, or kill the PID holding the port. You can also relocate Ollama to another port entirely — just update every client to match.

# Who owns the port?
lsof -i :11434            # then: kill <PID>

# Or run Ollama elsewhere:
OLLAMA_HOST=127.0.0.1:11500 ollama serve
curl http://localhost:11500/api/tags

6. Still refused from other machines? It's the firewall

After binding to 0.0.0.0, an OS firewall can still drop outside connections: allow TCP 11434 through ufw/firewalld on Linux, approve the "allow incoming connections" prompt on macOS, and on Windows add an inbound rule (fastest test: temporarily toggle the firewall off — if connections work, it was the rule). Verify from the remote device with curl http://<host-ip>:11434/api/tags — a JSON model list means everything works end to end.

# Linux (ufw) — allow only your LAN:
sudo ufw allow from 192.168.1.0/24 to any port 11434 proto tcp

# Windows (admin PowerShell):
New-NetFirewallRule -DisplayName "Ollama" -Direction Inbound -LocalPort 11434 -Protocol TCP -Action Allow

Frequently asked questions

What port does Ollama run on by default?

TCP 11434, bound to 127.0.0.1 (localhost-only). LM Studio's server defaults to port 1234. Both can be verified with a browser: http://localhost:11434 returns "Ollama is running", and /api/tags returns your model list as JSON.

Why can I chat in the terminal but the API gives connection refused?

You probably can't — ollama run starts a temporary server if none is running, then it exits with the chat. A separate long-lived server (the desktop app, ollama serve, or the systemd service) must be running for API clients to connect at any other time.

Is it safe to set OLLAMA_HOST=0.0.0.0?

On a home LAN behind NAT, generally yes — it exposes the API to devices on your network only. It is NOT safe to port-forward it to the internet: the API has no authentication, so anyone could use your GPU, delete models, or fill your disk. For access from outside your home, use a mesh VPN like Tailscale instead of an open port.

Open WebUI shows "Ollama not detected" even though Ollama works — why?

Because Open WebUI runs in Docker, and its "localhost" is the container. Point OLLAMA_BASE_URL at http://host.docker.internal:11434 (with the host-gateway add-host flag on Linux) and it will find the API immediately.

curl works on the server but the connection times out (not refused) remotely — different problem?

Yes, and a useful clue: "refused" means reachable-but-nobody-listening, while a *timeout* means packets never arrived — that's a firewall or routing issue. Check the OS firewall rule for the port and that both devices are truly on the same network (guest Wi-Fi isolation is a classic culprit).