Ollama Connection Refused on Port 11434: 8 Causes

"Connection refused" on port 11434 is not a crash. It means something at that address answered your TCP handshake with a rejection — nothing was listening there. The cause worth checking before any other is not that Ollama is down: it is that Ollama is running fine and bound to 127.0.0.1, which the official FAQ states is the default ("Ollama binds 127.0.0.1 port 11434 by default"). Loopback is unreachable from a Docker container, a WSL2 distro, or any other machine, so those clients are refused by design. The fix is to set OLLAMA_HOST to 0.0.0.0:11434 using the method your OS requires and restart. Before changing anything, run curl http://127.0.0.1:11434 on the machine Ollama is installed on: if it prints Ollama is running, the daemon is healthy and your problem is reachability, not the service.

That two-second test is the fork in the road, and almost nobody runs it first. Everything below is organised around which side of it you land on.

This page covers the client cannot reach the server direction. If your error is the opposite — the server itself refusing to start with a bind message such as address already in use — that is a different problem with a different fix, and it lives in our Ollama troubleshooting guide. The two get confused constantly because both mention port 11434, so it is worth knowing which one you have before you start editing config.

Command lines and default values below are quoted from the official Ollama FAQ and read from the Ollama source on main; GitHub issues are linked so you can check the state of anything still open.

What Does "Connection Refused" on 11434 Actually Mean?

Refused is a specific, informative failure and it is worth separating from its neighbours before you start changing settings:

The instant-versus-slow distinction alone tells you a lot. A refusal comes back immediately because the kernel sends a TCP RST; a firewall drop makes you wait for a timeout. If your client hangs for ten seconds and then fails, stop reading the bind-address sections and go to the firewall one.

That last row matters for browser extensions and web apps: the FAQ notes Ollama "allows cross-origin requests from 127.0.0.1 and 0.0.0.0 by default" and that "additional origins can be configured with OLLAMA_ORIGINS". A 403 is a successful connection, so it is not this page's problem.

Which Error String Did You Get, and What Emitted It?

Four different strings all mean "refused", and they come from four different layers. Knowing which layer spoke tells you where to start.

The two CLI strings are worth reading carefully, because the wording changed and the internet did not keep up. In v0.5.7 the heartbeat check ran startApp() and, if that failed, returned errors.New("could not connect to ollama app, is it running?"). Current main no longer has that string at all — the Linux path returns could not connect to ollama server, run 'ollama serve' to start it. If you are looking at the "is it running?" wording, you are on an Ollama older than v0.9.0, and half the advice you will find for it was written against a different codebase. Upgrading is a legitimate first move.

Issue #3200 is a good reminder that not every refusal is a config bug: the reporter was running llama_index inside Google Colab, pointed at localhost:11434, on a machine where Ollama had never been installed. Nothing was listening because nothing was there.

Step 0: Is Anything Listening on 11434?

Run this on the machine Ollama is installed on, not on the client. This is the test that decides which half of the page applies to you.

curl http://127.0.0.1:11434

Ollama is running means the daemon is healthy. That string is not folklore — it is the response body of the root route registered in Ollama's server:

r.GET("/", func(c *gin.Context) { c.String(http.StatusOK, "Ollama is running") })

If that works locally but your app still cannot reach it, skip to cause 2 onward — the service is fine and you have a reachability problem. If it is refused even locally, the server genuinely is not up, and cause 1 is yours.

Then confirm what is holding the port, per platform:

The log paths and the docker logs step come from Ollama's official troubleshooting doc; the Windows netstat -bano invocation is the one a triager asks reporters for in issue #8396.

Pay attention to the address in the ss output, not just the fact that a listener exists. 127.0.0.1:11434 and 0.0.0.0:11434 look almost identical at a glance and mean completely different things — that one difference is the whole of cause 2.

The Cause Table

Work down it. Each row's "tell" is a thing you can observe rather than a thing you have to believe.

Causes 2, 3 and 4 are all "OLLAMA_HOST is not what you think it is," which is why they sit next to each other. If you have never touched that variable, start at 1 and 5.

Cause 1: The Server Is Genuinely Not Running

Rule this out first, because every other fix on this page assumes a live daemon. The check is the curl http://127.0.0.1:11434 above, run locally.

How you start it depends on how you installed it:

• Linux, installed via the official script: it is a systemd unit. sudo systemctl start ollama and sudo systemctl enable ollama to survive reboots. Check journalctl -u ollama --no-pager --follow --pager-end (the command from the official troubleshooting doc) if it starts and dies.
• macOS or Windows desktop app: the menu-bar or tray app is the server. If the icon is gone, the server is gone. Quitting the app to "close the window" stops the daemon — that is the mechanism behind issue #11742, where closing the chat GUI mid-download killed an in-flight ollama pull and produced the connectex refusal quoted above.
• Any platform, manually: ollama serve in a terminal, which puts the logs where you can see them. This is the best debugging posture, because the reason the service is exiting will be on screen instead of buried in a log file.

A subtlety worth knowing on Windows and macOS: the CLI tries to start the app for you. Ollama's checkServerHeartbeat only calls startApp() when the error text contains refused or could not connect. So on those platforms a refusal is often silently self-healing, and an error that survives that means the launch attempt also failed — a much narrower problem than "Ollama is broken."

Fresh install and nothing is working at all? Start from our complete Ollama guide rather than debugging a half-finished setup, and on Windows specifically our Ollama Windows installation walkthrough covers the install-time gotchas.

Cause 2: Ollama Binds 127.0.0.1 by Default

This is the one to check the moment your client is anywhere other than the same machine. From the official FAQ, under "How can I expose Ollama on my network?":

Ollama binds 127.0.0.1 port 11434 by default. Change the bind address with the OLLAMA_HOST environment variable.

Loopback means loopback. A Docker container has its own loopback. A WSL2 distro has its own loopback. Another laptop on your Wi-Fi has its own loopback. All of them get refused, and all of them are behaving correctly.

Setting the variable is genuinely different on each OS, and this is where most guides go wrong by giving you the Linux answer only. All three of the following are quoted from the FAQ's "How do I configure Ollama server?" section.

macOS — the app does not inherit your shell's environment, so exporting it in .zshrc does nothing:

launchctl setenv OLLAMA_HOST "0.0.0.0:11434"

Then restart the Ollama application.

Linux with systemd — edit the unit, do not export it in a shell:

systemctl edit ollama.service

Add, under [Service]:

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

Then:

systemctl daemon-reload
systemctl restart ollama

Windows — the FAQ's sequence, in order, and the order matters: Quit Ollama from the taskbar first. Open Settings (Windows 11) or Control Panel (Windows 10), search for environment variables, click Edit environment variables for your account, create or edit OLLAMA_HOST, click OK, then start Ollama again from the Start menu. Editing the variable while the app is running changes nothing, because the running process already read its environment.

Confirm it took with ss -ltnp | grep 11434 on Linux, or the netstat command above on Windows. You are looking for the listen address to have changed from 127.0.0.1 to 0.0.0.0. If it has not, the variable did not reach the process — which on macOS and Windows is nearly always because the app was not fully restarted.

Understand what you just did. 0.0.0.0 binds every interface, and Ollama's API has no authentication of its own: anyone who can route to port 11434 can list your models, run inference, and delete models. On a laptop that joins café Wi-Fi that is a real exposure, not a theoretical one. Bind to a specific LAN address instead of 0.0.0.0 where you can, and read our guide to securing an Ollama server before you leave it that way. The FAQ ships an nginx reverse-proxy config, and a reverse proxy is where authentication belongs.

Cause 3: OLLAMA_HOST Is Two Settings Wearing One Name

OLLAMA_HOST tells the server where to bind and tells the CLI where to connect. Changing it for one purpose silently changes the other. This produces the most confusing report on the whole tracker: the server works perfectly over HTTP, and ollama pull on that very same machine fails.

Issue #4540 is the canonical write-up. The reporter set OLLAMA_HOST=192.168.1.10:11434 in the systemd unit, could reach it fine from Open WebUI, and got could not connect to ollama app, is it running? from the CLI on the server itself. Ollama maintainer dhiltgen's answer explains it exactly:

By setting OLLAMA_HOST on the server to a specific IP address, it should only listen on that address, and the client will not be able to access it over localhost (127.0.0.1) but must use the same IP address the server is listening to. Another possible server setup is 0.0.0.0:11434, which will tell the server to bind to all interfaces (including localhost)

So there are two working configurations, and one broken one:

• Server bound to 0.0.0.0:11434 — everything reaches it, including 127.0.0.1. This is why the FAQ recommends 0.0.0.0 rather than a specific IP.
• Server bound to a specific IP — then every client, including the CLI on that same box, must use that exact IP. Set OLLAMA_HOST for your shell to match.
• Server on one address, client assuming another — refused, forever, no matter how many times you restart it.

If you are debugging a remote client, keep the two roles straight in your head as "bind address" and "dial address". They only happen to share a variable name.

Cause 4: http://localhost Silently Means Port 80

A URL-shaped OLLAMA_HOST without an explicit port does not default to 11434. This one is invisible until you read the parser. From envconfig/config.go on main:

func Host() *url.URL {
	defaultPort := "11434"

	s := strings.TrimSpace(Var("OLLAMA_HOST"))
	scheme, hostport, ok := strings.Cut(s, "://")
	switch {
	case !ok:
		scheme, hostport = "http", s
		...
	case scheme == "http":
		defaultPort = "80"
	case scheme == "https":
		defaultPort = "443"
	}

Read the case arms. If you write a bare localhost or localhost:11434, there is no ://, so the default port stays 11434 and everything works. But the moment you write OLLAMA_HOST=http://localhost — which looks more correct, and which plenty of tutorials show — the default port becomes 80, your client dials localhost:80, and you get connection refused from a port Ollama was never on.

The fix is one of: drop the scheme (OLLAMA_HOST=localhost), or always write the port (OLLAMA_HOST=http://localhost:11434). The second is better because it is explicit and survives someone else reading your Compose file.

A related detail from the same file, in ConnectableHost(): unspecified bind addresses are rewritten to loopback for outgoing connections, with the comment "Unspecified addresses are valid for binding a server socket but not for connecting as a client, which fails on Windows." In other words OLLAMA_HOST=0.0.0.0:11434 is the right thing to set on a server and a meaningless thing to dial as a client. Ollama's own tooling papers over that; your Python script will not.

Cause 5: Your Container Is Dialling Its Own Loopback

Inside a container, localhost is the container. This is the single biggest source of "connection refused" for Open WebUI, n8n, LangChain services, Dify and every other tool people put in Docker in front of a host-installed Ollama. Nothing is misconfigured in Ollama; the request never left the container's network namespace.

There are two independent things to fix, and people usually do only one:

1. Give the container a hostname that resolves to the host. Docker's CLI reference documents the mechanism plainly: "The --add-host flag supports a special host-gateway value that resolves to the internal IP address of the host," and "It's conventional to use host.docker.internal as the hostname referring to host-gateway. Docker Desktop automatically resolves this hostname."
2. Make Ollama listen somewhere the container can reach. host.docker.internal resolves to the host's bridge-side address, which is not the host's loopback — so if Ollama is still on 127.0.0.1, step 1 alone gets you a refusal on a different IP. You still need cause 2's OLLAMA_HOST=0.0.0.0:11434.

On Docker Desktop (macOS, Windows) host.docker.internal resolves for you. On Docker Engine on Linux it does not exist unless you create it:

docker run -d \
  --add-host=host.docker.internal:host-gateway \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  -p 3000:8080 -v open-webui:/app/backend/data \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

The alternative, which Open WebUI's own connection-error documentation gives as its primary recommendation, is to skip container networking entirely on a Linux host:

docker run -d --network=host \
  -v open-webui:/app/backend/data \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

Note what changes with --network=host: the URL goes back to 127.0.0.1 because the container now is on the host's network stack, and Open WebUI's docs point out that the port you browse to changes from 3000 to 8080 because the port mapping no longer applies. That surprise — "I fixed the Ollama error and now the web UI itself is gone" — is a documented consequence, not a new bug. Host networking is a Linux-Docker-Engine feature; on Docker Desktop the host.docker.internal route is the dependable one.

A quick way to tell which layer is broken, from inside the container:

docker exec -it open-webui curl -s http://host.docker.internal:11434

Ollama is running means networking is solved and your app's configured URL is the problem. Refused means you are still on cause 2 or cause 1. Our Ollama and Open WebUI Docker setup guide has the full working compose file, and if you are wiring this into automation the n8n plus Ollama guide uses the same host-address pattern.

Running Ollama itself in a container instead? Then the host reaches it through the published port and the official invocation docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama is enough — but the container must still bind 0.0.0.0 internally for the port publish to have anything to forward, which the official image already does.

Cause 6: WSL2 Cannot See Windows' Loopback

By default WSL2 is a NAT'd VM, so localhost inside Ubuntu is not localhost on Windows. Microsoft's networking documentation is explicit that reaching a Windows-side server from Linux needs the host's IP, not loopback:

If you want to access a networking app running on Windows (for example an app running on a NodeJS or SQL server) from your Linux distribution (ie Ubuntu), then you need to use the IP address of your host machine.

The command Microsoft gives for finding it, run inside WSL:

ip route show | grep -i default | awk '{ print $3}'

That prints something like 172.30.96.1, and http://172.30.96.1:11434 is your base URL. This address changes across reboots, which is why hard-coding it into a .env file leads to a mysterious failure a week later.

The same page also warns that a request arriving from WSL is treated as a LAN connection, which is a second reason cause 2 applies here:

When using remote IP addresses to connect to your applications, they will be treated as connections from the Local Area Network (LAN). This means that you will need to make sure your application can accept LAN connections. For example, you may need to bind your application to 0.0.0.0 instead of 127.0.0.1.

The better fix on Windows 11 22H2 and higher is mirrored networking. Setting networkingMode=mirrored under [wsl2] in .wslconfig gives you, in Microsoft's words, the ability to "Connect to Windows servers from within Linux using the localhost address 127.0.0.1" — no gateway IP, no drift after reboot. The documented caveat is that IPv6 localhost (::1) is not supported, so pin your client to the IPv4 form.

Mirrored mode brings the Hyper-V firewall into play, and Microsoft's own note is that you may need to allow inbound connections explicitly, in an elevated PowerShell:

Set-NetFirewallHyperVVMSetting -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -DefaultInboundAction Allow

Or, scoped to a single port rather than everything:

New-NetFirewallHyperVRule -Name "Ollama" -DisplayName "Ollama" -Direction Inbound -VMCreatorId '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -Protocol TCP -LocalPorts 11434

The reverse direction — Ollama running inside WSL, client on Windows — is the easy case: Microsoft's docs say you can reach Linux apps from Windows "using localhost (just like you normally would)." That asymmetry is exactly what issue #5041, "Easy troubleshooting for Windows internal networks - known as 'Connection refused' issue", was opened to document, and its summary is still the shortest correct one on the tracker: use host.docker.internal for Docker, the vEthernet (WSL) address for WSL-to-Windows, and 127.0.0.1 for Windows-to-WSL.

Cause 7: A Firewall Is Dropping It

Firewalls usually produce a hang, not an instant refusal — so if your failure is immediate, this probably is not your cause. Check the timing before you start opening ports.

Where it does bite:

• Another machine on your LAN, after you correctly set 0.0.0.0. The host OS firewall still has to allow inbound 11434.
• WSL2 in mirrored mode, per the Hyper-V firewall commands above.
• Cloud VMs, where the provider's security group is a second firewall in front of the OS one, and the OS-level rule you just added does nothing.

Only open the port after you have read cause 2's warning about what an unauthenticated Ollama on 0.0.0.0 exposes. A reverse proxy with authentication in front of 11434 is the better answer for anything beyond your own desk — the FAQ ships an nginx config for exactly this, and our Ollama production deployment guide covers the full pattern.

Cause 8: Refused Because the Server Never Bound

If ollama serve itself fails with a bind: error, every client refusal downstream is a symptom, not the disease. Two distinct messages show up here and they are not the same problem:

• listen tcp 127.0.0.1:11434: bind: address already in use — something already holds the port, usually a second Ollama instance you forgot about. Covered in our Ollama troubleshooting guide.
• listen tcp 127.0.0.1:11434: bind: An attempt was made to access a socket in a way forbidden by its access permissions. — a Windows-specific one, reported verbatim in issue #8396 alongside could not connect to ollama app, is it running?. In that thread the diagnostic path was netstat -bano | Select-String -Pattern 11434 followed by netsh interface ipv4 show excludedportrange protocol=tcp, because Windows reserves blocks of ports (typically for Hyper-V) and a reserved range containing 11434 will refuse the bind without anything visibly using the port.

If 11434 falls inside an excluded range, moving Ollama is easier than fighting Windows for the port: set OLLAMA_HOST to something outside the reserved blocks, and point your clients at the new port. Every client that hard-codes 11434 will need updating, which is a good argument for putting the base URL in configuration rather than in code.

Verify the Fix From the Client's Point of View

Testing from the host proves nothing about a container. Test from wherever the failing request actually originates:

All of them should return Ollama is running. Once that works, curl http://<host>:11434/api/tags should return your model list as JSON — which proves not just reachability but that you are talking to a real Ollama rather than something else on the port.

Only then point your framework at it. If your app has its own base-URL setting — OLLAMA_BASE_URL for Open WebUI, the base_url argument in the Python client, the credential URL in n8n — that setting has to match the address that just worked in curl, and it is a separate place to get it wrong. Our Ollama Python API guide and Ollama LangChain integration guide both show where that URL lives in each library.

FAQ

Why does Ollama say "could not connect to ollama app, is it running?" when it clearly is running?

Because the CLI is dialling a different address than the server is bound to. That happens when OLLAMA_HOST was set to a specific IP for the server, in which case the CLI must use that exact IP too — maintainer dhiltgen's explanation in issue #4540 is the definitive statement of it. It also happens when OLLAMA_HOST is set in your shell for one purpose and inherited somewhere you did not intend. Note that this exact wording only exists in Ollama builds older than v0.9.0.

Do I have to set OLLAMA_HOST=0.0.0.0 for Docker?

Yes, if Ollama is installed on the host and your container connects to it. host.docker.internal resolves to the host's bridge-side address, not its loopback, so an Ollama still bound to 127.0.0.1 refuses the container even after you add the hostname. The two fixes are independent and you need both. If Ollama is running inside a container with -p 11434:11434, the official image already handles it.

Why does OLLAMA_HOST=http://localhost not work?

Because Ollama's Host() parser sets the default port from the scheme: an http:// URL with no explicit port defaults to 80, not 11434. Your client dials port 80 and is refused. Either write the port explicitly (http://localhost:11434) or omit the scheme entirely (localhost), which keeps the 11434 default.

Is "connection refused" the same as "address already in use"?

No, and they are opposite ends of the same pipe. Refused means your client found nothing listening. bind: address already in use means the server could not claim the port because something else holds it — often another Ollama instance. The second one causes the first if you never notice it, which is why our Ollama troubleshooting guide handles the bind side separately.

How do I reach a Windows-side Ollama from WSL2?

In default NAT mode, use the Windows host's IP from ip route show | grep -i default | awk '{ print $3}', and make sure Ollama is bound to 0.0.0.0 because WSL arrives as a LAN connection. On Windows 11 22H2 and higher, setting networkingMode=mirrored in .wslconfig is better: Microsoft documents that it lets Linux reach Windows servers on 127.0.0.1 directly. You may also need to allow inbound traffic through the Hyper-V firewall.

The connection hangs for ten seconds and then fails. Is that the same problem?

No. A refusal is instant because the kernel returns a TCP RST. A slow failure means packets are being silently dropped — a firewall, a security group, or an IP that does not host anything at all. Skip the OLLAMA_HOST sections and go to cause 7.

Ollama answers but returns 403. Why?

That is a successful connection with a rejected origin, not a network problem. Ollama allows cross-origin requests from 127.0.0.1 and 0.0.0.0 by default; anything else — including browser extensions — needs adding to OLLAMA_ORIGINS. The FAQ gives chrome-extension://*,moz-extension://*,safari-web-extension://* as the pattern for extensions.

Sources

• Ollama FAQ — the 127.0.0.1:11434 default, the per-OS OLLAMA_HOST procedures, OLLAMA_ORIGINS, the nginx proxy config
• Ollama troubleshooting docs — log locations per platform, journalctl and docker logs commands
• Ollama source on main: envconfig/config.go (Host() scheme-to-default-port logic, ConnectableHost()), cmd/start_default.go and cmd/cmd.go (CLI error strings), server/routes.go (the Ollama is running root route)
• ollama/ollama issues #3200, #4540, #5041, #8396, #11742
• Microsoft — Accessing network applications with WSL (NAT vs mirrored networking, the gateway-IP command, Hyper-V firewall rules)
• Docker CLI reference — docker run (--add-host, host-gateway, host.docker.internal)
• Open WebUI — connection error troubleshooting (the --network=host and OLLAMA_BASE_URL invocations)