"Connection Reset by Peer" — Which End Reset You, and Why

A reset (RST) means someone actively tore the connection down: the peer app, a middlebox, or the OS (port closed / queue full). The context around the reset names the culprit.

What you'll see

Root causes

Peer app crashed, closed, or rejected the request

App-level: process OOM-killed mid-request (check dmesg), request-size limit (nginx 413 sends RST when http2 with some configs), or the upstream actively refusing the payload.

Middlebox: LB/proxy/firewall idle or policy reset

LBs reset connections past idle timeouts mid-stream; corporate firewalls RST on policy (SNI filtering, content type). Resets identical across many clients = middlebox.

OS-level: queue overflow (SYN flood protection) or port closed

netstat -s | grep -i reset / listen queue overflow counters; on the server, net.core.somaxconn and backlog sizing matter under bursts.

Fix it

  1. Reproduce with verbose TCP visibility
    curl -v --max-time 10 https://host/path 2>&1 | tail -15   # where exactly the reset lands (connect vs mid-body)
  2. Correlate with server-side logs at the same timestamp
    sudo journalctl --since '-5 min' | grep -iE 'oom|kill|reset|segfault' ; sudo dmesg -T | tail -10
  3. Capture the RST's direction (who sent it)
    sudo tcpdump -i any -nn 'host <peer> and port 443' -c 50   # RST from the peer = peer-side cause; RST from a middlebox hops = policy/firewall
  4. Match the fix to the cause found
    # app crash: fix the app/OOM ; nginx limit: client_max_body_size ; LB idle: raise timeout or add keepalives ; overflow: raise somaxconn/backlog

Field note

Resets at a consistent point in the stream (same byte count) mean a size/policy limit; random-point resets mean crashes or timeouts. tcpdump showing the RST coming from an IP that's neither endpoint = firewall/LB in the path — that changes everything about your debug.

Common questions

What's the difference between reset and connection refused?

Refused = RST immediately on the initial SYN (nothing listening). Reset mid-connection = established TCP torn down by a peer or middlebox. 'Refused' is a startup problem; 'reset' is a lifetime problem.

Is a reset always a security block?

No — most resets are ordinary: app close without graceful shutdown, idle reaping, or crash. Reserve suspicion for resets that correlate with specific hosts, payload types, or SNI — those point at filtering.

Ship it right the first time

Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.

Browse the template store →

One-time. Yours to modify. Instant download from the NinjaOps template store.

Get new fixes by email

One short email when new fixes and production templates drop. No spam, unsubscribe anytime.

Partner pick — sponsored

Vultr — our lab-environment pick for this stack

Spin up a cloud server in 60 seconds and reproduce this fix yourself — pay by the hour.

Get Vultr →
Also vetted

Sentry — Free tier: see the exact line of code that broke, before users report it.

Get Sentry →

We earn a commission if you buy through our links — it never costs you extra. More vetted tools on our picks hub · comparing clouds? DigitalOcean vs Vultr and vs AWS · full deals: DigitalOcean · Vultr · NordLayer · Semrush