next.js: [NEXT-1164] Server error: Development mode tries and fails to connect to a different localhost port
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
npm installnpm run dev- Open browser to
http://localhost:3000orhttp://127.0.0.1:3000 - Expect to see the default home page; instead see an error message naming a given port on the local host.
- See that the same error is also described in the terminal output from
npm run dev - Terminate the running process (
npm run dev) - Repeat steps 2-5 above
- 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-appin 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)
- Using npm both to build (
- 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)
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 10
- Comments: 35 (4 by maintainers)
I noticed that it fails because the listening process used tcp6 ::1:<PORT>. I did a workaround wherein I disabled tcp6 temporarily and it worked. Another workaround I did was pass
-H 127.0.0.1which made the listeners listen using 127 instead of ::1Before:
After:
Workaround (deploying production Next.js to Render.com)
Apparently setting the “optional environment variable”
PORTto any port appears to make the extra TCP port go away:Also works with manually setting
PORTto the default10000:The
PORTvariable 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
@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.
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.
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.
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 (includingscss, that renders it unusuable for me).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.
The issue is resolved on my end with Node.js v18 and Next.js v13.5.1.
@karlhorky Thanks! This fixed my render deployment issue!
@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:
-H 127.0.0.1flagArchlinux here, same error happening. Can confirm fix was adding
-H 127.0.0.1to dev script.@jazar17, this worked for me! Thanks so much for sharing!
Thanks, @boncz92 . This seems to work for now. Any idea when this will be resolved for current versions of Node?
Version 13.4.4
App RouterandPages Routerstill give this error on ManjaroThis is related to Node > v16.
I know…but reverting it to
Node v16will 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.
same problem here, I use manjaro too.