dev: unhandled ECONNRESET when a proxied websocket dies with its worker #4493

Activity

1. devmrse commented on Aug 14, 2026

   

   devmrse

   on Aug 14, 2026

   More actions

   Can confirm —> hit this exact issue on Nitro 2.13.4 / Nuxt 3.21.11 (nuxt dev, node-server preset), reproducible on nearly every dev-server restart, not just on worker replacement.

   I traced it independently before finding this issue, using an async_hooks init hook to capture the creation stack of the TCP resource behind the unhandled rejection (the default stack TCP.onStreamRead / TCP.callbackTrampoline has no useful async context on its own). That pointed straight to the same place described here:

   DevServer.handleUpgrade (nitropack/dist/core/index.mjs)
   -> NodeDevWorker.handleUpgrade -> this.#proxy.proxy.ws(req, socket, { target, xfwd: true }, head)

   Both callers drop the returned promise:

   • nitropack's createDevServer() exposes upgrade: (req, socket, head) => devServer.handleUpgrade(req, socket, head) with no .catch().
   • @nuxt/cli's dev server registers this.listener.server.on("upgrade", ...) and calls nuxt.server.upgrade(req, socket, head) fire-and-forget (no await/.catch()), so the rejection becomes a process-level unhandledRejection, which @nuxt/cli treats as fatal and restarts on.

   I also found nitropack's createHTTPProxy() never attaches an 'error' listener to the httpxy proxy instance it creates — a second, related gap in the same function, since proxy libraries built on Node's EventEmitter conventions treat an unlistened 'error' event as fatal too.

   Workaround (via patch-package, three small patches, no functional changes otherwise):

   1. nitropack: added a proxy.on("error", ...) handler in createHTTPProxy() that ends/destroys the socket or response instead of leaving it unhandled.
   2. @nuxt/cli: wrapped the nuxt.server.upgrade(req, socket, head) call in Promise.resolve(...).catch(() => socket.destroy()).
   3. listhen: added clientError/connection/error handlers on the dev HTTP server itself, since it had the same class of gap for plain (non-WS) socket resets.

   With all three applied, 80 forced-RST connections (including ones with WebSocket upgrade headers, to hit this exact path) against a running dev server no longer crash it, previously it restarted within seconds, deterministically. Happy to share the exact patch diffs if useful; the fix in the linked PR looks like it covers the same core gap (never letting handleUpgrade reject) plus more.
2. fabis94 commented on Aug 14, 2026

   

   fabis94

   on Aug 14, 2026

   More actions

   i have run into the same issues! i see there's PRs to treat this, would be great to see those reviewed and merged in :)
3. nnshx commented on Aug 27, 2026

   

   nnshx

   on Aug 27, 2026

   More actions

   Confirming this on newer versions, with an additional trigger that doesn't involve a worker restart.

   Environment: nuxt 4.5.2, @nuxt/cli 3.37.0, nitropack 2.13.4, Node v24.19.0, Linux (Debian 13). nitro.experimental.websocket: true.

   Additional trigger — client-side abort is enough. No file edit / worker restart needed: if a client aborts an established WebSocket connection with a TCP RST, the dev server hits the same unhandled path. In 5 aborts we got 2–3 restarts:

   ●  Restarting Nuxt due to error: Error: read ECONNRESET
   

   In practice a browser refresh of a tab holding an open WebSocket can produce this teardown, so during development, one user reloading a page can restart the dev server for everyone. We also once observed the process dying outright instead of restarting, with the classic unhandled-'error'-event crash (node:events throw, Emitted 'error' event on Socket instance).

   Minimal reproduction (3 files + a script):

   // package.json
   {
     "name": "nuxt-ws-rst-repro",
     "private": true,
     "type": "module",
     "scripts": { "dev": "nuxt dev" },
     "dependencies": { "nuxt": "4.5.2" }
   }

   // nuxt.config.ts
   export default defineNuxtConfig({
     nitro: { experimental: { websocket: true } }
   })

   // server/routes/ws.ts
   export default defineWebSocketHandler({
     open(peer) {
       peer.send('hello')
     },
     message() {}
   })

   // repro.mjs — run `pnpm dev --port 3210`, then `node repro.mjs`
   import net from 'node:net'
   import crypto from 'node:crypto'
   const PORT = Number(process.env.PORT ?? 3210)
   const sleep = ms => new Promise(r => setTimeout(r, ms))
   
   for (let i = 1; i <= 5; i++) {
     await new Promise((resolve) => {
       const key = crypto.randomBytes(16).toString('base64')
       const sock = net.connect(PORT, 'localhost')
       sock.on('error', () => resolve())
       sock.on('connect', () => sock.write(
         `GET /ws HTTP/1.1\r\nHost: localhost:${PORT}\r\nConnection: Upgrade\r\nUpgrade: websocket\r\n`
         + `Sec-WebSocket-Version: 13\r\nSec-WebSocket-Key: ${key}\r\n\r\n`))
       sock.once('data', () => {
         setTimeout(() => { sock.resetAndDestroy(); resolve() }, 150)
       })
       setTimeout(resolve, 3000)
     })
     console.log(`RST ${i}/5`)
     await sleep(300)
   }

   Isolation, for what it's worth:

   • Plain HTTP aborts (RST mid-response, 10×): no restart — it's specific to proxied WebSockets.
   • Clean closes (ws.close()): no restart.
   • The production preset (node .output/server/index.mjs) survives the identical abort patterns (including RSTs of fully-established connections and writes to already-reset sockets) with no errors — consistent with the dev-proxy diagnosis in the OP.
4. pi0x

   added

   bugSomething isn't workingSomething isn't working

   nuxt

   v2

   on Sep 2, 2026