#ERROR [unhandledRejection] read ECONNRESET

14 messages · Page 1 of 1 (latest)

molten basalt
#

Hey guys, currently, when I perform an action on my site that involves the backend (in this case, logging in), I often get the following error:

ERROR [unhandledRejection] read ECONNRESET 20:04:58

at TCP.onStreamRead (node:internal/stream_base_commons:216:20)

I can't see why this is happening or identify any other problems. Does anyone have any ideas?

package.json:

{
  "name": "website-nuxt",
  "type": "module",
  "private": true,
  "scripts": {
    "build": "bunx --bun nuxt build",
    "dev": "npx nuxt dev",
    "generate": "bunx --bun nuxt generate",
    "preview": " bunx --bun nuxt preview",
    "postinstall": "bunx --bun nuxt prepare",
    "trigger": "bunx trigger.dev dev",
    "run-prod": "bunx drizzle-kit migrate && bun run ./.output/server/index.mjs"
  },
  "dependencies": {
    "@dargmuesli/nuxt-cookie-control": "9.1.6",
    "@headlessui/vue": "^1.7.23",
    "@nuxt/content": "^3.9.0",
    "@nuxt/eslint": "1.9.0",
    "@nuxt/fonts": "0.12.1",
    "@nuxt/icon": "2.0.0",
    "@nuxt/image": "^2.0.0",
    "@nuxtjs/i18n": "10.1.1",
    "@nuxtjs/seo": "3.2.2",
    "@nuxtjs/tailwindcss": "6.14.0",
    "@popperjs/core": "^2.11.8",
    "@simplewebauthn/browser": "11.0.0",
    "@stripe/stripe-js": "^8.5.3",
    "@tailwindcss/forms": "^0.5.10",
    "@tailwindcss/typography": "^0.5.19",
    "@tailwindcss/vite": "^4.1.17",
    "@trigger.dev/sdk": "4.2.0",
    "@types/three": "^0.181.0",
    "@vee-validate/nuxt": "^4.15.1",
    "@vee-validate/valibot": "^4.15.1",
    "@vee-validate/zod": "^4.15.1",
    "@vueuse/nuxt": "13.9.0",
    "@xterm/addon-fit": "^0.10.0",
    "@xterm/addon-web-links": "^0.11.0",
    "@xterm/xterm": "^5.5.0",
    "better-sqlite3": "^12.5.0",
    "i18n-iso-countries": "^7.14.0",
    "lottie-web": "^5.13.0",
    "moment": "^2.30.1",
    "nuxt": "4.1.3",
    "nuxt-aos": "1.2.5",
    "nuxt-auth-utils": "0.5.25",
    "otplib": "^12.0.1",
    "qrcode": "^1.5.4",
    "qs": "^6.14.0",
    "tailwindcss": "^4.1.17",
    "three": "^0.181.2",
    "typescript": "^5.9.3",
    "vue": "^3.5.25",
    "vue-router": "^4.6.3",
    "vue-sonner": "^2.0.9"
  },
  "devDependencies": {
    "@aws-sdk/client-s3": "^3.946.0",
    "@aws-sdk/s3-request-presigner": "^3.946.0",
    "@infisical/sdk": "^4.0.6",
    "@mistralai/mistralai": "^1.10.0",
    "@simplewebauthn/server": "11.0.0",
    "@trigger.dev/build": "4.2.0",
    "@types/bcrypt": "^6.0.0",
    "@types/bun": "^1.3.3",
    "@types/cidr-matcher": "^2.1.2",
    "@types/nodemailer": "^7.0.4",
    "@types/qrcode": "^1.5.6",
    "@types/qs": "^6.14.0",
    "@types/xml2js": "^0.4.14",
    "@vue-email/components": "^0.0.21",
    "@vue-email/render": "^0.0.9",
    "bcrypt": "^6.0.0",
    "cidr-matcher": "^2.1.1",
    "cloudflare": "^5.2.0",
    "deepl-node": "^1.22.0",
    "dns-over-http-resolver": "^3.0.16",
    "drizzle-kit": "^0.31.8",
    "drizzle-orm": "^0.45.0",
    "esbuild-plugin-vue3": "^0.5.1",
    "eslint-config-prettier": "^10.1.8",
    "eslint-plugin-prettier": "^5.5.4",
    "js-base64": "^3.7.8",
    "luaparse": "^0.3.1",
    "mariadb": "^3.4.5",
    "mysql2": "^3.15.3",
    "node-mailjet": "^6.0.11",
    "nodemailer": "^7.0.11",
    "prettier": "^3.7.4",
    "stripe": "^20.0.0",
    "xml2js": "^0.6.2",
    "zugferd-generator": "^1.2.1"
  }
}
brazen pawnBOT
#

Hi @molten basalt. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

This kind of ECONNRESET in Nuxt 4 is almost always the Node.js process telling you “the other side closed the TCP connection unexpectedly” rather than Nuxt itself providing a detailed app-level error.

From the provided knowledge sources, there is no explicit mention of read ECONNRESET with Nuxt 4, only somewhat related low‑level connection issues (e.g. premature close / connection: close / keep‑alive behavior, or Node 19+ changing idle/keep‑alive handling). [nitro v3 WIP; Node 19 keep-alive change]

So I can’t point you to a specific Nuxt bug or configuration in these docs that directly explains your error.

Given that limitation, here’s what is supported by the sources and what you can try, in order of how “Nuxt‑specific” it is:

  1. Check your Node version & connection headers

    One referenced case shows Node ≥19 being stricter about keep‑alive vs connection: close, causing low‑level connection errors when a proxy or HTTP client sends connection: 'close' and the server closes early. [Node 19 change]

    • Ensure your backend / proxy / HTTP client (e.g. Axios, fetch wrapper) is not forcing connection: 'close' in requests.
    • If you have a reverse proxy (NGINX, Cloudflare, etc.), temporarily bypass it and hit the Nuxt dev server and backend directly.

  2. Look for backend / DB / SMTP disconnects during login

    The error appears “when logging in”, i.e. when your server routes hit:

    • your DB (better-sqlite3, mysql2, mariadb, drizzle-orm),
    • external APIs (Stripe, Mailjet, DeepL, S3, etc.),
    • or SMTP (nodemailer, node-mailjet).
#

ECONNRESET will happen if those connections are closed abruptly. Since the sources don’t contain your route code, they also can’t give a concrete fix here.

  1. Check if it only happens in dev

    Some related issues in the sources appear only in dev and don’t affect actual app behavior. For example, the “Premature close” / dev‑server errors with Nuxt 4 + Nitro 3 were internal dev server issues. [premature close issue; nitro v3 WIP]

    • If the error is dev‑only and your API call still succeeds, it may be a noisy dev‑server/network thing, not a broken feature.

  2. Capture a minimal reproduction

    The Nuxt team asks for a minimal reproduction to triage low-level connection errors. [repro guide]

    • Strip your app down to just the login call and its server API handler.
    • If the error persists in that tiny repo, you can share it with the Nuxt team following the reproduction guidelines. [reporting bugs]

Because the knowledge sources do not contain a documented read ECONNRESET issue for Nuxt 4.1.3 with your dependency set, I can’t confidently say “upgrade X to version Y” or “set this Nuxt config option” to fix it. It’s most likely an underlying connection or proxy issue during your login route, but confirming that would require code and logs that aren’t in the sources.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@molten basalt Kapa.ai is still learning and improving, please let me know how I did by reacting below.

molten basalt
#

@brazen pawn when i try bun i and then bunx --bun nuxt dev then this error appears:
🔍 Resolving [1/1] 🔍 Resolving [1/1] error: "git fetch" for "@C:/Users/Comma/Documents/Kunden/Respawn/website-nuxt/node_modules/@nuxt/cli/dist/dev/index.mjs" failed
error: InstallFailed cloning repository for @C:/Users/Comma/Documents/Kunden/Respawn/website-nuxt/node_modules/@nuxt/cli/dist/dev/index.mjs
error: @C:/Users/Comma/Documents/Kunden/Respawn/website-nuxt/node_modules/@nuxt/cli/dist/dev/index.mjs failed to resolve
error: "git clone" for "@C:/Users/Comma/Documents/Kunden/Respawn/website-nuxt/node_modules/@nuxt/cli/dist/dev/index.mjs" failed
error: InstallFailed cloning repository for @C:/Users/Comma/Documents/Kunden/Respawn/website-nuxt/node_modules/@nuxt/cli/dist/dev/index.mjs
error: @C:/Users/Comma/Documents/Kunden/Respawn/website-nuxt/node_modules/@nuxt/cli/dist/dev/index.mjs failed to resolve

brazen pawnBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

This error is coming from @nuxt/cli, not directly from your app code. In the linked Nuxt issue, a similar dev‑time error after upgrading to Nuxt 4 was traced back to a bug in certain @nuxt/cli versions, and maintainers explicitly said it should be fixed in newer CLI releases and suggested updating it or refreshing the lockfile. [Nuxt 4 premature close]

From the knowledge we have, the actionable steps that are clearly recommended are:

  1. Update @nuxt/cli and refresh lockfile

    A Nuxt member wrote (about a related dev error):

    “this should be resolved in the latest release of nuxt/cli. refresh your lockfile or install it explicitly” [Nuxt 4 premature close]

    So for your Bun setup:

    • Ensure @nuxt/cli is brought up to at least 3.30.0 (where a related bug was confirmed fixed by users). [Nuxt 4 premature close]
    • Delete lock + node_modules:
      rm -rf node_modules bun.lockb
    • Re‑install:
      bun install
    • Then run:
      bunx --bun nuxt dev

  2. If still broken: explicitly add/override @nuxt/cli

    In the same issue, users temporarily solved the problem by pinning @nuxt/cli to a known‑good version. [Nuxt 4 premature close]

    Add to devDependencies (example version – pick the latest 3.x actually available to you, or the one you know works):

    {
  "devDependencies": {
    "@nuxt/cli": "3.30.0"
  }
}

    Then again:

    rm -rf node_modules bun.lockb
bun install
bunx --bun nuxt dev

  3. If it still happens

#

The sources don’t contain anything more specific about Bun trying to git fetch an on‑disk .mjs file path like @C:/Users/.../@nuxt/cli/dist/dev/index.mjs, so beyond updating and pinning @nuxt/cli as above, I don’t have a documented, Nuxt‑specific fix to point you to. At that point you’d likely need a minimal reproduction and to open an issue, as suggested by the Nuxt team for CLI‑related problems. [Nuxt bug reporting guide]

So: update or explicitly pin @nuxt/cli, clear your lockfile and node_modules, reinstall with Bun, and retry bunx --bun nuxt dev.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@molten basalt Kapa.ai is still learning and improving, please let me know how I did by reacting below.

molten basalt
#

@brazen pawn i didn't even have @abstract forge/cli installed in my package.json

brazen pawnBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

Nuxt 4 installs and uses @nuxt/cli as an internal dependency, so you won’t normally see it in your package.json even though it’s present in node_modules. That’s why Bun is trying to resolve:

@C:/Users/.../node_modules/@nuxt/cli/dist/dev/index.mjs

The relevant bits from the sources:

So your situation is:

  • You don’t list @nuxt/cli explicitly, but Nuxt 4.1.3 brings in some @nuxt/cli version via its own dependencies.
  • Bun’s resolver is misinterpreting the path (treating a Windows path as a Git spec) when it encounters @nuxt/cli/dist/dev/index.mjs.

Within what’s documented in the sources, the Nuxt‑side steps you can reasonably try are:

  1. Refresh lockfile and node_modules so Nuxt pulls the latest compatible @nuxt/cli

    This is exactly what a Nuxt member suggested for a related Nuxt 4 + CLI issue: “refresh your lockfile or install it explicitly”. [Nuxt 4 premature close]

    rm -rf node_modules bun.lockb
bun install
bunx --bun nuxt dev

  2. Optionally pin @nuxt/cli in your own package.json

#

Users in the same issue temporarily fixed their errors by pinning a specific CLI version (e.g. 3.28.0, later 3.30.0 where the bug was reported as fixed). [Nuxt 4 premature close]

Add to your devDependencies:

{
  "devDependencies": {
    "@nuxt/cli": "3.30.0"
  }
}

Then reinstall:

rm -rf node_modules bun.lockb
bun install
bunx --bun nuxt dev

The knowledge sources do not describe this exact Bun/Git resolution bug (git fetch against a local .mjs path), so beyond making sure Nuxt is pulling a fixed @nuxt/cli version and refreshing your install, I can’t cite a more specific, Nuxt‑documented workaround. If the problem persists after those steps, you’d likely need to provide a minimal reproduction and open an issue, as Nuxt maintainers request for CLI‑related problems. [bug reporting guide]

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: