"Could Not Connect to Ollama App, Is It Running?" Every Fix (Windows, Linux, Docker, Open WebUI)

"Error: could not connect to ollama app, is it running?" means the ollama command (or an app such as Open WebUI) tried to reach the Ollama server at 127.0.0.1:11434 and nothing answered. Newer versions word the same problem as "could not connect to ollama server, run 'ollama serve' to start it." Here is the part that surprises most people: the ollama command you type is not where the AI runs. It is only a messenger. The model runs inside a separate background server, and this error means the messenger knocked and found nobody home. So the fix is almost always one of three things: start the server (open the Ollama app on Windows or Mac, or run sudo systemctl start ollama on Linux), point the client at the right address, or remove whatever is blocking the connection, most often Docker's networking. To check in five seconds, open http://localhost:11434 in a browser on the same computer. If it says "Ollama is running," the server is fine and the problem is the path to it. Below, we start with the basics and then fix every version of this error: Windows, Linux, Mac, Open WebUI and Docker, WSL2, and connecting from another PC.

Jake's phone repair shop had settled into a routine with its local AI model: his technician typed customer questions into a chat page in the browser, and the model drafted polite replies and repair quotes, all on the shop's own PC. One Monday morning after a Windows update and a restart, the chat page showed a red banner about failing to connect to Ollama. Jake opened a terminal, typed ollama list, and got "could not connect to ollama app, is it running?" He reinstalled Ollama, which fixed the terminal but not the chat page. Three customers waited on quotes that morning while he searched forums. Ethan called back at lunch. The fix took two minutes once they knew which of the three things had broken. Here is how to find yours.

The basics: client, server, and port 11434

Every version of this error makes sense once you see how Ollama is built. It is two programs that talk to each other.

• The server is the part that loads models and does the actual thinking. It runs quietly in the background: as a small app in the system tray on Windows, in the menu bar on a Mac, or as a system service on Linux. You rarely see it.
• The client is whatever sends it questions. The ollama command in your terminal is a client. So are Open WebUI, VS Code extensions, Python scripts, n8n and every other app that "uses Ollama."
• Port 11434 is the door the server listens at. A port is just a numbered entry point on a computer; web servers use 80 and 443, and Ollama uses 11434.
• localhost, or 127.0.0.1, means "this same computer." By default, the Ollama server only listens at 127.0.0.1:11434, which means only programs on the same machine, and outside any container, can reach it.

When you type ollama run llama3.2, the client walks to that door and knocks. "Could not connect" means nobody opened it.

"So reinstalling fixed the terminal because the installer started the server again," Jake said.

"Exactly," Ethan said. "And the chat page still failed because it isn't on the same side of the door as your terminal. It's inside Docker, and Docker has its own idea of what 'this computer' means. Two problems, one error message."

Why there are two wordings of the same error

Older versions of Ollama said "could not connect to ollama app, is it running?" Recent versions say "could not connect to ollama server, run 'ollama serve' to start it." They mean exactly the same thing, and the fixes below apply to both. A third variant appears when you check the version with ollama -v while the server is down:

$ ollama -v
Warning: could not connect to a running Ollama instance
Warning: client version is <your version>

That one is actually a handy test: if ollama -v prints only a version number and no warning, the server is running and reachable.

First, is the server running? One check for every system

Before changing anything, find out which side of the door has the problem. These checks take seconds and change nothing.

1. Browser check. On the computer where Ollama is installed, open http://localhost:11434. If the page shows Ollama is running, the server is up.
2. Terminal check. Run curl http://localhost:11434/api/version. A reply like {"version":"..."} means the server is up and answering its API.
3. Who is listening? On Windows, run netstat -ano | findstr 11434. On Linux, run ss -ltnp | grep 11434. On a Mac, run lsof -iTCP:11434 -sTCP:LISTEN. You will see the address the server listens on.

Here is what the last check looks like on a Linux machine with Ollama's default settings:

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

$ ss -ltnp | grep 11434
LISTEN 0      4096       127.0.0.1:11434      0.0.0.0:*

That 127.0.0.1:11434 is the most important detail in this whole guide. It means the server only accepts connections from the same machine. Programs on this computer can connect; Docker containers, WSL, phones and other PCs cannot, until you change it.

What you see	What it means	Go to
Browser can't reach localhost:11434	The server is not running on this machine.	Windows, Linux, Mac
"Ollama is running," but the terminal still errors	The client is pointed somewhere else, usually by an OLLAMA_HOST setting.	Wrong address
"Ollama is running," but Open WebUI or Docker fails	The container cannot see the host's 127.0.0.1.	Open WebUI and Docker
Works on this PC, not from another one	The server listens on 127.0.0.1 only, or a firewall blocks 11434.	Remote access
"'ollama' is not recognized" or "command not found"	The terminal cannot find the program at all.	PATH fix

Windows: start the Ollama app, and why it isn't opening

On Windows, the server is the Ollama app itself. When it is running, a small llama icon sits in the system tray at the bottom right (click the up arrow to see hidden icons). No icon usually means no server.

1. Start it. Open Start, type Ollama, and open the app. Wait a few seconds, then check http://localhost:11434 again.
2. Check that it is really gone. Open Task Manager (Ctrl + Shift + Esc) and look on the Processes tab for ollama app and ollama. If they are listed but the tray icon is hidden, the server may already be running and the problem is elsewhere.
3. Make it start with Windows. The installer normally adds Ollama to startup. If it stopped starting after an update, open Settings → Apps → Startup and switch Ollama on.
4. Read its logs if it will not stay open. Press Windows + R, type explorer %LOCALAPPDATA%\Ollama, and open app.log (the tray app) and server.log (the server). The last lines usually say exactly why it closed.

"Why is Ollama not opening?" The usual reasons on Windows

• It is already running. Opening it a second time does nothing visible. Check the tray and Task Manager before assuming it failed.
• Security software blocked it. Some antivirus products quarantine new programs that open network ports. Check your antivirus history for anything from %LOCALAPPDATA%\Programs\Ollama, restore it, and allow it.
• Port 11434 is taken. If another program, or a second copy of Ollama run from a terminal, already holds the port, the app's server cannot start. netstat -ano | findstr 11434 shows the process ID in the last column; Task Manager's Details tab matches it to a name.
• A broken update. If server.log stops mid-startup after an update, download the current installer from ollama.com and install over the top. Your downloaded models live separately, in %HOMEPATH%\.ollama, and are not touched.

To restart Ollama cleanly on Windows, right-click the tray icon, choose Quit Ollama, then open it again from Start. Do this after changing any Ollama environment variable too, because the server only reads them when it starts.

"ollama is not recognized as an internal or external command"

This one is not a connection problem at all. Windows cannot find the ollama program, so it never even gets to knock. On Linux and Mac, the same situation reads "ollama: command not found."

1. Open a new terminal. The installer adds Ollama to your PATH (the list of folders Windows searches for commands), but terminals that were already open keep the old list. Close every terminal, including the one inside VS Code, and open a fresh one.
2. Check the folder exists. Press Windows + R and run explorer %LOCALAPPDATA%\Programs\Ollama. You should see ollama.exe. If the folder is missing, Ollama is not installed for this Windows user; install it while signed in as that user.
3. Check the PATH. In PowerShell, run $env:Path -split ';' | Select-String Ollama. If nothing comes back, open Edit environment variables for your account, select Path, choose Edit, and add %LOCALAPPDATA%\Programs\Ollama. Then open a new terminal.
4. Use the full path meanwhile. & "$env:LOCALAPPDATA\Programs\Ollama\ollama.exe" list works even with a broken PATH, which proves the program itself is fine.

On Linux, the install script puts the binary in /usr/local/bin; run ls /usr/local/bin/ollama to confirm it is there, and reinstall if not. If you are on Kali and still finding your feet with sudo and system folders, our guide to root, su and sudo starts from the basics.

Linux: start the service, and the "two servers" trap

On Linux, the official install script sets Ollama up as a systemd service called ollama, which starts at boot and runs as its own ollama user. Start and check it like any other service:

sudo systemctl start ollama      # start it now
sudo systemctl enable ollama     # start it at every boot
systemctl status ollama          # is it active (running)?
journalctl -u ollama --no-pager -n 50   # the last 50 log lines

If systemctl status shows failed, the log lines explain why; the usual reasons are a port already in use, a broken environment setting from a recent edit, or a disk that is full. The same commands work on Ubuntu, Debian, Kali and Fedora.

The "two servers" trap: why your models disappeared

Many tutorials say to run ollama serve in a terminal. On a Linux machine where the service is already running, that creates confusion, because it starts a second server as your own user, and the two keep their models in different places:

Started by	Runs as	Keeps models in
The systemd service	The ollama user	/usr/share/ollama/.ollama/models
ollama serve in your terminal	You	~/.ollama/models

Whichever server grabs port 11434 first is the one your client talks to. So a model downloaded while one was running "vanishes" when the other one answers next time. If you do not have a specific reason to run ollama serve by hand, don't; let the service do it. If you prefer running it by hand, stop and disable the service first with sudo systemctl disable --now ollama.

"ollama serve" not working: address already in use

If you run ollama serve and get "Error: listen tcp 127.0.0.1:11434: bind: address already in use" (on Windows: "Only one usage of each socket address ... is normally permitted"), that is good news in disguise: a server is already running. You do not need a second one. Close that terminal and use ollama commands normally. Only if you deliberately want to run the server by hand, with special settings in front of you, stop the existing one first: quit the tray app on Windows or Mac, or run sudo systemctl stop ollama on Linux.

Mac: the menu bar app

On a Mac, the server is the Ollama app, and it shows a small llama icon in the menu bar while it runs. Open Ollama from Applications or Spotlight to start it. The first time, macOS may ask you to confirm that you want to open an app downloaded from the internet; until you accept, nothing runs, so look for that dialog behind other windows. The log lives at ~/.ollama/logs/server.log. To make it open at login, add it under System Settings → General → Login Items.

If you installed Ollama with Homebrew instead of the app, the server is a background service that you start with brew services start ollama and check with brew services list. Do not run both the Homebrew service and the app: they compete for port 11434 exactly like the two Linux servers above, and whichever loses shows up as "could not connect" or as missing models. Pick one, and quit or stop the other. Environment variables for the app are set with launchctl setenv and need the app to be restarted; for the Homebrew service, they belong in the service's own configuration, so restart it with brew services restart ollama after any change.

Where Ollama keeps everything, on each system

Half of troubleshooting is knowing where to look. This table saves the searching:

	Windows	Linux (service)	Mac (app)
Program	%LOCALAPPDATA%\Programs\Ollama	/usr/local/bin/ollama	/Applications/Ollama.app
Server runs as	The tray app, as you	The ollama systemd service	The menu bar app, as you
Logs	%LOCALAPPDATA%\Ollama (app.log, server.log)	journalctl -u ollama	~/.ollama/logs/server.log
Downloaded models	%HOMEPATH%\.ollama\models	/usr/share/ollama/.ollama/models	~/.ollama/models
Settings	User environment variables, then restart the app	sudo systemctl edit ollama.service	launchctl setenv, then restart the app

Every running server prints its full configuration near the top of its log, in a line that starts with server config. It lists OLLAMA_HOST, OLLAMA_MODELS, OLLAMA_ORIGINS and everything else. When a setting you changed "isn't working," that line shows what the server actually read, which ends a lot of guessing.

Port 11434 is taken? Run Ollama on a different port

Occasionally another program already uses port 11434, or you want two separate Ollama servers on one machine. Both the server and every client have to agree on the new port, because the default is baked into all of them.

1. Find who has the port. On Windows, netstat -ano | findstr 11434 shows a process ID; match it in Task Manager's Details tab. On Linux, sudo ss -ltnp | grep 11434 shows the program name directly.
2. Move the server. Set OLLAMA_HOST=127.0.0.1:11435 (or 0.0.0.0:11435 for network access) for the server using the method for your system, and restart it.
3. Move every client. In the terminal, set the same OLLAMA_HOST value before running ollama commands. In Open WebUI and other apps, change the URL to :11435.
4. Check. http://localhost:11435 should now say Ollama is running, and ollama -v should print no warning in a terminal with the new value set.

If the program holding 11434 turns out to be an older Ollama that should not be there, such as a forgotten ollama serve in another terminal window, closing it is simpler than moving the port.

Ollama not working on Windows at all? The clean reset

When the tray app will not start, the logs show nothing useful, and you have already rebooted, a clean reset takes about five minutes and keeps your downloaded models.

1. Stop everything. Quit Ollama from the tray, then open Task Manager and end any remaining ollama or ollama app processes.
2. Uninstall. Open Settings → Apps → Installed apps, find Ollama, and choose Uninstall.
3. Keep your models. Leave %HOMEPATH%\.ollama alone; that is where your downloaded models are, and a reinstall will find them again.
4. Clear old logs and leftovers. Open %LOCALAPPDATA%\Ollama and move its contents to a backup folder (or delete them), and check that %LOCALAPPDATA%\Programs\Ollama is gone.
5. Remove stray settings. Under Edit environment variables for your account, remove any OLLAMA_* variables you do not remember setting on purpose.
6. Restart Windows, then install the current version from ollama.com, signed in as the user who will use it.
7. Verify. Open http://localhost:11434, run ollama list, and your models should be listed again.

If even a fresh install will not stay open, the new app.log and server.log will now contain only this attempt, which makes the real error easy to spot. Security software is the most common culprit at that point; installing from the official source and allowing it in your antivirus resolves most of these cases.

"Ollama is running" but the terminal still can't connect

This combination has one common cause: the client is knocking at the wrong door. The ollama command reads the OLLAMA_HOST environment variable to decide where the server is. If a tutorial had you set it, say to a server on another PC or to 0.0.0.0, your client may still be using it.

• Windows (PowerShell): echo $env:OLLAMA_HOST
• Linux and Mac: echo $OLLAMA_HOST

If it prints an address you do not expect, remove the variable (on Windows, under Edit environment variables for your account; on Linux and Mac, from your ~/.bashrc, ~/.zshrc or ~/.profile) and open a new terminal. Setting OLLAMA_HOST=0.0.0.0 is correct for the server, so it listens on every network interface. For a client on the same machine, though, the right address is 127.0.0.1:11434, or simply leaving the variable unset.

Open WebUI "could not connect to Ollama" (and other Docker apps)

This is the most common version of the problem today, and it is where Jake's chat page was stuck. Open WebUI usually runs in Docker, and Ollama usually runs directly on the computer. The trap is one word: localhost.

Inside a Docker container, localhost means the container itself, not your computer. So when Open WebUI tries http://localhost:11434, it knocks on its own door, where no Ollama lives. It needs the address of the host, the computer the container runs on. Docker provides one: host.docker.internal.

Open WebUI's own recommended command for this setup adds that name and maps the ports:

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

With that, Open WebUI reaches Ollama at http://host.docker.internal:11434, and you open Open WebUI itself at http://localhost:3000. On Docker Desktop for Windows and Mac, host.docker.internal exists automatically; the --add-host part is what makes it work on Linux.

On Linux there is a second half. Remember that Ollama listens on 127.0.0.1 only. A container reaching the host through Docker's bridge network arrives from a different address, so the server ignores it. The fix is to make Ollama listen on all interfaces:

sudo systemctl edit ollama.service
# add these two lines, then save:
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

sudo systemctl daemon-reload
sudo systemctl restart ollama
ss -ltnp | grep 11434        # should now show 0.0.0.0:11434 or *:11434

Then, if your firewall is on, allow the Docker bridge to reach port 11434, and before anything else read the security note below, because 0.0.0.0 also opens the door to your local network.

The other option: --network=host

If you would rather skip the bridge entirely on Linux, run Open WebUI on the host's network. Then 127.0.0.1 inside the container really is your computer, but the port changes:

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

With host networking, open Open WebUI at http://localhost:8080, not 3000. That port change catches many people, who then think the container is broken.

Changing the address inside Open WebUI

You do not always need to recreate the container. In current versions, an administrator can change the Ollama address in the web interface: open the Admin Panel, go to Settings → Connections, and set the Ollama API URL to http://host.docker.internal:11434 (or the address that matches your setup). Use the verify button next to it, and save. If the address is right and it still fails, the problem is on the Ollama side: the listening address or the firewall.

Test the connection from inside the container

When the address looks right and Open WebUI still refuses, test from the container's own point of view instead of guessing. Open WebUI's image includes Python, so this one-liner works even where curl is missing:

docker exec -it open-webui python3 -c "import urllib.request; print(urllib.request.urlopen('http://host.docker.internal:11434').read())"

If it prints b'Ollama is running', the network path is fine and the problem is the URL saved in Open WebUI's settings. If it fails with "connection refused," Ollama is not listening where the container can reach it, which on Linux almost always means OLLAMA_HOST is still at its default 127.0.0.1. If it fails with a name error, the --add-host part of the run command is missing.

When Ollama also runs in Docker

If both run as containers, put them on the same Docker network and use the Ollama container's name as the address. With Docker Compose, that is automatic:

services:
  ollama:
    image: ollama/ollama
    volumes: ["ollama:/root/.ollama"]
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    ports: ["3000:8080"]
    environment: ["OLLAMA_BASE_URL=http://ollama:11434"]
    depends_on: [ollama]
volumes:
  ollama:

Here http://ollama:11434 works because Compose gives each service a name that the others can use. The same pattern applies to n8n, Flowise, AnythingLLM and other tools in containers. To let the Ollama container use an NVIDIA GPU too, add the GPU settings from our Ollama GPU guide.

For Jake, the culprit was exactly this. The Windows update had restarted Docker Desktop before Ollama's tray app was back, and Open WebUI had been set up with localhost instead of host.docker.internal, which had only ever worked by luck from an earlier test. Ethan changed the address in Settings → Connections, and the chat page came back while they were still on the phone.

WSL2 and Windows: which side is Ollama on?

WSL2 runs Linux in a small virtual machine, so it has its own network address. Whether the connection works depends on which side Ollama is installed.

• Ollama inside WSL, app on Windows. This usually works out of the box: WSL forwards its localhost ports to Windows, so a Windows browser or app can use http://localhost:11434.
• Ollama on Windows, client inside WSL. This is the one that fails. Inside WSL, localhost means the Linux side. On Windows 11 22H2 and later, the cleanest fix is WSL's mirrored networking: open the WSL Settings app (or create %UserProfile%\.wslconfig), set the networking mode to mirrored, then run wsl --shutdown and start WSL again. With mirrored mode, 127.0.0.1:11434 inside WSL reaches the Windows server.

[wsl2]
networkingMode=mirrored

Without mirrored mode, you would set OLLAMA_HOST=0.0.0.0 on the Windows side, allow port 11434 in Windows Firewall, and point the WSL client at the Windows machine's address, which is more moving parts for the same result. If WSL itself is new to you, our WSL guide covers installing and updating it.

Connect to Ollama remotely, from another PC or a phone

Jake's next request was natural: could his technician use the model from the front-desk PC too? Yes, in three steps. Ollama has no built-in password, so read the security section after this before you do it on any network you do not fully trust.

1. Make the server listen on the network. Set OLLAMA_HOST=0.0.0.0:11434 for the server, then restart it.

• Windows: quit Ollama from the tray, add OLLAMA_HOST with the value 0.0.0.0:11434 under Edit environment variables for your account, and start Ollama again.
• Linux: the systemctl edit ollama.service steps from the Docker section above.
• Mac: run launchctl setenv OLLAMA_HOST "0.0.0.0:11434", then quit and reopen the app.

2. Allow port 11434 through the firewall, for your local network only.

# Windows (PowerShell as administrator), private networks only
New-NetFirewallRule -DisplayName "Ollama LAN" -Direction Inbound -Protocol TCP `
  -LocalPort 11434 -Action Allow -Profile Private

# Linux with ufw, only from your home or office subnet
sudo ufw allow from 192.168.1.0/24 to any port 11434 proto tcp

Replace 192.168.1.0/24 with your own network's range. On Windows, make sure your network is set to Private, not Public, in Settings → Network & internet, or the rule will not apply.

3. Point the other device at the server's address. Find the server PC's local IP (ipconfig on Windows, ip addr on Linux), for example 192.168.1.50. On the other PC, test with a browser at http://192.168.1.50:11434; it should say Ollama is running. Then point the client there: OLLAMA_HOST=http://192.168.1.50:11434 ollama list for the command line, or that same URL as the Ollama address in Open WebUI or your app.

Using it from a phone or tablet

The friendliest way to reach a home or shop Ollama from a phone is not the raw API at all, but Open WebUI's page on your network: on the phone's browser, open http://server-ip:3000 (or :8080 with host networking). Open WebUI has its own user accounts, and the first account created becomes the administrator, so you can give each person a login instead of handing the whole network an open API. That also means you only need to allow Open WebUI's port through the firewall, and Ollama itself can stay on 127.0.0.1 where nothing else can reach it, which is the safest arrangement of all for a small office.

If a browser-based app on another origin is refused even though the address works, the server is blocking it for safety; add the app's address to OLLAMA_ORIGINS on the server and restart it.

Security: never put port 11434 on the open internet

This deserves its own heading because the mistake is common and the consequences are real. The Ollama API has no login and no password. Anyone who can reach port 11434 can use your models, keep your GPU busy, pull new models onto your disk and read anything a model was given. Security researchers keep finding Ollama servers that are exposed straight to the internet, usually because someone forwarded the port on their router to "use it from anywhere."

Safe patterns, from simplest to most robust:

• Same PC only: keep the default 127.0.0.1. Nothing else can connect.
• Home or shop network: 0.0.0.0 plus a firewall rule limited to your local subnet, as above. Never forward 11434 on your router.
• From outside, for yourself: use a private VPN such as WireGuard or Tailscale, and connect to the server's VPN address. The port stays invisible to the internet.
• For a team or a business: put a reverse proxy with real authentication (or your organization's zero-trust access gateway) in front of Ollama, and keep Ollama itself bound to 127.0.0.1 behind it.

Connecting apps: VS Code, Python, n8n and OpenAI-style clients

Most apps that "use Ollama" need just one setting, the base URL, and most connection failures are a small mistake in it. The right values on the same machine:

App expects	Use
An Ollama URL	http://localhost:11434
An OpenAI-compatible base URL	http://localhost:11434/v1, with any non-empty text as the API key
The app runs in Docker	http://host.docker.internal:11434 (plus the Linux steps above)
Ollama is on another PC	http://192.168.x.x:11434, after the remote steps above

The common slips: https instead of http (Ollama serves plain HTTP unless you put a proxy in front), a missing :11434, /v1 added where the app wants the plain Ollama URL or left out where it wants the OpenAI one, and localhost used from inside a container. A ten-second test from the same place the app runs, such as curl http://host.docker.internal:11434 from inside the container, tells you whether the address works before you blame the app.

A few concrete examples. In VS Code extensions that talk to Ollama, such as Continue, the setting is usually called apiBase or Ollama URL, and http://localhost:11434 is the right value on the same machine. In n8n, the Ollama credential has a Base URL field; when n8n runs in Docker, which is how most people run it, that field needs http://host.docker.internal:11434, not localhost, which is the single most common n8n-plus-Ollama question. LangChain and LlamaIndex take a base_url parameter with the same value.

For a Python script, the official ollama package reads OLLAMA_HOST, or you pass the address directly with Client(host='http://localhost:11434'). If the request reaches the server but the reply is an error, read it carefully: that is no longer a connection problem, which brings us to the next section.

Errors that look like connection problems but aren't

• "An existing connection was forcibly closed by the remote host" (Windows) or "connection reset by peer": the client did connect, then the server dropped it, usually because it crashed while loading a model that did not fit in memory. Check server.log or journalctl -u ollama for the crash, and see our GPU and memory guide.
• "... does not support tools": the connection is fine; the model you chose was not trained for tool calling. Pick a model whose Ollama page lists tools.
• "... does not support generate": you sent a chat request to an embedding model such as nomic-embed-text. Use a chat model for chat, and the embedding model only for embeddings.
• "This model does not support images": attach images only to vision models.
• Timeouts while a model loads: the first request after a model has unloaded can take a while, especially for large models. Many apps give up after 30 or 60 seconds. Try again once the model is loaded, or raise the app's timeout.

For IT admins: running Ollama as a shared service

When a team relies on one Ollama box, "could not connect" becomes an outage, so treat it like any other internal service. Run it under systemd with Restart=always (the default unit already restarts it), keep settings in a systemctl edit override rather than editing the unit file, and monitor GET /api/version from your uptime checker so you hear about a dead server before your users do. Put it behind a reverse proxy that handles TLS and authentication, log who uses it, and size it for concurrency: each parallel request reserves its own context memory. On managed Windows clients, set OLLAMA_HOST centrally only for machines that use a shared server; a stray value pushed to every laptop produces exactly the "running but can't connect" puzzle described above.

Still can't connect? The checklist, in order

1. On the server machine, does http://localhost:11434 say Ollama is running? If not, start the app or the service.
2. Does ollama -v print a version with no warning? If it warns, check OLLAMA_HOST in that terminal.
3. Is the client in Docker or WSL? Use host.docker.internal or mirrored networking, not localhost.
4. Is the client on another device? Check that the server listens on 0.0.0.0 (ss or netstat) and that the firewall allows 11434 from your network.
5. Is the address exact? http, not https; port 11434; /v1 only for OpenAI-style clients.
6. Did you change a setting? Restart the server; it only reads environment variables at startup.
7. Still stuck? Read the last lines of server.log or journalctl -u ollama. The server nearly always says why it stopped.

Could not connect to Ollama: frequently asked questions

Jake's Monday problem turned out to be two small things wearing one error message: a server that had not started yet, and a container that had been knocking on its own door all along. Now the chat page points at host.docker.internal, Ollama starts with Windows, and the technician's front-desk PC reaches it over the shop network and nowhere else. If you have been reinstalling Ollama over this, please don't be hard on yourself. The error says "could not connect," but it never says who couldn't reach whom, and that is the whole puzzle.

Revision note. Written October 5, 2026. If a red "could not connect" banner held up your morning, the fix is usually one address away; may the next knock get an answer.