Ollama Troubleshooting: Connection, GPU, Model and Port Checks

Updated 26 October 2026 · Sources & corrections

Start by identifying which part failed: the local server, model download, model loading, or the application connecting to Ollama. Changing all four at once makes a fault harder to isolate. The checks below separate those cases before you restart or remove anything.

1. Record the version and check the local server

ollama --version
ollama list
ollama ps

On Windows PowerShell, query the local model-list endpoint:

$result = Invoke-RestMethod -Uri 'http://127.0.0.1:11434/api/tags'
$result.models | Select-Object name, size

On macOS or Linux, use:

curl --fail --show-error http://127.0.0.1:11434/api/tags

An HTTP 200 response containing a models array establishes that this endpoint is reachable. An empty array can simply mean no models are installed. Connection refused points to the listening address or server process; it is not evidence that a model must be deleted.

2. Start the correct service, then read its logs

For the Windows or macOS desktop installation, open the Ollama application. For a Linux installation managed by systemd, inspect the service and recent logs:

systemctl status ollama --no-pager
journalctl -u ollama -n 50 --no-pager

If that service is stopped, start it with sudo systemctl start ollama. A container or manually started process has a different lifecycle. Do not run a second daemon until you know whether the expected instance is already listening.

The official troubleshooting reference below documents log locations. On Windows, inspect %LOCALAPPDATA%\Ollama\server.log; for the macOS app, inspect ~/.ollama/logs/server.log. Share only the relevant lines after removing private paths, prompts and credentials.

3. A port conflict needs process identification

Use this PowerShell check to identify the listening PID without terminating it:

Get-NetTCPConnection -LocalPort 11434 -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess

Check that PID in Task Manager or with Get-Process -Id <PID>. A running Ollama server may be the expected owner. Restart only the instance you identified, using its application or service controls.

If the server responds but your client cannot find its model, follow the model-not-found diagnostic checks for tags, server addresses and API paths.

4. Separate installed models from loaded models

ollama list lists installed models. ollama ps lists models currently loaded for inference. Copy the exact installed tag when testing. A model can be installed successfully while no model is currently loaded.

ollama run llama3.2:3b
ollama ps

The run command is an example and may download weights if that tag is absent. Check disk capacity and the model card first. A successful response proves that request worked; it does not establish a benchmark or guarantee GPU use.

5. Check GPU use during an active request

Run ollama ps while a generation is active. Its processor information distinguishes CPU, GPU and partial offload. For a different view, query /api/ps. An empty list after the model unloads is normal. If a compatible GPU is unused, inspect the logs and the vendor support requirements before changing drivers or environment overrides.

For memory pressure, lower the configured context or select a smaller supported model. Deleting disk files does not increase physical GPU memory. CPU offload is possible; its performance depends on the model, workload and hardware.

6. Frontend and container connections

Test the endpoint from the same environment that hosts the frontend. Inside a container, 127.0.0.1 refers to that container. Correct host routing and binding before changing browser CORS settings. Keep Ollama bound locally unless a trusted network setup explicitly requires otherwise.

If a browser directly calls a different origin, allow the specific frontend origin using the documented configuration. A server-to-server connection does not become a browser CORS problem. Do not use a wildcard origin as the first troubleshooting step.

How to interpret a diagnostic response

{"models": []}

Illustrative response only: the JSON above shows the shape of an empty installed-model list, not a captured test result. Actual responses depend on your installed version and models. Before reporting a fault, save the version, exact command, response or status code, relevant logs, and whether the same request succeeds from another client.

Related guides: model storage and environment settings, removing a model, and Windows installation.

7. Ollama 503: identify the overloaded component

Short answer: if a local Ollama model returns 503 under a burst of requests, first reduce simultaneous work and inspect the matching server logs. Increasing the waiting queue does not create inference capacity. Confirm which component returned the response before changing server settings.

This diagnostic applies to the native REST API on a server you administer. A frontend, reverse proxy or remote model provider can also be part of the request path. Record the full destination, selected model, HTTP status, response body, timestamp and number of active requests. Remove credentials and private prompts before sharing that record.

The official Ollama FAQ documents a 503 response when excessive incoming work overloads the server. That explains one local failure mode; a status code alone does not identify the source of every failure.

Capture one response without a retry loop

First use the version, installed-model and running-model checks above. A successful /api/tags response proves that endpoint responds; it does not prove a generation request has capacity. Select an already installed, local chat-capable model and save the following as request.json, replacing the placeholder with its exact tag:

{
  "model": "REPLACE_WITH_INSTALLED_LOCAL_TAG",
  "messages": [{"role": "user", "content": "Reply with one short greeting."}],
  "stream": false
}

On macOS/Linux use this single-line command. On Windows PowerShell use curl.exe in place of curl so the command calls the curl executable:

curl --include --show-error --max-time 60 -H "Content-Type: application/json" --data-binary "@request.json" http://127.0.0.1:11434/api/chat

This optional command performs inference and may load a model. It has no retry flag and leaves HTTP error bodies visible. The 60-second client limit is a diagnostic choice, not a recommended server timeout; a slow model can exceed it. Do not interpret a client timeout as proof that server-side work stopped. These are documentation-based examples, not recorded successful model runs. See the native chat request reference.

Queue length, parallelism and retries solve different problems

Use OLLAMA_MAX_QUEUE to control how much work may wait, OLLAMA_NUM_PARALLEL to control per-model parallel processing, and OLLAMA_MAX_LOADED_MODELS to limit simultaneous model residency. Parallel work consumes additional context memory; loaded models also need sufficient memory. Consult the current concurrency documentation for your installation rather than copying old default values.

Start by capping requests at the application that produces them. A larger queue can increase waiting time without making the model faster. Change one setting at a time, through the environment of the actual Ollama service or application, then compare failures and completion times under the same workload. Preserve the previous configuration for rollback. Review our context-length guide and model keep-alive guide when memory residency is involved.

If your application retries a transient failure, use a bounded attempt count, a total deadline and spaced delays with jitter. Check whether the SDK, proxy and application each retry independently: stacked retries can multiply traffic. Do not automatically repeat actions performed by external tools without duplicate protection. Stop retrying an unchanged persistent failure and preserve the diagnostic evidence.

A streaming HTTP 200 can still contain an error

Check the complete response, not only the status line. The official error reference explains that an error after streaming starts is carried in an NDJSON object with an error property; the already-sent HTTP status cannot change. A client must inspect those objects. Use our streaming response guide for parsing and completion checks.

Next step: reproduce once with a known local model and no competing producer, retain the status and relevant log lines, then choose the corresponding branch in the table. Do not expose an unauthenticated local server publicly to work around an overload or connectivity problem.

Editorial update, 26 October 2026: added the 503 diagnostic and streaming-error distinction using current official documentation. No live overload benchmark or hardware test was performed. The original publication date is retained.