Mistral API Connection Reset (ECONNRESET): Which Plane Actually Closed the Socket (2026)

Mistral is unusual among AI providers in that the same client code, the same model names and the same request body run against three completely different deployments: La Plateforme, a cloud marketplace endpoint, and self-hosted weights behind vLLM. Every other error class at least tells you something about the server. A connection reset does not.

That matters because the fix is entirely plane-dependent. On La Plateforme a reset is usually a stale pooled socket. On a marketplace endpoint it is usually the cloud provider’s gateway, not Mistral. On self-hosted vLLM it is almost always your own reverse proxy or the server process dying — and it will never appear on any status page, because no shared infrastructure was involved.

60-second triage: confirm which base URL you are actually hitting. Print the resolved base URL at request time rather than trusting the config file, then run the same call with curl on a fresh connection. If curl succeeds and only your app fails, the socket pool is the cause. If curl fails against La Plateforme too, check live Mistral status and the error code reference instead.

Three planes, three different resets

The single most common waste of time here is debugging the wrong deployment. Teams move a workload from La Plateforme to a self-hosted vLLM instance for cost reasons, keep the same client wrapper, and then read the resulting resets as a Mistral incident. The request shape is identical, so nothing in the error hints that the traffic never left the VPC.

On La Plateforme, resets follow the classic keep-alive pattern: the socket sat idle past the edge’s threshold, your pool handed it out anyway, and the RST came back on write. It clusters after quiet periods and after serverless warm starts, and it reproduces on no fresh connection.

On a cloud marketplace endpoint the reset is usually enforced by the cloud provider’s gateway rather than by Mistral — the model is Mistral’s, the socket is not. These resets track the gateway’s own idle and duration limits, and they will never correlate with anything published on Mistral’s status page.

On self-hosted vLLM the two dominant causes are a reverse-proxy keep-alive shorter than your client’s, and the server process being killed by the OOM reaper mid-request under KV-cache pressure. The second one is severe and easy to miss: to the client it is a plain reset, and the evidence is only in the host’s kernel log.

Symptom	What it means	Where to fix it
`ECONNRESET` within milliseconds of the write	A pooled socket the server had already closed	Your HTTP client's connection pool
`EPIPE` / broken pipe while sending	The peer refused the request mid-upload	Request body size, or an intermediary's limit
Reset seconds in, after a clean handshake	Accepted, then something downstream gave up	Proxy idle timers, routing, cold starts
Reset on fresh connections, from every network	A genuine provider-side problem	Failover — nothing local will help

📡

Recommended

Prove Which Side Closed the Socket

External checks running against your AI endpoints answer the only question that matters mid-incident: was the provider still accepting connections while your app was failing?

Try Better Stack Free →

The self-hosted default that causes most of these

If you are running vLLM behind uvicorn, nginx or an ingress controller, the default keep-alive timeouts in that chain are short — often five seconds — while most HTTP clients happily hold a connection for far longer. That mismatch guarantees resets under any bursty workload, and it is invisible in testing because a tight benchmark loop never leaves a socket idle long enough to trip it.

The rule is the same one that applies to every proxy: the client’s idle timeout must be strictly shorter than the shortest server-side keep-alive anywhere in the path. Raise the server side, lower the client side, and make sure you know which intermediary owns the smallest value.

If the resets track concurrency rather than idle time, suspect memory instead. A vLLM worker terminated while serving cannot send a graceful response, so every in-flight request on that worker resets at once — a spike of simultaneous ECONNRESETs across unrelated callers is the fingerprint.

Pin down the plane, then tune the right layer

Instrument first. A reset that carries no server identity is worth very little; a reset tagged with the base URL, whether the socket was reused, and how long it had been idle is usually self-diagnosing.

// Log the plane and the socket age on every failure — this is the diagnosis.
import { Agent, setGlobalDispatcher } from 'undici';

const BASE = process.env.MISTRAL_BASE_URL ?? 'https://api.mistral.ai/v1';

setGlobalDispatcher(new Agent({
  keepAliveTimeout: 4_000,   // must be BELOW the smallest server-side keep-alive
  keepAliveMaxTimeout: 10_000,
}));

export async function callMistral(body: unknown) {
  const started = Date.now();
  try {
    return await fetch(`${BASE}/chat/completions`, {
      method: 'POST',
      headers: { Authorization: `Bearer ${process.env.MISTRAL_API_KEY}`, 'Content-Type': 'application/json' },
      body: JSON.stringify(body),
    });
  } catch (err) {
    console.error('mistral_conn_error', { base: BASE, ms: Date.now() - started, cause: String((err as Error).cause ?? err) });
    throw err;
  }
}

Then handle the failure itself. The rule that keeps retries honest is the same everywhere: retry only when nothing was read back, cap the attempts, and always add jitter — a reset that hits many sockets at once will otherwise synchronise every client into a single reconnect wave that re-fails together.

# Self-hosted vLLM: make the server outlast the client, not the other way round.
# uvicorn default keep-alive is 5s — far below most client pools.
vllm serve mistralai/Mistral-Small-Instruct \
  --host 0.0.0.0 --port 8000 \
  --timeout-keep-alive 75

# nginx in front of it must agree:
#   keepalive_timeout 75s;
#   proxy_read_timeout 300s;
# And check for the other cause after any reset spike:
dmesg -T | grep -i 'killed process'   # OOM reaper took a worker mid-request

What a reset rules out

Because no HTTP response was produced, a connection reset rules out an entire category of causes that teams check first. It is not a rate limit — a 429 requires a response. It is not an authentication problem, not a malformed body, and not a context-window overflow, because all of those return a status code and a JSON error.

It also tells you nothing about your quota or your billing state. If resets started at the same time as a plan change, the correlation is almost certainly coincidental; look for a deployment or an infrastructure change in the same window instead.

The one thing it does establish is that the failure lives at or below the transport layer, which narrows the search to exactly three things: your client’s connection pool, an intermediary between you and the server, or the server process itself.

Frequently Asked Questions

What causes ECONNRESET when calling the Mistral API?

A connection reset means the far end sent a TCP RST and tore the socket down before any HTTP response existed. On La Plateforme the usual cause is a keep-alive connection your client pooled after the server had closed it, so the reset arrives the moment you write a request onto a dead socket. On self-hosted vLLM the usual cause is a reverse proxy with a shorter keep-alive than your client, or the server process being killed mid-request. Because Mistral runs on three planes with identical request shapes, the first step is always establishing which base URL the failing traffic actually used.

Why does the same code get resets on self-hosted Mistral but not on La Plateforme?

Because you inherited a different set of timeouts. Self-hosted vLLM typically sits behind uvicorn or nginx with default keep-alive values around five seconds, while La Plateforme’s edge is tuned for internet clients and holds connections much longer. The client pool that was comfortably inside La Plateforme’s window is far outside your own proxy’s, so every quiet period leaves stale sockets. Raise the server side with vLLM’s timeout-keep-alive flag and matching nginx keepalive_timeout, and lower your client’s idle timeout below whichever value is smallest.

Do Mistral connection resets show up on the status page?

Usually not, and that is diagnostic rather than a gap in reporting. A status page covers shared La Plateforme infrastructure. If your traffic goes to a cloud marketplace endpoint, the socket is terminated by that cloud’s gateway and Mistral never sees it. If it goes to self-hosted weights, nothing left your own network. Only resets against api.mistral.ai on fresh connections, reproducing from multiple networks at once, are candidates for a real incident — and even then a genuine Mistral fault more often presents as 5xx responses than as silence.

Is it safe to retry a Mistral request that was reset?

Retry when nothing was read back, which covers the great majority of these. A reset on a stale pooled socket happens before the server processes the request, so a retry on a fresh connection duplicates no work and is billed once. A reset partway through a streamed response is different: tokens were generated and charged, so resume from what you received rather than reissuing the whole prompt. Cap at two or three attempts with jittered backoff, because a proxy-wide reap resets many sockets at the same instant and un-jittered clients will reconnect in a single synchronised wave.

How do I tell a connection reset apart from a timeout on Mistral?

By whether anything happened. A timeout means the connection stayed open and no response arrived within your budget, so the elapsed time equals your configured limit almost exactly — a suspiciously round number. A reset means the connection was actively destroyed, and it typically fails fast, often within milliseconds of the write, with no relationship to your timeout value at all. That timing difference is the cleanest way to separate them in logs: cluster your failures by duration, and resets sit near zero while timeouts pile up on the deadline.

Related Mistral Guides

Stop Guessing Whether It Is Mistral or You

API Status Check probes Mistral’s public endpoint from outside your network on a fixed schedule, with connection timing on every check — so you can separate “La Plateforme refused the connection” from “our own proxy did” without waiting for the next incident.

Start Your Free Trial →

Mistral API Connection Reset: Find Out Which Plane Dropped It