Код ошибки 1164

$ next info
    Operating System:
      Platform: linux
      Arch: x64
      Version: #1 SMP PREEMPT Thu Apr 20 11:41:14 UTC 2023
    Binaries:
      Node: 19.1.0
      npm: 9.2.0
      Yarn: N/A
      pnpm: 8.1.1
    Relevant packages:
      next: 13.4.2-canary.3
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 4.9.5

same problem here, I use manjaro too.

Same here as well. I am running endeavourOS. From what I’ve seen running different next versions this problem started showing up from 13.3.x forward.

same problem, using Arch Linux

Same issue using rhel 8. Can concur that the issue started occuring on the upgrade to 13.3

OS: rhel 8
Browsers Tested on: chrome/firefox/edge
Created using base npx create-next-app@latest and upgrading current solution to latest.

Port changes everytime you attempt to restart the application, worked with networking to check outbound traffic being blocked (just in case) and came up with nothing.

Using turbopack the error does not happen.
In package.json change the script tag to:
"dev": "next dev --turbo",

On windows is ok, dont need to use turbo pack.

Using turbopack the error does not happen. In package.json change the script tag to: "dev": "next dev --turbo",

On windows is ok, dont need to use turbo pack.

Will give this a shot today and report back.

So this does work…. but when I try to build then start I get the same error…. so a workaround for development but when its ready to push to prod you will encounter the same issue.

Using turbopack the error does not happen.

Unfortunately turbo is in alpha, and doesn’t support all the features that I am using in my app.

This is related to Node > v16.

I know…but reverting it to Node v16 will solve the issue for now.

It looks like a race condition between the port that is going to be used for the connection and the actual service being launched.

It looks like a race condition between the port that is going to be used for the connection and the actual service being launched.

@dav1app Which service is it?

It looks like a race condition between the port that is going to be used for the connection and the actual service being launched.

@dav1app Which service is it?

This seams to be related to Webpack and its way to compile packages, but I am not sure.

If you inspect ports, you might see some other high port being used during first compilation of the package. As I mentioned, it looks like some sort of race condition between the service being up after the request is sent.

Another alternative is to use next dev --turbo, but it is on alpha stage and doesn’t support all the features (including scss, that renders it unusuable for me).

Interesting, wonder if this is also the same issue that we’re now experiencing (intermittently) with Next.js v13.4.3:

When trying to deploy Next.js to Render.com (next build and next start) Render.com detects two ports being opened by the application — one TCP port and one HTTP port. Unfortunately, it selects the incorrect port to test our health check route (I think the default port 10000 must be the HTTP port), so most deploys are failing now.

Seems to be a race condition, because the deploys which don’t fail are selecting the HTTP port as 10000 (which I think is the default for Render.com):

To contrast, before one of the last Next.js versions (and also with other services running other non-Next.js frameworks), we only have a single HTTP port 10000 appearing:

I’ll try to dig in and see if downgrading Next.js to 13.4.2, 13.4.1 or 13.4.0 helps (could of course be unrelated to the rest of the problems described here)

Workaround (deploying production Next.js to Render.com)

Apparently setting the «optional environment variable» PORT to any port appears to make the extra TCP port go away:

Also works with manually setting PORT to the default 10000:

The PORT variable is not set by default on Render — I think they may do something like a reverse proxy to the first exposed port, for better or worse 😅

cc @aduong, @AnalogMemory, @anurag, @BigAlUK from Render.com, in case you run into this same issue with your customers using Next.js and having failures with ports

Thanks @karlhorky, but that doesn’t seem to be a relevant solution to the actual bug described here. Good to know, though. (I haven’t tested it, and for thoroughness I will give it a try later)

I tried this again with a fresh clone and install of the test app (and another app I’m working on), and they both run without error. I tried this with both npm and pnpm.

I made no changes to the code or how I started the app (I used pnpm dev and npm dev)

This is puzzling. The only thing I can suspect is that the issue was fixed by a recent update of Next or one of its dependencies.

Does anyone still have the issue?

Version 13.4.4 App Router and Pages Router still give this error on Manjaro

I spoke too soon. The error is back :/

I first found it with the project I’m working on; then I tried it with the demo/POC repo linked above. Both have the bug, and are unusable.

This is a race condition downgrading your node version to 16 fixes the issue in dev and in production, while not the best solution, it is the solution we have for now.

Thanks, @boncz92 . This seems to work for now.
Any idea when this will be resolved for current versions of Node?

Thanks, @boncz92 . This seems to work for now. Any idea when this will be resolved for current versions of Node?

Your guess is as good as mine, I know that @timneutkens marked it with their internal tag and issue number so they are aware of the issue.

I noticed that it fails because the listening process used tcp6 ::1:. I did a workaround wherein I disabled tcp6 temporarily and it worked. Another workaround I did was pass -H 127.0.0.1 which made the listeners listen using 127 instead of ::1

Before:

After:

@jazar17, this worked for me! Thanks so much for sharing!

I had the same error I used turbopack. In package.json

"scripts": {
    "dev": "next dev --turbo",
    "build": "next build",
    "start": "next start",
    "lint": "next lint"
  }

Archlinux here, same error happening. Can confirm fix was adding -H 127.0.0.1 to dev script.

Archlinux user too, same error. Adding -H 127.0.0.1 to dev script worked like a charm. Attached my scripts after fix as reference.

«scripts»: {
«dev»: «next dev -H 127.0.0.1»,
«build»: «next build»,
«start»: «next start»,
«lint»: «next lint»
}

@timneutkens any update on this? Vercel will stop new builds for Node.js 16.x on August 15th.
Having a fix before would be ideal.

Edit:

I just tested and I still have the issue, here’s my spec:

• With or without the -H 127.0.0.1 flag
• Next.js v13.4.9
• Node.js LTS v18.16.1
• OSX Ventura v13.4
• Not using Turbo

@timneutkens any update on this? Vercel will stop new builds for Node.js 16.x on August 15th. Having a fix before would be ideal.

Edit:

I just tested and I still have the issue, here’s my spec:

• With or without the -H 127.0.0.1 flag
• Next.js v13.4.9
• Node.js LTS v18.16.1
• OSX Ventura v13.4
• Not using Turbo

I know this is not what you want to hear, but if it hits August 15th, if you fall back to node v 16.19.1 the issue is no longer present. Also interested in getting this fixed, but in the mean time I downgraded my node version to continue development.

@boncz92 I actually did that too and it works for now. That being said, the only solution to continue deploying after Vercel’s deadline would be to use different Node.js versions which could cause unexpected bugs.

Note: I just saw that Vercel postponed their Node.js v16 deprecation date to February 5, 2024.

@boncz92 I actually did that too and it works for now. That being said, the only solution to continue deploying after Vercel’s deadline would be to use different Node.js versions which could cause unexpected bugs.

Note: I just saw that Vercel postponed their Node.js v16 deprecation date to February 5, 2024.

Agreed, not a good solution, but at least allows us to forge forward while we anticipate a fix.

@karlhorky Thanks! This fixed my render deployment issue!

@timneutkens This is the same error from #49677. Still encountering this issue on the latest release as well. Stuck using Node 16.19.1 to resolve the issue.

The issue is resolved on my end with Node.js v18 and Next.js v13.5.1.