Perplexity API Connection Reset (ECONNRESET): Why Proxies Kill It Mid-Retrieval (2026)

Perplexity’s Sonar models do something no plain completion endpoint does: before generating a single token they run a live web search, fetch documents and rank them. From the socket’s point of view that whole phase is dead air — the connection is open, both ends are healthy, and nothing is being transmitted.

Idle-sensitive infrastructure reads dead air as a dead connection. Proxies, load balancers, service meshes and serverless runtimes all keep an idle read timer that fires on bytes, not on elapsed request time, and when it fires many of them send a TCP RST rather than a clean 504. That is the mechanism behind most Perplexity connection resets, and it is why the same client code that is rock solid against a plain chat endpoint falls over here.

60-second triage: compare a search-heavy prompt against a trivial one on the same connection. Ask Perplexity something that needs no retrieval and something that needs a broad current-events search. If only the search-heavy prompt resets, the retrieval window is the cause and the fix is streaming plus an idle-timer change — not a retry loop. If both fail on fresh connections, check live Perplexity status and the error code reference instead.

Why the reset tracks the prompt, not the clock

The most useful diagnostic on this page is that Perplexity connection failures cluster by prompt shape rather than by time of day. A prompt that triggers a broad search across many sources spends far longer in retrieval than one answerable from a narrow lookup, and the length of that silent window is what decides whether an intermediary’s idle timer fires.

That produces a signature no other provider has: two users hitting the same deployment in the same second, one succeeding and one resetting, with the difference being how hard their question was to research. Because it is not correlated with load or with the clock, it survives every capacity-based explanation you try on it — and it will not appear on a status page, because Perplexity did nothing wrong.

It also means backoff is the wrong remedy. Retrying an expensive query after a delay just runs the same expensive retrieval again into the same idle timer. If the resets track query breadth, narrowing the query or constraining the search domain fixes more than any amount of retry tuning.

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 →

Streaming is the actual fix

Turning on streaming does not make Perplexity faster, but it changes the shape of the traffic in exactly the way idle timers care about. With a streamed response the connection starts producing bytes as soon as generation begins, which resets every idle timer in the chain and keeps proxies from concluding the socket is dead.

It also converts total failures into partial ones. A buffered request that gets reset at second twenty-five returns nothing, and you have paid for the retrieval work regardless. A stream that breaks after several hundred tokens has already delivered a usable answer and gives you a resumption point.

With streaming enabled, replace any single overall deadline with an idle deadline that resets on each chunk. A response that produced a token two seconds ago is healthy no matter how long the request has been running; one that has produced nothing for ninety seconds is genuinely stuck. Just be aware that the first chunk still arrives only after retrieval finishes, so the idle budget covering that initial window has to be generous.

Raise the idle budget for the retrieval window, then stream

Two changes, in this order: give the silent phase enough room in every layer you control, and then make sure there is barely any silent phase left.

// Streaming + an idle timer that resets on every chunk (not one overall deadline).
const res = await fetch('https://api.perplexity.ai/chat/completions', {
  method: 'POST',
  headers: { Authorization: `Bearer ${process.env.PERPLEXITY_API_KEY}`, 'Content-Type': 'application/json' },
  body: JSON.stringify({ model: 'sonar-pro', stream: true, messages }),
});

const reader = res.body!.getReader();
// Generous first window: retrieval runs before ANY byte is emitted.
let idle = setTimeout(() => reader.cancel('stalled'), 90_000);

for (;;) {
  const { done, value } = await reader.read();
  if (done) break;
  clearTimeout(idle);
  idle = setTimeout(() => reader.cancel('stalled'), 30_000);  // shorter once flowing
  yield value;
}
clearTimeout(idle);

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.

# Every intermediary you own needs to tolerate the silent retrieval window.
# nginx — the default 60s proxy_read_timeout resets broad Sonar searches:
#   proxy_read_timeout 180s;
#   proxy_buffering off;          # buffering defeats streaming entirely
#
# AWS ALB idle timeout (default 60s):
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn "$ALB_ARN" \
  --attributes Key=idle_timeout.timeout_seconds,Value=180

# And confirm the phase split before blaming anything:
curl -sS -o /dev/null --max-time 180 \
  -w "connect=%{time_connect}s firstbyte=%{time_starttransfer}s total=%{time_total}s\n" \
  https://api.perplexity.ai/chat/completions \
  -H "Authorization: Bearer $PERPLEXITY_API_KEY" -H "Content-Type: application/json" \
  -d '{"model":"sonar-pro","messages":[{"role":"user","content":"latest AI news"}]}'
# A tiny connect with a huge firstbyte IS the retrieval window. That is normal here.

The ordinary cause, which still applies

Not every Perplexity reset is retrieval-related. The universal cause is still present: your HTTP client pools connections between requests, the edge closes idle ones on its own schedule, and writing a request onto an already-closed socket produces an immediate RST.

Tell them apart by timing. A stale-socket reset fails within a millisecond or two of the write, long before retrieval could have started, and has no relationship to the prompt. A retrieval-window reset fails seconds in, after a successful handshake, and correlates with query breadth.

Fix the stale-socket half with pool hygiene — client idle timeout strictly below the server’s, plus a hard ceiling on connection lifetime — and it stops adding noise to the signal you actually need to read.

Frequently Asked Questions

Why does the Perplexity API reset connections on some prompts but not others?

Because Sonar models search the web before generating, and how long that search takes depends entirely on the question. During retrieval the connection is open and completely silent, and idle timers in proxies, load balancers and serverless runtimes fire on bytes rather than on elapsed request time. A narrow lookup emits its first token quickly and survives; a broad current-events question spends much longer in silence and trips the timer, at which point many intermediaries send a TCP reset rather than a clean 504. That is why two identical deployments can differ purely by prompt.

Is a Perplexity connection reset an outage?

Rarely. The characteristic pattern here — failures that track query breadth rather than time of day, with successes and failures interleaved in the same second — is incompatible with a provider incident, which would fail everything at once regardless of prompt. It also will not appear on a status page, because from Perplexity’s side nothing failed: it was still working on the retrieval when something between you and it severed the connection. Test it directly by running a search-heavy prompt with curl over a fresh connection and a long deadline; if curl completes, Perplexity is fine and an intermediary is at fault.

Does streaming stop Perplexity connection resets?

It stops most of them, because it removes the silence that causes them. With stream enabled the response starts emitting bytes as soon as generation begins, which resets every idle timer along the path and prevents proxies concluding the socket is dead. It also downgrades the failure: a reset partway through a stream has already delivered a usable partial answer and a point to resume from, where a buffered request that dies at second twenty-five returns nothing while you still paid for the retrieval. The one caveat is that the first chunk still arrives only after retrieval completes, so the idle budget covering that opening window has to be generous.

What idle timeout should I set for Perplexity API calls?

Use two values rather than one. The window before the first byte covers live retrieval and needs real room — 90 to 120 seconds is reasonable for broad Sonar searches — while the window between chunks once tokens are flowing can be much shorter, around 30 seconds, because a stream that has gone quiet that long is genuinely stuck. Then make sure every layer you own agrees: nginx defaults to a 60 second proxy read timeout and AWS ALBs to a 60 second idle timeout, and either will reset a legitimate broad search regardless of what your client is configured to allow.

Should I retry a Perplexity request that was reset?

Only after deciding which cause you have, because the answer differs. A reset that fails within milliseconds of the write is a stale pooled socket, nothing was processed, and an immediate retry on a fresh connection is safe and usually instant. A reset seconds into the retrieval phase is different: backoff does not help, because the retry runs the same expensive search into the same idle timer and fails the same way. For that case, fix the idle budget or narrow the query — constrain the search domain or make the question more specific — rather than retrying, and never blindly retry a reset that arrived mid-stream, since those tokens were already generated and billed.

Related Perplexity Guides

Stop Guessing Whether It Is Perplexity or You

API Status Check probes Perplexity from outside your infrastructure with timing recorded on every check — so when connections start dropping you can tell straight away whether Perplexity stopped answering or something in your own path stopped waiting.

Start Your Free Trial →

Perplexity API Connection Reset: Killed During the Silent Search Phase