Ollama Ports, OLLAMA_HOST and 11434, Explained on a Real Machine

Ollama listens on port 11434 by default, on the loopback address only, and almost every "cannot connect" question on the site comes down to one of three things: which program owns that port, what OLLAMA_HOST means on the client versus the server, and what happens when you bind to the network. This post runs all of it on Ollama 0.40.3 on Windows 11, with a WSL install on the same PC for the part everyone trips over, and quotes what the commands printed.

Who owns 11434

On a Windows PC with the desktop app installed, the listener on 11434 is ollama.exe serve, a child of the tray app ollama app.exe, and it binds the loopback address only:

  TCP    127.0.0.1:11434        0.0.0.0:0              LISTENING       12676

Loopback only means that nothing outside this machine can reach it, which is the right default for a server with no authentication. It also means that another operating system on the same PC, such as a WSL distribution, is "outside" for this purpose, which is the last section of this post.

OLLAMA_HOST means two different things

Set in the shell that runs ollama serve, OLLAMA_HOST is the address the server binds. Set in the shell that runs ollama list or ollama run, it is the address the client connects to. Same variable, two jobs, and most confusion comes from setting it for one and expecting the other. On the client side it is forgiving: http://localhost:11434, localhost:11434, localhost, :11434 and even 0.0.0.0 all reached the local server and listed the same five models.

When nothing listens on the address, the Windows CLI does not say "could not connect". It starts the desktop app, which notices the instance that is already running and exits, and the CLI then gives up:

Error: timed out waiting for server to start

That took about five seconds and left the tray app untouched. On Linux and WSL the same situation prints the message in "could not connect to ollama server". If a .NET client is the one failing, it is the connection refused exception instead.

A second server on another port

Nothing stops you running two servers, as long as each binds its own port. The one started with OLLAMA_HOST set to 127.0.0.1:15600 announced itself in its log, with the setting normalised to a full URL:

msg="Listening on 127.0.0.1:15600 (version 0.40.3)"

Both servers listed the same five models, because both read the same models folder: OLLAMA_MODELS defaults to .ollama\models under the user profile and was not changed. Two servers sharing one folder is fine for reading; the test set OLLAMA_NOPRUNE=1 on the second one so that it would not prune blobs the tray app was using, and the server config line shows that as OLLAMA_NOPRUNE:true. One detail that matters when you capture logs: the server writes its own lines to standard error and the per-request lines, the ones that start with [GIN], to standard output.

A third server pointed at the busy default port never got as far as a config line:

Error: listen tcp 127.0.0.1:11434: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.

The process exited on its own and the tray app kept answering. The Windows and Linux versions of that error have their own posts: Windows and Linux.

Binding to the network: 0.0.0.0

A server started with OLLAMA_HOST set to 0.0.0.0:15601 logged Listening on [::]:15601, and netstat showed two listeners for it, one IPv4 and one IPv6. It answered on 127.0.0.1, on localhost, on [::1], on the PC's LAN address, on a VMware adapter and on the Windows side of the WSL switch. The loopback-only server on 15600, asked on the LAN address, refused:

curl: (7) Failed to connect to ... after 2071 ms: Could not connect to server

Two things to know before you do this on purpose. First, a server on 0.0.0.0 has no authentication: anyone on the network can list your models and run them. Keep 127.0.0.1 and put a reverse proxy with a login in front if the server has to be shared. Second, Windows Firewall gets involved. The second the 0.0.0.0 server started, Windows created two inbound rules named ollama.exe, Block for TCP and UDP on the Public profile, and four seconds later both were changed to Allow, which is the sequence Windows records when its "Windows Security Alert" dialog is answered with "Allow access". Those rules outlive the test. If you clicked Allow once while experimenting, open Windows Security, Firewall, "Allow an app through firewall", and decide whether ollama.exe should stay on that list.

Browser apps: OLLAMA_ORIGINS

A page served from your own site that calls Ollama directly from JavaScript sends an Origin header, and the server checks it. Without OLLAMA_ORIGINS, a request with Origin: http://app.example.test got a bare refusal:

HTTP/1.1 403 Forbidden
Content-Length: 0

The preflight OPTIONS request got the same 403. Two origins are allowed out of the box that the documentation does not mention: http://localhost and http://127.0.0.1 on any port, plus the app://, file://, tauri:// and VS Code webview schemes, so a Vite dev server on localhost:5173 worked without any setting. With OLLAMA_ORIGINS set to http://app.example.test on a fresh server, the same request answered 200 with the matching Access-Control-Allow-Origin header, and the preflight came back as:

HTTP/1.1 204 No Content
Access-Control-Allow-Methods: GET,POST,PUT,PATCH,DELETE,HEAD,OPTIONS
Access-Control-Allow-Origin: http://app.example.test
Access-Control-Max-Age: 43200

The value is added in front of the defaults, not instead of them: localhost:5173 was still allowed and a different origin still got 403. Note that curl never enforces CORS; the 403 is the server's decision based only on the header, which makes curl the right tool to test it.

Windows and WSL on the same port

This PC has two installs: the Windows app (0.40.3) and an older service inside the Ubuntu-24.04 distribution (0.34.2), both configured for 11434. From Windows, localhost:11434 answers {"version":"0.40.3"}: the Windows app wins, because it owns the Windows port. The WSL service binds 127.0.0.1 inside WSL, so from Windows it was not reachable at all, not even on the distribution's own address. From inside WSL, the Windows server bound to 0.0.0.0 was reachable through the gateway address, while the loopback-only tray app timed out after five seconds. So if your .NET app runs in WSL and talks to Ollama on Windows, either bind the Windows server to 0.0.0.0 and point the app at the gateway address, or run Ollama inside WSL and keep everything on one side.

Making it permanent on Windows

The desktop app inherits your user and system environment variables, and the official FAQ gives the procedure: quit Ollama from the taskbar, open the system settings and search for environment variables, choose "Edit environment variables for your account", create or edit OLLAMA_HOST (or OLLAMA_MODELS to move the models folder), save, and start Ollama again from the Start menu. The variable set in one PowerShell window, as in the tests above, dies with that window.

Frequently asked

What port does Ollama use?

11434 on the loopback address 127.0.0.1, so only programs on the same machine can reach it. On Windows the listener is ollama.exe serve, started by the tray app. Change the port or the address with the OLLAMA_HOST environment variable in the environment of the server process, for example 127.0.0.1:15600 or 0.0.0.0:11434 to listen on every network interface.

How do I change the Ollama host or port?

Set OLLAMA_HOST before starting the server: in the shell for a one-off test, or as a user environment variable on Windows after quitting the tray app so it applies to the desktop app. The same variable, set in the shell that runs the ollama command, tells the client which server to talk to. Each server needs its own port; a second one on a busy port fails with the bind error.

How do I allow a web page to call Ollama?

Set OLLAMA_ORIGINS to the page's origin, for example http://app.example.test, in the server's environment. Requests from other origins get a 403 with an empty body. Local development origins such as http://localhost:5173 and http://127.0.0.1 are allowed by default, and the value you set is added to those defaults rather than replacing them.

The errors this post walks around have their own pages in the Fixes category, and the series From Prompt to Private builds a whole clinic assistant on a local model.