Fix Continue in VS Code Not Connecting to Ollama

The Exact Error and Who This Is For

Related: Fix Stable Diffusion Out Of Memory on a 6GB VRAM GPU →

You have Ollama running on your machine. You installed the Continue extension in VS Code to get local autocomplete and chat. You open the sidebar, type a prompt, and get slammed with this exact error:

Error getting response. Failed to fetch

Or, if you dig into the VS Code developer tools console, you see this stack trace:

Error: Connect ECONNREFUSED 127.0.0.1:11434 at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16)

I hit this exact wall on a Tuesday night. My terminal could query Ollama just fine. curl http://localhost:11434/api/tags returned my list of models immediately. But VS Code acted like the Ollama server did not exist.

This guide is for developers running Ollama and VS Code on the same local hardware, or separated by a local WSL2 boundary. We are going to fix the Node.js networking quirks, correct your Continue configuration file, and verify your local port bindings so you can actually get back to writing code.

Check the Continue Config File First

Related: Fix ComfyUI "Torch Not Compiled With CUDA Enabled" Error →

Before you start messing with system environment variables, you need to check what Continue is actually trying to do. The UI for Continue is just a wrapper around a single configuration file. If that file has a typo, the extension fails silently or throws generic network errors.

Open the Continue configuration file. You can find it here depending on your operating system:

• Mac/Linux: ~/.continue/config.json
• Windows: %USERPROFILE%\.continue\config.json

Open it in a standard text editor. Look at the models array. By default, Continue might try to set up an external API provider. You need to explicitly define your local Ollama instance.

Here is exactly what that block should look like for a standard local setup using Llama 3:

{
  "models": [
    {
      "title": "Llama 3 (Ollama)",
      "provider": "ollama",
      "model": "llama3:8b",
      "apiBase": "http://127.0.0.1:11434"
    }
  ],
  "tabAutocompleteModel": {
    "title": "Starcoder 2",
    "provider": "ollama",
    "model": "starcoder2:3b",
    "apiBase": "http://127.0.0.1:11434"
  }
}

Pay strict attention to the apiBase value. The default might be http://localhost:11434. Change it to http://127.0.0.1:11434. Save the file, reload your VS Code window (Command+Shift+P, type "Developer: Reload Window"), and try the chat again. If that fixed it, you just bypassed the Node.js IPv6 bug. If it did not, keep reading.

The Node.js IPv6 Bug

Related: A One-File Docker Compose Stack for Ollama and Open WebUI →

If changing localhost to 127.0.0.1 fixed your issue, here is why that happened.

The Continue extension runs on Node.js inside the VS Code extension host. Starting in Node.js version 17, the developers changed how the dns.lookup() function resolves localhost. Node now prefers IPv6 over IPv4. When Continue asks for localhost, Node resolves it to ::1 (the IPv6 loopback address).

Ollama, by default, binds to 127.0.0.1 (the IPv4 loopback address). It is not listening on ::1.

When Continue sends the HTTP request to ::1:11434, there is nothing listening on the other end. The operating system immediately rejects the connection, resulting in a frustrating Ollama connection refused on 127.0.0.1:11434 error. Hardcoding the IP address in your config.json bypasses DNS resolution entirely, forcing Node to use the correct IPv4 protocol.

Binding Ollama to All Interfaces

Related: Fixing Painfully Slow Whisper Transcription →

If forcing 127.0.0.1 in the config file did not work, your Ollama service might be bound to an unexpected network interface, or you are dealing with a containerization boundary. We need to force Ollama to listen on all available network interfaces, not just loopback.

You do this by setting the OLLAMA_HOST environment variable to 0.0.0.0.

How you set this depends entirely on how you installed Ollama.

If you are running Ollama as a systemd service on Linux:

1. Open your terminal and run sudo systemctl edit ollama.service.
2. This opens an override file in your text editor. Add these exact lines:

[Service]
Environment="OLLAMA_HOST=0.0.0.0"

3. Save and exit.
4. Reload systemd and restart the service:

sudo systemctl daemon-reload
sudo systemctl restart ollama

If you are on Windows using the official Ollama installer:

1. Right-click the Start button and select "System".
2. Click "Advanced system settings".
3. Click "Environment Variables".
4. Under "System variables", click "New".
5. Variable name: OLLAMA_HOST
6. Variable value: 0.0.0.0
7. Click OK. Quit the Ollama app from your system tray and relaunch it.

Restart VS Code completely after doing this. This binding trick is also the exact same solution you need if your Open WebUI in Docker cannot reach Ollama.

WSL2 and Remote SSH Network Headaches

Related: Fix Open WebUI Showing No Models in the Dropdown →

Networking gets significantly more complicated if you use Windows Subsystem for Linux (WSL2). A very common setup is running VS Code in Windows, but running Ollama inside an Ubuntu WSL2 instance to get better access to Nvidia CUDA drivers.

WSL2 runs in a lightweight utility VM. It has its own IP address. While Microsoft built a "localhost forwarder" so Windows applications can access WSL2 ports via 127.0.0.1, this forwarder is notoriously fragile. It breaks frequently after a laptop wakes from sleep or after a Windows update.

When this breaks, Continue in Windows cannot reach Ollama in WSL via localhost.

To fix this, you must bypass the forwarder and point Continue directly at the WSL2 IP address.

1. Open your WSL2 terminal.
2. Run this command to get your internal IP:

ip -4 a show eth0 | grep -oP '(?<=inet\s)\d+(\.\d+){3}'

3. You will get an IP address like 172.24.96.1.
4. Open your Windows Continue config file (%USERPROFILE%\.continue\config.json).
5. Change your apiBase to use that IP address: "apiBase": "http://172.24.96.1:11434"

This will immediately restore the connection. The catch is that this IP address changes every time you restart your PC. You will have to update the config file after every reboot. If you want a permanent fix, you need to run Ollama natively in Windows, or move your VS Code workspace entirely inside WSL2 using the WSL extension.

Verifying the Model is Actually Local

Related: How to Stop Ollama From Unloading Models (keep_alive) →

Sometimes Continue connects to Ollama perfectly, but the chat window still throws an error or returns a blank response. I have wasted hours debugging network rules only to realize I was asking Ollama for a model it did not have downloaded.

When Continue requests a model that does not exist on your disk, Ollama returns an HTTP 404 error. Continue often misinterprets this as a general failure.

Open your terminal and list your available models:

ollama list

You will see output like this:

NAME            ID              SIZE    MODIFIED
llama3:8b       365c0bf3be91    4.7 GB  3 days ago
starcoder2:3b   f67ae0f64584    1.7 GB  2 weeks ago

Look at the NAME column. The string you use in your Continue config.json under the model key must match this name exactly. If your config asks for llama3 but you only have llama2 pulled, it will fail.

If the model is missing, pull it manually in the terminal:

ollama pull llama3:8b

Wait for the download to finish before trying Continue again. If your download speeds are crawling, there are ways to fix an Ollama running slow connection, but usually, it is just high traffic on the Ollama registry.

Configuration vs Environment Variables

When troubleshooting, it is easy to get confused about where a setting actually lives. Are you changing a setting in the VS Code client, or in the Ollama server? Use this table to keep track of what goes where.

Once you have this basic networking stable, you can start doing more advanced integrations, like building a local RAG chatbot that hits this exact same apiBase to index your local markdown notes.

What Did Not Work

I want to save you the time I wasted. When debugging this, I tried several things that seemed logical but ultimately did absolutely nothing to fix the connection.

First, I tried uninstalling and reinstalling the Continue extension in VS Code. This does nothing. The extension state and your config.json persist in your home directory across installations. Reinstalling just wastes two minutes of your life.

Second, I tried changing the Ollama port. I thought maybe another service was squatting on 11434. I set OLLAMA_HOST=127.0.0.1:11435 and updated my Continue config. The error followed me to the new port. The issue was never port conflict; it was always the IPv4/IPv6 loopback mismatch.

Finally, I tried turning off my Windows Firewall entirely. This was a massive red herring. The Windows Firewall does not inspect or block traffic strictly operating on the 127.0.0.1 loopback interface. Disabling the firewall only introduced a security risk without moving me an inch closer to a working autocomplete.

Stick to the apiBase IP change and the OLLAMA_HOST binding. Those are the concrete engineering fixes for this architecture.

FAQ

Why does Continue say "Model not found" when I can see it in terminal?

You likely have a typo in your config.json. The model field in your config file must exactly match the output of ollama list. "Llama3" is not the same as "llama3:8b".

Can I run Ollama on a different PC and connect Continue to it?

Yes. Set OLLAMA_HOST=0.0.0.0 on the remote PC. Then, in your local VS Code Continue config, change apiBase to http://<REMOTE_PC_IP>:11434.

Does Continue need an internet connection to use Ollama?

No. Once you have downloaded the extension in VS Code and pulled your model using ollama pull, all traffic routes locally over your machine's loopback interface.

Why is autocomplete working but the chat window fails?

Continue uses two separate model definitions in config.json. Check the tabAutocompleteModel block vs the models array block. One of them likely has the wrong apiBase or model name set.