TL;DR: ollama run works in your terminal, but Cline, Continue.dev, or Cursor throws fetch failed or ECONNREFUSED 127.0.0.1:11434. Nine times out of ten it’s one of three things: the client resolved localhost to IPv6 while Ollama listens on IPv4, a WSL/Docker network boundary the loopback address can’t cross, or Ollama simply isn’t bound to the address the client is calling. Swap localhost for 127.0.0.1 first — it fixes the most common case in ten seconds.

	Cline	Continue.dev	Cursor
Where the URL lives	Provider settings → Base URL	config.yaml → apiBase	Settings → Models → Override Base URL
Correct value	http://127.0.0.1:11434	http://127.0.0.1:11434	http://127.0.0.1:11434/v1
Most common error	fetch failed in the task view	”HTTP 0” / no completions	”network error” in chat
Top fix	Use 127.0.0.1, not localhost	Same, plus check apiBase has no /v1	Same, plus API key must be non-empty

Honest take: Before you touch any config, run curl http://127.0.0.1:11434 in the same environment the editor runs in. If that returns “Ollama is running,” the model is fine and the problem is address resolution or a network boundary — not Ollama. If it hangs or refuses, fix Ollama first and the editors will follow.

Start here: prove Ollama is actually reachable

Every “connection refused” debugging session should begin with one command, run from the same machine and same shell context your editor runs in:

$ curl http://127.0.0.1:11434
Ollama is running

If you see Ollama is running, the server is up and listening on IPv4 loopback. The bug is now entirely on the client side — an address mismatch, an IPv6 quirk, or a network boundary. Skip to the tool-specific sections.

If curl hangs, times out, or prints Connection refused, Ollama is not listening where you’re looking. Ollama binds 127.0.0.1 port 11434 by default, per the official FAQ. Confirm the process is alive and the model is loaded:

$ ollama ps
NAME                 ID              SIZE      PROCESSOR    UNTIL
qwen2.5-coder:14b    9ec8897f747a    11 GB     100% GPU     4 minutes from now

No rows? The model isn’t loaded yet — run ollama run qwen2.5-coder:14b once to pull it into memory. No response at all from ollama ps? The daemon isn’t running: start it with ollama serve (or sudo systemctl start ollama on systemd Linux, or launch the menu-bar/tray app on macOS and Windows).

Fix #1: the localhost vs 127.0.0.1 trap (the big one)

This is the single most common cause of “connection refused” when Ollama is demonstrably running. Cline and Continue.dev are Node/Electron applications. Node’s DNS resolver, since v17, returns results in the order the OS provides them — and on a dual-stack machine that usually means localhost resolves to the IPv6 address ::1 before the IPv4 127.0.0.1.

Ollama, by default, listens only on the IPv4 loopback 127.0.0.1. So the client dials ::1:11434, nothing is listening there, and you get ECONNREFUSED ::1:11434 or a bare fetch failed. This is a documented, reproducible mismatch — the Ollama JS client has an open issue where localhost fails while 127.0.0.1 works from the exact same script.

The fix is to stop using the hostname and use the literal IPv4 address everywhere:

• Not http://localhost:11434
• Use http://127.0.0.1:11434

Change it in whichever tool is failing (config values below) and restart the extension. In my experience this resolves the majority of “but Ollama is running!” reports on a single developer machine.

If you genuinely need localhost to work for both stacks, tell Ollama to listen on all interfaces (OLLAMA_HOST=0.0.0.0:11434, covered below), which binds IPv6 too — but read the IPv6-only warning at the end first.

Fix #2: Cline says fetch failed

In Cline, open the provider settings, select Ollama as the API provider, and set the Base URL. Cline talks to Ollama’s native API, so the base URL is the root — no /v1 suffix:

Base URL: http://127.0.0.1:11434
Model:    qwen2.5-coder:14b

Then confirm the model name matches exactly what ollama list reports, tag included. A mismatch (qwen2.5-coder vs qwen2.5-coder:14b) surfaces as a request that connects and then fails, which is easy to misread as a connection problem.

If Cline still shows fetch failed after switching to 127.0.0.1, the request is completing the TCP handshake but the model isn’t ready. Ollama loads the model into VRAM on the first request, and a cold 14B model can take 20–40 seconds. Cline’s default request timeout can fire before that finishes, printing fetch failed. Pre-warm the model once from the terminal (ollama run <model> and send one prompt), then retry inside Cline against the now-hot model.

Cline runs multiple files and command output into every prompt, so also make sure you haven’t hit the silent context-truncation trap — that’s a separate failure that looks like the agent “forgetting,” not a connection error. We cover it in the num_ctx fix guide.

Fix #3: Continue.dev returns no completions

Continue.dev is configured through config.yaml (the current format as of 2026; older installs used config.json). A working local model block looks like this:

models:
  - name: Qwen 2.5 Coder 14B
    provider: ollama
    model: qwen2.5-coder:14b
    apiBase: http://127.0.0.1:11434

Two things trip people up here:

1. apiBase takes the root URL, not /v1. The ollama provider speaks Ollama’s native API. Appending /v1 gives you a 404 that Continue surfaces as “HTTP 0” or a completion that never arrives. Only use /v1 if you deliberately set provider: openai to hit the OpenAI-compatible endpoint.
2. Restart the extension after editing the config. Continue reloads config.yaml on save in recent versions, but if completions still don’t appear, reload the VS Code window (Cmd/Ctrl+Shift+P → “Developer: Reload Window”) to force it.

Verify the endpoint independently before blaming Continue:

$ curl http://127.0.0.1:11434/api/tags
{"models":[{"name":"qwen2.5-coder:14b", ... }]}

If that lists your model but Continue still shows nothing, the problem is the config file, not the connection.

Fix #4: Cursor throws a network error in chat

Cursor is the odd one out. Its Chat, Cmd+K, and Agent modes use the OpenAI-compatible endpoint, so the base URL needs the /v1 suffix:

1. Cursor Settings → Models
2. Scroll to the OpenAI API Key section
3. Toggle on Override OpenAI Base URL
4. Enter: http://127.0.0.1:11434/v1
5. In the API Key field, enter any non-empty string — Ollama doesn’t validate keys, but Cursor refuses to send a request with an empty field. ollama works.

Two Cursor-specific gotchas:

• Tab autocomplete stays cloud-only. The Override Base URL setting has no effect on Cursor Tab, which runs on Cursor’s proprietary server-side FIM model. If your “connection” complaint is really “Tab isn’t using my local model,” that’s by design, not a bug — see our full Cursor + Ollama setup.
• Corporate proxies intercept localhost. A minority of users behind VPNs or corporate firewalls find 127.0.0.1:11434/v1 still times out because a network proxy grabs the request. The workaround is to expose Ollama through a tunnel:

ngrok http 11434 --host-header="localhost:11434"

Use the printed HTTPS URL plus /v1 as your Cursor base URL. Note the free ngrok tier rotates the URL on every restart.

Fix #5: WSL 2, Docker, and remote machines

If the client and Ollama are in different network namespaces, 127.0.0.1 will never work — it points at the wrong machine. This is the second-most-common category after the IPv6 trap.

WSL 2 → Windows Ollama (or the reverse). WSL 2 runs in its own network namespace, so loopback doesn’t cross the boundary. Bind Ollama to all interfaces on the host and point the client at the host’s real IP:

# On the machine running Ollama:
OLLAMA_HOST=0.0.0.0:11434

Then, from WSL, find the Windows host IP (cat /etc/resolv.conf shows the nameserver, or use the mirrored-networking IP) and use http://<windows-host-ip>:11434. If you enabled WSL’s mirrored networking mode, 127.0.0.1 starts working again because the namespaces share the loopback — that’s the cleanest fix if you’re on a recent Windows build. For the GPU-passthrough side of running local models under WSL, see our WSL 3 GPU guide.

Docker containers. Inside a container, localhost is the container itself, not the host. Use:

• http://host.docker.internal:11434 on Docker Desktop (Windows/macOS)
• http://172.17.0.1:11434 on native Linux (the default bridge gateway)

And, again, Ollama on the host must be bound to 0.0.0.0, not just 127.0.0.1, or the container can’t reach it.

A separate machine on your LAN. Point the base URL at that box’s IP: http://192.168.1.100:11434 (add /v1 for Cursor). The server must run with OLLAMA_HOST=0.0.0.0:11434.

How to actually set OLLAMA_HOST (per OS)

Setting the variable in the shell you launched ollama serve from is easy, but if Ollama runs as a service or app, it ignores your shell. Set it where the service reads it:

macOS (menu-bar app):

launchctl setenv OLLAMA_HOST "0.0.0.0:11434"

Then quit and reopen Ollama from the menu bar.

Linux (systemd):

sudo systemctl edit ollama.service

Add under the [Service] section:

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

Then reload and restart:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Windows: Quit Ollama from the system tray, open Settings and search for “environment variables,” click Edit environment variables for your account, add OLLAMA_HOST = 0.0.0.0:11434, save, and relaunch Ollama from the Start menu. Ollama inherits your account environment variables on launch.

Confirm it took effect:

$ ollama ps
# then, from another machine or namespace:
$ curl http://<server-ip>:11434
Ollama is running

Fix #6: the firewall (remote access only)

If curl works locally on the server but the client machine still can’t connect after binding to 0.0.0.0, a firewall is dropping the inbound connection. Windows Defender, corporate endpoint protection, and Linux ufw all block port 11434 by default for external traffic. Add an inbound allow rule for TCP 11434 on the server. This never affects same-machine setups — only cross-machine, WSL, and Docker.

The IPv6-only binding gotcha

One trap when you set OLLAMA_HOST=0.0.0.0: on some Linux systems Ollama can end up listening on IPv6 only, so IPv4 clients calling 127.0.0.1 still get refused. This traces back to a Go networking quirk (golang/go#48723). Per the confirmed discussion on Ollama issue #3961: “By default, it seems it’ll listen on both v4 and v6. If you set BindIPv6Only in systemd.socket, or /proc/sys/net/ipv6/bindv6only is set to 1, it may not listen on v4.”

If you hit this, check:

$ cat /proc/sys/net/ipv6/bindv6only
0

It should be 0. If it’s 1, either reset it or bind Ollama to an explicit IPv4 address (OLLAMA_HOST=127.0.0.1:11434 for local, or your machine’s LAN IPv4) instead of 0.0.0.0.

CORS: only for browser-based clients

If your client is a browser extension rather than a desktop editor, a connection can succeed at the network layer and still be blocked by CORS. Cline, Continue.dev, and Cursor are desktop apps and don’t hit this, but if you’re wiring a browser tool, allow its origin:

OLLAMA_ORIGINS=chrome-extension://*,moz-extension://*,safari-web-extension://*

Set it the same way as OLLAMA_HOST for your OS.

The debugging ladder, in order

When you’re stuck, work down this list — each step rules out one layer:

1. curl http://127.0.0.1:11434 from the editor’s environment → is Ollama reachable at all?
2. ollama ps → is the model loaded, or is a cold start timing out?
3. Switch localhost → 127.0.0.1 in the client → fixes the IPv6 resolution mismatch.
4. Check the URL shape: root for Cline/Continue (ollama provider), /v1 for Cursor.
5. Different namespace (WSL/Docker/remote)? → OLLAMA_HOST=0.0.0.0 + real IP, not loopback.
6. Cross-machine still failing? → open firewall TCP 11434.
7. Bound 0.0.0.0 but IPv4 refuses? → check bindv6only.

FAQ

Why does ollama run work in my terminal but the editor can’t connect? The terminal uses whatever address you type; the editor uses whatever you configured, and Node-based editors resolve localhost to IPv6 first. Ollama listens on IPv4 by default, so the editor dials an address nothing is listening on. Use 127.0.0.1.

Do I need /v1 at the end of the URL? Only for OpenAI-compatible clients. Cursor’s OpenAI override needs http://127.0.0.1:11434/v1. Cline and Continue.dev using the native ollama provider need the root URL with no /v1.

My model works for one message then fails. That’s usually not a connection issue — it’s Ollama silently truncating context once the prompt exceeds the default window. See the num_ctx fix.

Is 0.0.0.0 safe? It exposes Ollama to every machine that can reach the port. On a trusted LAN behind a router, fine. On a shared or public network, restrict it with a firewall rule or bind to a specific interface instead.

How much VRAM do I need before any of this is worth it? A usable 14B coder model wants ~12–16 GB. For the hardware side of running local models for coding, see runaihome.com’s breakdown at https://runaihome.com/blog/best-local-ai-models-by-vram/, and the open-source tooling landscape at aifoss.dev.

Sources

• Ollama FAQ — network configuration, OLLAMA_HOST, OLLAMA_ORIGINS (verified Jul 13 2026)
• Ollama issue #3961 — OLLAMA_HOST 0.0.0.0 IPv6-only binding
• ollama-js issue #102 — localhost fails, 127.0.0.1 works
• Ollama OpenAI API compatibility
• Cursor community — set up Ollama local model in Cursor

Last verified: Jul 13 2026. Ollama binds 127.0.0.1:11434 by default; all commands tested against the current Ollama FAQ.