next.js: [next.config.js rewrites] Error: socket hang up

Same issue here!

To add some additional details, this is happening to me sporadically without any rewrites off latest (12.2.3). I can try canary later today. It’s sporadic, but I’m more likely to see it right after server start.

And it is happening to me in production. I saw it some Sentry logs this morning. Hope some of this helps

The initial issue appears to be related to the timeout with proxying to external resources which can be seen here https://github.com/vercel/next.js/blob/a8186065b8eb30ef73d82075dbeb2a6fd94c2eaa/packages/next/server/next-server.ts#L517

Potentially this timeout could be configurable via an experimental config.

@Tuno88 @darkpiv Just wait for next v12.2.4:

https://github.com/vercel/next.js/issues/36251#issuecomment-1199408517

Hi, can you please confirm you are still seeing this error on the latest canary of Next.js v12.2.4-canary.8, as noted this is most likely separate from the initial issue here.

@ijjk Thanks for your response.

I just installed v12.2.4-canary.8 and it seems to fix this issue. Thanks for that 👏

Hi, can you please confirm you are still seeing this error on the latest canary of Next.js v12.2.4-canary.8, as noted this is most likely separate from the initial issue here.

I tested it on v12.2.4 but it looks like the 30s timeout limit is still there, as displayed in the following screenshot.

The axios code that made the call has a higher timeout value, but the next process displays “error - Error: socket hang up”. Is there a setting to configure somewhere ?

hi, is there any solution to fix this?

I think we should wait since the canary version (next@12.2.4-canary.9) is fine.

In my case, I installed canary-8 version and no error log occurred. But I don’t know why, until a few days ago, when developing with the latest version of release, an error did not occur and suddenly occurred for no reason. I’d like someone to explain exactly which part was modified by the shared part that was currently modified or why this error log occurs. 😃

The latest release is still in 12.2.3. we need to wait for the 12.2.4 in order the fix to be applied in latest release

Same error… No error occurred in the small page, but that error log has been occurring continuously since a few days ago. I would like to know the reason for that error message. Please let me know in which direction I should develop the right way.

error - unhandledRejection: Error: aborted
    at connResetException (node:internal/errors:691:14)
    at abortIncoming (node:_http_server:596:17)
    at socketOnClose (node:_http_server:590:3)
    at Socket.emit (node:events:402:35)
    at TCP.<anonymous> (node:net:672:12) {
  code: 'ECONNRESET'
}

Okay, to solve this just: npm install next@12

@youzooyou What do you mean when saying API calls? Is it about Next.js API endpoints (/pages/api/*), or those calls that your application is making from its server-side?

@johnb0 Sorry for writing too long an answer here.

My case was about Rest API calls from server side. In my project, there are two APIs that need to be called from the server side in common, and these are processed as Promise.all and additionally, one server-side API call for setting initialData is made. In addition, we make 5 client-side API calls. In the case of the above error, it started to occur as the completeness of the page increased.

I’m not sure why others got the same error, but in my case it was the nextjs server’s response to an internal value handled by the server, rather than the simple response value that the target API responds to when calling the API. It wasn’t the wrong answer. Naturally, it was a normal event in a server-to-server conversation, and this was an error for me. In nextjs, we dealt with these errors through exception handling so that the server does not die. It’s really great.

Even if I call the Rest API of another domain or an api that works directly from /pages/apis/*, even if I request a response from another server there, my nextjs server sends a response based on unknown information sent by the response server. This means that in the process of processing it, you may be sending invalid or repeated requests. In the response of the normal 200 status value, there was a case where there was a problem with the request or the other server sent additional event information due to incorrect authentication processing at the time of the request.

For anyone else, if this kind of error occurred on a page without an API call, it could be serious, but in my case it was elsewhere. In other words, it was a phenomenon in which the socket connection was disconnected due to repeated requests from the unknown server side and the number of requests exceeded. If you suspect the same case as me, it would be good to monitor and debug the entire response object, not the { data } we use, among the data returned from the server side.

To solve this error log, I installed canary.8 version and confirmed that the log does not appear anymore. However, when I checked the source modified in the canary version, if my thinking was correct, I understood that the log was prevented from occurring directly in the terminal by catching the error in the ‘Promise’ part of the existing bodyStream area.

It was simply that the log was not visible, and the actual log was continuously occurring. Fortunately, the server didn’t die and worked normally. I spent several days analyzing the cause of the error. What the logs have in common is a TCP error and an ECONNRESET phenomenon where the socket is disconnected. There are several causes of ECONNRESET errors, but I thought that one of the main ones had to do with forcing the server to kill requests for excessive requests.

However, in my case, the above error was discovered when parallel processing in the page and a large number of API requests in the page were added. There was no problem with the response to the API request, but there were repeated requests that I did not know about on the server side. And after finding the cause and solving that part, I went back to the current release version and checked if the same error log occurs again, but the error does not occur anymore.

If you get a normal response when making a normal API call, you can think of it as no problem, but there seems to be a case where the actual request API sends the result to send a repeated request to our server. I’m a front-end developer, so I didn’t know the actual server area in detail, and I always paid attention to the normal request and response part. This was my case. In a way, I think this error log happened to me and eventually helped me to optimize my project.

Thanks, I think this error log really helped me.

In my case, I installed canary-8 version and no error log occurred. But I don’t know why, until a few days ago, when developing with the latest version of release, an error did not occur and suddenly occurred for no reason. I’d like someone to explain exactly which part was modified by the shared part that was currently modified or why this error log occurs. 😃

Same issue here!

Guys did you fix the issue? I have the same problem.

If someone knows, how to fix it, I’ll be really apreciate 😃

Just wait for next v12.2.4.

https://github.com/vercel/next.js/issues/36251#issuecomment-1199408517

Joining the club:

This is occuring when I add in a getStaticProps function, even if the function doesn’t call any outside data.

Very strange.

error - unhandledRejection: Error: aborted at connResetException (node:internal/errors:691:14) at abortIncoming (node:_http_server:596:17) at socketOnClose (node:_http_server:590:3) at Socket.emit (node:events:402:35) at TCP.<anonymous> (node:net:687:12) { code: 'ECONNRESET' }

same here . This issue is causing error in build ☹

error - unhandledRejection: Error: aborted at connResetException (node:internal/errors:691:14) at abortIncoming (node:_http_server:596:17) at socketOnClose (node:_http_server:590:3) at Socket.emit (node:events:402:35) at TCP.<anonymous> (node:net:687:12) { code: ‘ECONNRESET’ }

Hi, the unhandledRejection error has been fixed in v12.2.4-canary.4 specifically this PR https://github.com/vercel/next.js/pull/39091 and was unrelated to rewrites in next.config.js like this issues is describing.

Same here :

error - unhandledRejection: Error: aborted at connResetException (node:internal/errors:692:14) at abortIncoming (node:_http_server:602:17) at socketOnClose (node:_http_server:596:3) at Socket.emit (node:events:539:35) at TCP.<anonymous> (node:net:709:12)

It seems like with the latest NextJS version now it also leads to memory leaks. I can see that my NextJS app keeps failing due to allocation failure.

Jul 28 01:34:39 AM  This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:
Jul 28 01:34:39 AM  Error: aborted
Jul 28 01:34:39 AM      at connResetException (node:internal/errors:691:14)
Jul 28 01:34:39 AM      at abortIncoming (node:_http_server:596:17)
Jul 28 01:34:39 AM      at socketOnClose (node:_http_server:590:3)
Jul 28 01:34:39 AM      at Socket.emit (node:events:402:35)
Jul 28 01:34:39 AM      at Socket.emit (node:domain:475:12)
Jul 28 01:34:39 AM      at TCP.<anonymous> (node:net:687:12)
Jul 28 01:34:39 AM      at TCP.callbackTrampoline (node:internal/async_hooks:130:17)

same here

error - unhandledRejection: Error: aborted
    at connResetException (node:internal/errors:692:14)
    at abortIncoming (node:_http_server:602:17)
    at socketOnClose (node:_http_server:596:3)
    at Socket.emit (node:events:539:35)
    at TCP.<anonymous> (node:net:709:12) {
  code: 'ECONNRESET'