Ollama Desktop Says Server Not Ready on Windows but the Server Is Fine

Ollama Desktop starts, and then just sits there: "ollama server not ready, continuing anyway" every few seconds, forever. The app never connects. So you check the obvious things and they're all fine. server.log is empty. Nothing is listening on port 11434. And yet, if you open a terminal and run ollama serve yourself, it works perfectly.

That last part is the clue. The server binary is fine. The problem is the environment the desktop app spawns it in, and it's almost always one of two silent traps.

Trap 1: a second launcher is already holding the port

The most common one on Windows. Ollama's app has a launch-at-login option, and plenty of people also layer their own autostart on top of it: a shortcut in the Startup folder, a .vbs script, a Task Scheduler entry. Something that runs ollama.exe serve at login.

Then the desktop app starts later and spawns its own ollama serve child. The child tries to bind port 11434, finds it taken by the instance that's been running since login, and exits. The app's log keeps repeating "server not ready," but the child never got far enough to write anything to server.log, so you have no idea what happened.

The server that's actually running is the autostart one, and it can behave differently from the one the app expects: no tray integration, a different environment, an older version still on disk.

Check for a duplicate launcher first. Get-CimInstance Win32_Process -Filter "name='ollama.exe'" | Select ProcessId, CommandLine shows every instance and how it was started. If you see more than one, or one whose command line isn't the plain app child, that's your answer.

Trap 2: HTTP_PROXY is intercepting localhost

This one is sneakier because the server may actually be running fine, and the app still can't reach it.

If you run a local proxy or VPN client (Clash, Karing, v2ray, whatever), it probably sets HTTP_PROXY as a system or user environment variable. Ollama's own FAQ is blunt about this: avoid setting HTTP_PROXY, it may interrupt client connections to the server. Ollama uses HTTPS for model pulls, not HTTP, so the variable does nothing useful for Ollama and only causes trouble.

The trouble: the app's health check hits 127.0.0.1:11434, the proxy env var routes that localhost connection through the proxy, and the proxy either drops it or can't reach back to your own machine, so the readiness check loops forever. You get "server not ready" while the server is literally up.

The fix is to tell anything proxy-aware to leave loopback alone:

[Environment]::SetEnvironmentVariable("NO_PROXY", "127.0.0.1,localhost", "User")
[Environment]::SetEnvironmentVariable("no_proxy", "127.0.0.1,localhost", "User")

And if you don't actually need the HTTP proxy for anything, just delete the variable instead of working around it.

The checklist

If Ollama Desktop keeps saying the server isn't ready, work through these in order:

1. Kill everything. taskkill /F /IM ollama.exe in an admin shell, twice if it complains. Also check the tray for a lingering Ollama icon and quit it there.
2. Find the other launcher. Look in shell:startup, Task Scheduler, and any .vbs or batch files you ever created for Ollama. Remove or disable the one that starts ollama serve on login. The desktop app manages its own server; it doesn't want a roommate.
3. Check the proxy env vars. [Environment]::GetEnvironmentVariable("HTTP_PROXY", "User") and the System scope too. If something's there and you don't need it, remove it. If you do need it, set NO_PROXY to 127.0.0.1,localhost in the same scope, then sign out and back in (or reboot) so every process picks it up.
4. Make sure nothing else owns 11434. netstat -ano | findstr :11434 and match the PID to the process. If something non-Ollama has it, that's a different fight.
5. Relaunch the app and watch the logs. %LOCALAPPDATA%\Ollama\app.log and server.log. If server.log still stays empty while the app loops "not ready," the child is dying before it can log, which points back at the spawn environment: duplicate process or proxy vars.

Why this bites everyone eventually

Any desktop app that spawns a local server and then health-checks it over localhost has these two failure modes, and they're silent by design. A child process that exits immediately writes nothing. A readiness check that goes through a proxy fails without an error you can see. Ollama just happens to be the app millions of people run, so it's where the pattern shows up.

If the checklist above doesn't get you there, the issue is still open at ollama/ollama#18061, and there's a maintainer actively reproducing it. Worth adding your logs there rather than fighting it alone.

Same rules apply if you ever see this pattern with any other tool that bundles a local server, by the way. Localhost traffic should never go through a proxy, and a server process should only ever be started once.