Introduction

An origin connection reset means the server or an upstream service accepted the connection and then closed it abruptly before returning a complete response. Visitors may see gateway errors, browser reset messages, or intermittent downtime depending on which layer reports the failure first.

Symptoms

  • Reverse proxies report connection reset, upstream reset, or reset by peer errors
  • Visitors get intermittent 502, 520, or generic connection failure messages
  • The site works for some requests but fails on heavier pages or API routes
  • Logs show worker crashes, abrupt socket closes, or dropped backend connections
  • The issue appears after deploys, traffic spikes, or firewall rule changes

Common Causes

  • The application process crashes or exits while handling a request
  • Reverse proxy timeouts or body limits trigger abrupt upstream disconnects
  • Firewalls, WAF rules, or kernel-level protections terminate connections unexpectedly
  • Memory pressure or worker exhaustion causes the backend to restart under load
  • Long-running queries or upstream dependencies force the app to close the connection before response completion

Step-by-Step Fix

  1. Identify which layer reports the reset first by checking browser behavior, proxy logs, app logs, and infrastructure monitoring together.
  2. Confirm whether the origin process is restarting, crashing, or being killed by memory or resource limits.
  3. Compare failing requests with successful ones to see whether specific routes, payload sizes, or backend operations trigger the reset.
  4. Review reverse proxy timeout, buffer, and body-size settings so the proxy is not tearing down a request the app still needs to finish.
  5. Check firewall, WAF, container, or host security rules for automated resets on suspicious or oversized traffic.
  6. Inspect application dependencies like databases, cache servers, or external APIs that may be causing the app to abort the request path midstream.
  7. Stabilize the backend service first, then reload the proxy only after the upstream can hold connections reliably.
  8. Retest through the public hostname and under light load to confirm the resets are gone before declaring recovery.
  9. Add monitoring on worker restarts, memory pressure, and upstream error rates so you can catch the pattern before it becomes a visible outage again.