How to Fix “upstream connect error or disconnect/reset before headers. reset overflow”

Seeing “upstream connect error or disconnect/reset before headers. reset overflow” on your screen means one thing: the Envoy proxy in front of the service refused your request, usually with an HTTP 503. The phrase “reset reason: overflow” tells you exactly why. An Envoy circuit breaker tripped, so your request was rejected before it ever reached the backend. This guide explains what the upstream connect error reset overflow message means and how to fix it, whether you run the service or are just trying to load a website.

You will run into this error anywhere Envoy sits in the request path. The usual suspects are an Istio service mesh, a Kubernetes ingress gateway, a cloud API gateway, or any site that happens to run behind Envoy. For end users it looks like the site is down. For the team running the service, it means a safety valve did its job, possibly a little too eagerly.

What Causes This Error

The word “overflow” is the giveaway. Envoy’s circuit breakers cap the number of connections, pending requests, and active requests that a cluster may hold. The default thresholds are 1024 each for max_connections, max_pending_requests, and max_requests. When real demand crosses those lines, Envoy sheds load by failing new requests with this exact upstream connect error reset overflow message. The five most common triggers are below.

1. Circuit-breaker thresholds too low for real load. The stock defaults of 1024 connections and pending requests can be far too small for a busy service, especially one served by a small pool of backend pods. Traffic that is perfectly healthy still gets rejected once the counters fill up.
2. maxPendingRequests set to 0. In Istio, setting http1MaxPendingRequests to 0 rejects queued requests outright, so freshly started pods fail traffic bursts the moment they begin warming up. If you see a plain 503 page instead of this error, our guide to fixing Error 503 Backend Unhealthy covers that sibling problem.
3. The HTTP/1.1 connection ceiling. Over HTTP/1.1, every concurrent request needs its own upstream connection. A burst of parallel requests can exhaust maxConnections long before the backends are genuinely busy, and every request past the ceiling gets the overflow error.
4. Retry storms latching the outage. When every client retries aggressively at the same moment, the retry traffic itself keeps the connection pool full, so the breaker never resets and the upstream connect error reset overflow outage latches on. Runaway retries cause similar failures elsewhere too, like the ones in our GCP Cloud Scheduler schedulingrejected guide.
5. End-user side causes. Sometimes the trigger is closer to home: the backend is genuinely overloaded, a VPN or corporate proxy is interfering with the connection, or corrupted cache and cookies are replaying broken state. These do not trip a circuit breaker by themselves, but they can produce the same error screen for the person browsing. Our Blooket WebSocket error fix walks through similar connection troubleshooting steps.

How to Fix It

There are two completely different fixes, and the right one depends on which side of the error you are on. Pick your track below.

Track A: You Run the Service

If you own the cluster or the gateway, the upstream connect error reset overflow is a configuration problem. Work through these in order.

1. Raise the Envoy circuit_breakers thresholds on the cluster. The defaults of 1024 are conservative. Size the thresholds to your real peak load with headroom:

circuit_breakers:
  thresholds:
    - priority: DEFAULT
      max_connections: 2048
      max_pending_requests: 2048
      max_requests: 2048

2. Tune the Istio DestinationRule connectionPool. In an Istio mesh, set tcp.maxConnections, http.http1MaxPendingRequests, http.http2MaxRequests, http.maxRequestsPerConnection, and http.maxRetries inside trafficPolicy to match your traffic shape. Pair them with outlierDetection so unhealthy hosts get ejected instead of soaking up the pool:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-service
spec:
  host: my-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 2000
      http:
        http1MaxPendingRequests: 2000
        http2MaxRequests: 2000
        maxRequestsPerConnection: 100
        maxRetries: 3
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s

3. Add retry budgets instead of unbounded retries. Cap retries per request and add backoff with jitter, so one slow backend does not turn a single request into ten. A small, bounded retry budget keeps a blip from becoming a storm.

4. Never set maxPendingRequests to 0. A zero pending-request queue means any burst beyond the active request limit is rejected instantly, which is exactly the overflow error you are trying to eliminate. Always leave a queue, even a modest one.

Track B: You Just See the Error as a User

If you do not run the service, the circuit breaker is not yours to tune, but these steps often clear the upstream connect error reset overflow from your side:

1. Check the service status page. If the team has posted an incident, the fastest fix is waiting for their update.
2. Wait a minute, then retry once. Circuit breakers reset when load drops, which is what clears the upstream connect error reset overflow. One gentle retry after a pause is fine. Hammering refresh makes it worse.
3. Disable your VPN or proxy. VPNs and corporate proxies add connection hops that can push a busy pool over its limit from your side.
4. Clear cache and cookies. Corrupted cached data can replay a failing request path, and stale cookies can pin you to a broken session.
5. Switch networks. Moving from Wi-Fi to mobile data (or the reverse) can route you to a different edge or gateway that is not saturated.
6. Try the app instead of the browser. Native apps often use different connection handling and may sidestep the failing path entirely.

How to Verify the Upstream Connect Error Reset Overflow Fix

Envoy’s admin interface exposes the proof at /stats. Watch the upstream_rq_pending_overflow and upstream_rq_active_overflow counters for the affected cluster. After a fix, both counters should stop climbing under the same load that previously triggered the upstream connect error reset overflow message. If they are still rising, the thresholds are still too low or the retry storm is still running.

Frequently Asked Questions

Is this error my fault?

As an end user, almost never. The error means the service’s own safety limits rejected your request, so the fix sits with the team running it. If you keep seeing the upstream connect error reset overflow screen, the fix has to come from the team running the service. The one exception is when your own setup is contributing, like a misbehaving VPN or a corrupted cache, which is why the Track B steps above are worth trying first.

Does hammering the retry button help?

No. It makes things worse. Every retry consumes another slot in the connection pool, which keeps the circuit breaker tripped and latches the upstream connect error reset overflow outage. Wait, then retry once after a pause.

What is the difference between overflow and other reset reasons?

“Overflow” means the circuit breaker rejected your request before it was ever attempted, which is the whole story behind the upstream connect error reset overflow message. Other reset reasons describe different failures: a connection that could not be opened, an upstream that reset the connection mid-flight, or a request that timed out. Overflow is special because it is a deliberate load-shedding decision, not a broken wire.

Last updated: October 2026. Fix the thresholds, budget your retries, and the upstream connect error reset overflow message goes away for good.