ECONNREFUSED when starting vanilla installation #49677
Comments
|
Executing |
|
I tried to do what you recommended it does not help resolve the issue. |
|
Latest versions give me this error. I'm stuck on 13.2.4. This is the latest working version for me. |
Same here. I have a feeling its an issue with a external dependency that next references..... I just havent been able to nail down a fix for it. Issue does not occur on my personal computer. Think I will give the networking team a ring to see if they can see specific traffic being blocked. Hopefully someone has some additional insight if my investigation turns up nothing. |
Are you running this in an enterprise environment? Would assist with backing my theory if some external dep is getting blocked. |
Nope. I'm working on home. |
Exactly the same here too. We had to downgrade to 13.2.4. I am using MacOS 13.3.1 on M1. The weird thing is that the app works when served from Vercel |
|
I'm having this same issue as well and had to downgrade. MacOs 13.3 |
|
Also seeing this issue. Had to downgrade to 13.2.4, also using 13.3.1 M1 mac. Cant reproduce the issue locally but we see it when we deploy to k8s |
|
I can't reproduce locally on my M1 Mac on Ventura 13.3.1 (22E772610a) but am getting spammed with errors (multiple times a minute) when deployed to Node 19 Alpine instance on Kubernetes. Is anybody getting errors like this? {"log":"Error: read ECONNRESET\n at TCP.onStreamRead (node:internal/stream_base_commons:217:20) {\n errno: -104,\n code: 'ECONNRESET',\n syscall: 'read'\n","stream":"stderr"} {"log":"Error: socket hang up\n at connResetException (node:internal/errors:717:14)\n at Socket.socketOnEnd (node:_http_client:519:23)\n at Socket.emit (node:events:525:35)\n at endReadableNT (node:internal/streams/readable:1359:12)\n at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {\n code: 'ECONNRESET'\n","stream":"stderr"} I am on Next 13.4.2. |
|
13.4.3 has same problem. Thinking about migrating to something else but it's a lot of work. |
|
I had this problem, I found a solution on Stackoverflow that recommends downgrading node from 18 to 16, I tried that and the problem was fixed for me (not ideal I know). |
I can confirm this works. I was using Node 20.2.0. Thanks for sharing but this's not a proper solution. 😞 |
|
One thing to know is that creating a new NextJS app (currently at 13.4.3), the app works with no issues. I think the problem is with the old apps. I have an app which I created with NextJS 13.0.0. I had no issues with updating the "next" package from 13.0.0, 13.1.0. etc until 13.2.4. Updating to 13.4.3 now, on the old project, gives this error. This is my And these are the packages: |
|
Hi, this has been updated in |
|
@iicdii just tested. The error is still there. I updated my old project to the latest NextJS version and deleted every single line of code one by one, remove every file, until I found the issue. It was this line: const dns = require('dns')
dns.setDefaultResultOrder('ipv4first')It works with NextJS 13.2.4, but not with the newer versions |
Nope, still the same. |
|
@TaylanTatli try to do the same as me in order to find the issue: remove every file one by one, and every line one by one to find the issue. Maybe we can find a pattern |
|
Issue also happens in AWS ECS docker containers. Receiving Works fine in Next.js 13.2.4 Issue happens with both Node.js 16.19 and 18.16. |
|
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. |
|
It does happen also in Node.js 16 for me, but as @IonelLupu stated, it does no longer happen with a clean installation of Next.js 13.4.4. It only happens after upgrade. I will investigate it better this evening to narrow down the issue on my side. |
|
I just finished investigating the issue and was able to fix it on my side. Turns out I was receiving Error socket hang up error when indirectly importing Cheers! |
Are you saying the entirety of the issue was resolved by doing that? Or downgrading to node v16 and the firebase-admin 'use client' combination allowed you to work using node v16? Just want to clarify, im not using firebase so the former wouldnt make sense. |
|
After some more digging it turned out that there were two things that caused the
Important finding is that after Next.js 13.2.4 the app seems to crash when run with After removing imports to
Actually, I first got the issue on Node.js 16. I moved briefly to Node.js 18 to test if it will still occur. It did, so I reverted back to Node.js 16 and started investigating.
It still might be worth to check if you import any Node.js specific libraries from components marked with @IonelLupu narrowed down his problem to |
|
Just wanted to add, that we yesterday had a similar behavior where the application crashed on our aws EC2 Instance running on Node.js v18.16.0 and Next.js 13.4.3 ... the log-output is as follows After a complete rebuild and re-deploy the instance runs stable today ... for now. Will report back if we find something. |
|
I'm facing the same problem here. The application works in a local container, but not in an external production server (shows this ECONNREFUSED above). Downgrading to 13.2.4 worked. |
|
Getting the same error with a fresh install of Next.js in this application running Next.js v13.4.4, Node.js 18, on Kubernetes. |
Encountered this exact issue too. Removing those lines in my Note that it also is due to the change in Node.js switching to essentially prefer IPv6 as of v17.0.0. This is mostly an issue when running locally and having (by default) Workarounds include:
Definitely possible there are other issues causing this error though. |
|
We're also still experiencing this same problem in our feature branch. |
|
I think this is related: #49929 (comment) |
This attempts to avoid IPv6 and IPv4 resolve issues across network setups by locking down our internal IPC requests to just one address for consistency. This way there aren't issues when `localhost` resolves to one or the other in different cases. x-ref: #49677
|
Hi, this has been updated in |
|
Hi, I installed the canary version this morning and deployed to our sandbox server but did not get a different result. Our deployment is still timing out on health checks, and I haven't been able to see the log yet, but I'm assuming it's still for the same |
|
I am seeing the same thing. @ijjk |
|
@ijjk I am not running in any type of IPv6 environment so I don't see how this can fix the issue. Also, I am suspecting this has something to do with image optimization as suggested in #49929 (comment) |
|
Same as @Starefossen: the core of the problem is not about a hostname resolution. I eventually had this problem but setting the |
|
I was able to boot: the core issue was allocatable RAM. At 128MB, those extra web servers needed at boot were not able to be created and so connections were not resolving. 256MB seems to be the bare minimum for me. |
|
I still have issues with ECONNREFUSED when using the canary release. |
|
Thanks for the tip, @Swatto! After bumping Next.js from 13.2.1 to 13.4.x we experienced this issue as well. Seems like allocating more memory solved it. I also notice that the Kubernetes pod's memory usage has increased from around 95 MB to over 227 MB. |
|
I am having the same issue on 13.4.7 with Node.js 18.16.1 on macOS. |
|
Getting the same error with a fresh install of Next.js v13.4.7, Node.js 18, on Kubernetes. But work well on my local macOS. The IP 10.16.128.108 is the container IP: // in my k8s pod container
ifconfig
eth0 Link encap:Ethernet HWaddr 7E:17:9C:E8:BD:9E
inet addr:10.16.128.108 Bcast:10.16.128.127 Mask:255.255.255.192
UP BROADCAST RUNNING MULTICAST MTU:1460 Metric:1
RX packets:669 errors:0 dropped:0 overruns:0 frame:0
TX packets:587 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4722152 (4.5 MiB) TX bytes:105302 (102.8 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:100 (100.0 B) TX bytes:100 (100.0 B) |
|
Should this be reopened this @ijjk ? This issue appears to be a symptom of #49929 and it's preventing us from upgrading to the latest version. While we could track the resolution in the linked memory issue I would bet lots of folks, like myself, are landing on this issue from a search of the error message. For anyone else who is stuck - here are two things that helped me get the latest version running in my test cases:
Neither 'fix' is ideal, but could unblock folks. |
|
Yup, getting this error as of 13.4.7. Rolled back to 13.4.5, as 13.4.6 is riddled with #51482: |
|
Anyone who is running into Specifically, the suggestion from @greifmatthias to switch |
|
Wanted to add that this is happening with the pages router too, not just the vanilla (I assume app router) installation. |
|
@shehi feel free to open an new issue, make sure there is a reproduction included, thanks! |
This issue should never have been closed in the first place and should thus be reopened. |
|
I have a nextj 13.4.9 app running on a kuberentes cluster. In my case the problem was due to memory requirements defined in deployment. I increased from 200Mi to 400Mi and then it's started working Sad to see next 13 consume more compute and it's more slow than next 12, but it is what it is |
Unfortunately there's no new reproduction provided, so definitely should be opened as a new issue. If you don't open a new issue with a reproduction we won't be able to investigate this as you can imagine. |
and others
Verify canary release
Provide environment information
Operating System: Platform: linux Arch: x64 Version: #1 SMP Fri Mar 17 01:52:38 EDT 2023 Binaries: Node: 18.14.2 npm: 9.6.6 Yarn: N/A pnpm: N/A Relevant packages: next: 13.4.2-canary.5 eslint-config-next: 13.4.1 react: 18.2.0 react-dom: 18.2.0 typescript: 5.0.4Which area(s) of Next.js are affected? (leave empty if unsure)
No response
Link to the code that reproduces this issue
create-next-app@latest
To Reproduce
npx create-next-app@latest
npm run dev
-Error occurs when attempting to navigate to site
-No additional packages installed
Describe the Bug
Error: connect ECONNREFUSED 127.0.0.1:35391
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16) {
errno: -111,
code: 'ECONNREFUSED',
syscall: 'connect',
address: '127.0.0.1',
port: 35391
}
error Error: connect ECONNREFUSED 127.0.0.1:36639
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16) {
errno: -111,
code: 'ECONNREFUSED',
syscall: 'connect',
address: '127.0.0.1',
port: 36639
}
Notice that the port changes everytime the server is started up. I can bring it up and down 100 times and itll likely be on a different port every time.
Every time the server is started up it results in the above error. I went did incremental package updates to pinpoint exactly when it broke. It appears that at 13.3.0 is when it first starts occuring. I have only seen one other thread with the same issue and there was no solution provided (or any answers on SO)
I do realize this is potentially a configuration issue with the server, I have attempted to turn off the firewall completely and same issue occurs. Some guidance on where to check would be appreciated. I see no errors in my nginx logging either.
Expected Behavior
Site should start as expected.
Which browser are you using? (if relevant)
Chrome/Edge/Firefox
How are you deploying your application? (if relevant)
Linux Rhel 8
The text was updated successfully, but these errors were encountered: