Ollama 500 Internal Server Error: Find the Cause

Ollama always attaches the real error to a 500 — it is in the JSON body as {"error": "..."}. If you are staring at a bare "500 Internal Server Error" with no detail, your client discarded that body. Re-issue the same request with curl and read the response, and in most cases you will have your actual error in one command. If the body really is empty, the message is in the server log: ~/.ollama/logs/server.log on macOS, journalctl -u ollama on Linux, %LOCALAPPDATA%\Ollama\server.log on Windows. The 500 itself is never the diagnosis — it is the default: branch of handleScheduleError, meaning Ollama could not classify what went wrong.

That last point is the one that reframes this whole error. Ollama maps everything it recognises to a specific status code — a missing model is a 404, an unsupported capability is a 400, a full queue is a 503. A 500 is what is left over. So there is no such thing as "the fix for a 500"; there is a fix for whatever text came with it, and this page is a router that takes that text and points you at it.

If you have not managed to get any response at all, you are in a different situation: a connection that is refused rather than a request that failed. Start with Ollama connection refused on port 11434 instead.

Everything below was read from ollama/ollama on main (current release v0.32.15, 19 August 2026), from the official troubleshooting docs, or quoted from the linked issue where a user pasted it.

Why does a 500 arrive with no error message?

Because the message lives in the response body, and a lot of client code only keeps the status line. Ollama's own error path always writes the text:

func handleScheduleError(c *gin.Context, name string, err error) {
	switch {
	case errors.Is(err, errCapabilities), errors.Is(err, errRequired):
		c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
	case errors.Is(err, context.Canceled):
		c.JSON(499, gin.H{"error": "request canceled"})
	case errors.Is(err, ErrMaxQueue):
		c.JSON(http.StatusServiceUnavailable, gin.H{"error": err.Error()})
	case errors.Is(err, os.ErrNotExist):
		c.JSON(http.StatusNotFound, gin.H{"error": fmt.Sprintf("model %q not found, try pulling it first", name)})
	default:
		c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
	}
}

Read that switch as a definition. A 500 from Ollama means: this failure did not match any of the categories above. Note also that every branch carries err.Error() or an explicit sentence — there is no path here that returns a status with an empty body.

The reason the CLI shows you detail and your SDK does not is in api/client.go. The streaming path (/api/generate and /api/chat, which is what ollama run uses) builds the error like this:

} else if response.StatusCode >= http.StatusBadRequest {
	return StatusError{
		StatusCode:   response.StatusCode,
		Status:       response.Status,
		ErrorMessage: errorResponse.Error,
	}
}

and StatusError.Error() in api/types.go formats it as "%s: %s" — status, then message. That is where Error: 500 Internal Server Error: model requires 20.4 GiB but only 11.3 GiB are available comes from, verbatim, in issue #17246.

Three things break that chain, and between them they cover nearly every "I just get a 500" report:

1. The client only reads the status. This is the default shape of a lot of HTTP error handling — raise on a non-2xx status, never touch the body — and it is what you get from a bare response.raise_for_status(), an unguarded fetch wrapper, or any UI that surfaces err.message from a library that only recorded the status line. The server told you; nobody was listening. We are not going to name which of Open WebUI, n8n or LangChain does this in the version you have, because it varies by version and by which endpoint you hit — the test below settles it for your setup in one command.
2. The body was consumed already. A streaming client that starts reading the response and then hits an error can end up raising on the status with the body half-read.
3. A proxy replaced the response. If nginx, Cloudflare or a gateway sits in front of Ollama and returns its own 500 page, the body is HTML, not Ollama's JSON — and nothing in it is about your model.

There is one more clue worth recognising. StatusError.Error() has a fallback for when both fields are empty:

default:
	// this should not happen
	return "something went wrong, please see the ollama server logs for details"

If you see that exact sentence, it is not a generic apology — it is a specific state, meaning the error object arrived with neither a status string nor a message. Go to the log.

How do I get the real error out of a 500?

Reproduce the same request with curl and print the body. This is not a workaround; it is the shortest path to the message your client dropped.

curl -i http://localhost:11434/api/chat -d '{
  "model": "llama3.2:3b",
  "messages": [{"role": "user", "content": "hi"}],
  "stream": false
}'

-i prints the status line and headers so you can confirm the 500 is Ollama's and not a proxy's. What you are looking for is a JSON body shaped like this — the format from issue #17822, where a user ran exactly this kind of curl against /api/embed:

{"error":"tokenize error: {\"error\":{\"message\":\"Invalid API Key\",\"type\":\"authentication_error\",\"code\":401}}"}

Two useful reads of that single line. The message is there, which is the point. And it is a nested error — Ollama's tokenize error: prefix wrapping something else's JSON — which is the shape you will see whenever the real failure happened a layer below.

Three practical notes on reproducing:

• Use "stream": false. A streaming request can deliver an error as one of the newline-delimited JSON objects, which is harder to read in a terminal.
• Point curl at the same host and port your app uses. If your app talks to http://ollama:11434 inside Docker and you curl localhost, you may be testing a different server.
• If curl succeeds and your app still 500s, the difference is in the request, not the server. Diff the payloads — an unsupported parameter, a malformed message array, or a tool definition your model cannot accept. Our Ollama Python API guide documents the field shapes each endpoint expects.

Where is the Ollama server log?

Per the official troubleshooting docs, quoted:

Two Windows details from the same page that save time: explorer %LOCALAPPDATA%\Programs\Ollama browses the binaries, and explorer %TEMP% holds the temporary executables in one or more ollama* directories — relevant when the failure is a missing or blocked llama-server.

The line you want is almost never the last one. When a model fails to load, the runner's own stderr is captured into the server log, so scroll up past the Go-formatted level=INFO lines until you find the C++ output — llama_model_load, ggml_, CUDA error, or a stack trace. That block is the actual failure; the 500 is the receipt.

Turning on debug logging

If the default log is not specific enough, set OLLAMA_DEBUG=1 on the server process — not in the shell where you run your client. The docs give the Windows procedure as: quit the running app from the tray menu, then in PowerShell

$env:OLLAMA_DEBUG="1"
& "ollama app.exe"

On Linux with the official installer, the same rule that governs proxies and OLLAMA_MODELS applies — it has to go in the systemd unit (sudo systemctl edit ollama.service, add Environment="OLLAMA_DEBUG=1" under [Service], then systemctl daemon-reload && systemctl restart ollama). A shell export never reaches a daemon someone else started. On macOS, launchctl setenv OLLAMA_DEBUG 1 then restart the app.

Which log line means what: the router

Find the most specific string in your log or response body, then follow the row. The strings in the left column are real — each is quoted from the linked issue or from Ollama's source, not paraphrased.

That table is the page. If your string is not in it, the general rule still applies: read the line above the 500 in the server log, because Ollama's 500 is a wrapper and the thing it wraps is what broke.

How the wrapping works

Issue #16547 shows the full chain in one line, which is worth studying because it is how most of these are shaped:

Error: 500 Internal Server Error: llama-server process has terminated: exit status 1: error loading model: unknown model architecture: 'mllama'

Read that right to left. The root cause is unknown model architecture: 'mllama'. That caused the model load to fail, which made llama-server exit with status 1, which Ollama reported as a terminated runner, which had no classification in handleScheduleError and therefore became a 500. Four layers, one cause, and only the rightmost fragment is actionable.

That specific case has since been given a better message. Current main returns, when a model's families contain mllama and it has projector paths:

'llama3.2-vision' is no longer compatible with your version of Ollama and has been replaced by a newer version. To re-download, run 'ollama pull llama3.2-vision'

Which is the general lesson for the unknown model architecture row: before investigating anything, check your Ollama version against the model's release date. A model published after your build usually cannot be loaded by it, and there is nothing to configure — see the Ollama version history for what shipped when.

What does "unmarshal: invalid character" mean?

It means a JSON decoder was handed something that was not JSON, and the character it names is the first byte of what it got. Issue #13048 is titled with the exact string — Error 500 Internal Server Error: unmarshal: invalid character 'I' looking for beginning of value. — reported from a GUI client on macOS, with no other detail available.

The named character is the whole clue:

The first three all say the same thing: your client is not talking to Ollama. Check the base URL, check whether a reverse proxy is in the path, and confirm with curl -i that the response actually carries Content-Type: application/json.

The '\x00' case is different and worth separating out, because it is the failure that #17537 describes: a blob "a stalled write or disk error left corrupted at the right size" passes Ollama's cache-hit check forever, so pull keeps reporting success and list keeps showing the model as healthy, and "only run failed, with an error (invalid character '\x00' looking for beginning of value) that didn't identify the blob or the corruption." If that is your string, the model store is damaged and the repair is on our digest mismatch page.

Which 500s are not about your model at all?

Two live examples, both worth recognising because the error text points somewhere misleading.

An authentication error on a purely local setup. In issue #17822 (Windows 10, Ollama 0.32.14, installed via winget) both /api/embed and /api/generate returned 500 Internal Server Error: tokenize error: {"error":{"message":"Invalid API Key","type":"authentication_error","code":401}} with, in the reporter's words, "no Ollama Cloud sign-in, no OLLAMA_API_KEY set, and no reverse proxy in front of Ollama." They ruled out the model (three unrelated ones), the client (raw curl), and the credential file. The detail that makes it diagnosable: the error body format does not match llama-server's native plain-text Unauthorized: Invalid API Key, so the JSON is coming from somewhere else in the request path and being wrapped by Ollama's tokenize error: prefix. If you get an auth error you did not configure, the question is which hop introduced it, not which model you asked for.

A malformed request that reads like a server fault. 500 Internal Server Error: no user query found in messages (issue #17812) is the server rejecting the shape of the payload. Anything phrased as a statement about your request — a missing field, an empty array, an unexpected role — is a client bug that happened to land in the unclassified bucket and get a 500 instead of a 400.

Is the 500 really a capacity problem?

Ollama has explicit statuses for the two capacity failures, so if you are getting a 500 you are probably not hitting them — but the confusion is common enough to be worth stating.

• A full request queue is a 503, from ErrMaxQueue. The queue is 512 deep by default (OLLAMA_MAX_QUEUE).
• A client that gave up is a 499 with the body {"error": "request canceled"}. This is your timeout, not the server's. First loads of a large model can take minutes, and many HTTP clients default to 30 or 60 seconds.

A genuine memory refusal, by contrast, does land in the 500 bucket — model requires X GiB but only Y GiB are available (after Z MiB overhead) is a real message with real arithmetic in it, and the two numbers tell you exactly how much short you are. Check the model's requirements against your machine in the Ollama model RAM and VRAM table before changing any settings; on a shared GPU the answer is often just that something else is holding VRAM.

Honest limitations

• A 500 is a symptom, not a cause, and this page cannot change that. It is a router. If your error text is not in the table, the page has done its job only if it got you to the server log with a clear idea of what to look for.
• Nothing here was reproduced on our own machines. The Go excerpts are from ollama/ollama on main; the log locations are quoted from the official troubleshooting docs; every error string is from the linked issue where a user pasted it. There are no benchmarks on this page because none were run.
• Status-code behaviour is version-specific. handleScheduleError is accurate for main at v0.32.15 (19 August 2026). Older builds classify fewer failures, so an error that returns 400 or 404 today may well have been a 500 on the version you are running.
• Third-party clients change the picture. Open WebUI, n8n, LangChain and the OpenAI-compatible endpoints each re-wrap errors in their own way, and some map every failure to 500 regardless of what Ollama returned. When a status looks wrong, trust curl -i over the UI.
• We deliberately do not list "restart Ollama" as a fix. It resolves a stuck runner sometimes and destroys the evidence every time. Copy the log first.

FAQ

Why does Ollama return a 500 with no error message?

It does not — Ollama attaches {"error": "..."} to every 500 it returns, because every branch of handleScheduleError writes the error text into the JSON. The missing detail is almost always the client discarding the response body and raising on the status alone. Re-run the same request with curl -i and the message will be in the body.

Where are the Ollama server logs?

Per the official troubleshooting docs: ~/.ollama/logs/server.log on macOS, journalctl -u ollama --no-pager --follow --pager-end on Linux with systemd, docker logs <container-name> in a container, %LOCALAPPDATA%\Ollama\server.log on Windows (with older logs rotated to server-#.log), and the terminal itself if you started it with ollama serve.

What does "500 Internal Server Error: llama runner process has terminated" mean?

The subprocess that runs the model exited. The 500 is a wrapper; the exit code that follows it, and the runner's own stderr in the server log just above it, are the real diagnosis. Exit codes are covered in our guide to llama runner process has terminated.

What causes "unmarshal: invalid character 'I' looking for beginning of value"?

A JSON parser received text that was not JSON, starting with the letter I — almost always the beginning of a proxy's plain-text Internal Server Error page. It means your client is not reaching Ollama. A leading < means the same thing with an HTML page; a leading null byte means a corrupt file rather than a network problem.

Is a 500 in Ollama ever a hardware problem?

Sometimes, but it says so. CUDA error: out of memory with a ggml-cuda.cu backtrace is a GPU allocation failure, and model requires X GiB but only Y GiB are available is a pre-launch sizing refusal that names both numbers. A 500 with no such text in the log is not evidence of a hardware fault.

Does restarting Ollama fix a 500?

It can clear a wedged runner, and it always destroys the log context you need to find out why the runner wedged. Copy the relevant log block first, then restart. If the same 500 returns, restarting was never the fix.

Why do I get a 500 from my app but the CLI works fine?

Because ollama run and your app are sending different requests. The CLI uses the streaming chat endpoint with a minimal payload; an SDK or UI may add tool definitions, a system message, an options block or a context length the model cannot honour. Reproduce the app's exact payload with curl and remove fields until it succeeds.

What is the difference between a 500, a 503 and a 499 from Ollama?

They come from different branches of the same switch. A 503 means the request queue is full (512 deep by default). A 499 means the client disconnected before the response — that is a timeout on your side. A 500 is the fallback for anything Ollama could not classify, which is why it always carries the underlying error text.

Sources

• ollama/ollama — server/routes.go (handleScheduleError and its status mapping, the llama3.2-vision replacement message)
• ollama/ollama — api/client.go (checkError, the streaming error path)
• ollama/ollama — api/types.go (StatusError.Error() and its fallback sentence)
• ollama/ollama — server/images.go (CheckCapabilities, the does not support error family)
• Ollama troubleshooting docs (log locations per platform, OLLAMA_DEBUG)
• Issues: #13048 (unmarshal: invalid character), #16547 (unknown model architecture), #16555 (llama-server binary not found), #17089 (CUDA out of memory backtrace), #17246 (model requires X GiB), #17537 (corrupt blob, \x00), #17812 (no user query found), #17822 (tokenize error: Invalid API Key)