[NEXT-1164] Server error: Development mode tries and fails to connect to a different localhost port

[bluepostit]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

$ 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

Which area(s) of Next.js are affected? (leave empty if unsure)

Operating System (Windows, MacOS, Linux)

Link to the code that reproduces this issue

https://github.com/bluepostit/nextjs-connection-refused

To Reproduce

NB: Affects only Linux (Manjaro), as far as I have tested

I have only experienced this error when trying to run a Next.js app on Manjaro Linux. The same app works fine on a Mac OS. I have not tested any other OSes

1. npm install
2. npm run dev
3. Open browser to http://localhost:3000 or http://127.0.0.1:3000
4. Expect to see the default home page; instead see an error message naming a given port on the local host.
5. See that the same error is also described in the terminal output from npm run dev
6. Terminate the running process (npm run dev)
7. Repeat steps 2-5 above
8. See the same error message, but naming a different port on the local host.

First run: given port is 38639

Second run: given port is 34347

Describe the Bug

• The expected index page is not displayed in the browser
• The app is not functional
• Instead, the Next.js process reports a server error
• The error says that the app has a Connection Refused error when trying to connect to a certain port on the same machine (local host)
• The port number is different each time I run npm run dev, and seems always to be in the 3000s (from a small sample size)
• There is no process running on the given port that I am aware of.
• Unfortunately the error message gives no information as to why the app attempted to communicate with whatever process it expected to be listening and responding on that port.

Notes

• As mentioned above, this was tested with Manjaro Linux, where I consistently see this bug.
• When testing the same code on a Mac, I don't see the bug.
• I tested Next.js apps built with create-next-app in two scenarios:
  • Using npm both to build (npx create-next-app ...) and to run (npm run dev)
  • Using pnpm both to build (pnpm create next-app ...) and to run (pnpm dev)
• The results were identical in both cases.

Expected Behavior

• Expected to see the app's pages rendered in the browser
• Expected no server error

Which browser are you using? (if relevant)

Firefox Developer Edition 112.0b9

How are you deploying your application? (if relevant)

npm run dev (localhost)

_NEXT-1164

[Ataide]

same problem here, I use manjaro too.

[DenisJulio]

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.

[dcousens]

same problem, using Arch Linux

[boncz92]

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.

[Ataide]

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.

[boncz92]

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.

[boncz92]

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.

[bluepostit]

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.

[dav1app]

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.

[bluepostit]

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?

[dav1app]

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).

[karlhorky]

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)

[karlhorky]

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

[bluepostit]

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)

[bluepostit]

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?

[NextWack]

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

[bluepostit]

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.

[boncz92]

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.

[bluepostit]

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

[boncz92]

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.

[jazar17]

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:

[bluepostit]

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

[hyper-dot]

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"
  }

[GentikSolm]

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

[jcruzv-prog]

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"
}

[franknoel]

@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

[boncz92]

@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.

[franknoel]

@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]

@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.

[solomon-bush]

@karlhorky Thanks! This fixed my render deployment issue!

[boncz92]

@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.

[franknoel]

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

[ahmouse15]

Resolved for me as well on Node.js v20 and Next.js v13.5.3

[timneutkens]

This has been resolved in 13.5 indeed 👍

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.