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

[abriginets]

Verify canary release

• [X] I verified that the issue exists in Next.js canary release

Provide environment information

    Operating System:
      Platform: linux
      Arch: x64
      Version: #1 SMP Wed Oct 28 23:40:43 UTC 2020
    Binaries:
      Node: 16.13.1
      npm: 8.1.2
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 12.1.5
      react: 17.0.2
      react-dom: 17.0.2

What browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

Describe the Bug

When using rewrites it's impossible to make a request to API endpoint that takes more than 30 seconds to respond. After 31 second Next just throws the error Server Error Error: socket hang up which makes it impossible to use with any responding APIs.

Expected Behavior

There should be a soft timeout which would not throw after 30 seconds but should proceed waiting for the response and only show a warning. Or provide additional option to set custom timeouts.

To Reproduce

Create a rewrite rule to the endpoint which responds more than 30 seconds.

[linrock]

+1 for a resolution to this issue. being able to customize the timeout would be nice.

also it'd be nice to show an error message that's less cryptic when a timeout happens. it's not obvious that this error is caused by a hardcoded 30-second timeout in the http proxy config used by next.js rewrites:

Error: socket hang up
  at connResetException (internal/errors.js:628:14)
  at Socket.socketCloseListener (_http_client.js:449:25)
  at Socket.emit (events.js:412:35)
  at TCP. (net.js:675:12) {
  code: 'ECONNRESET'

[reuixiy]

Same issue here!

[tonyYo00]

Same issue here!

[GRIM-xx]

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'

[hunghg2505]

Same error,

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

[gothic-a]

Same issue with node 14.18

[youzooyou]

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

[bryanprimus]

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 with node v16 and next latest (not canary) in windows machine

[domosedov]

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 Socket.emit (node:domain:475:12)
    at TCP.<anonymous> (node:net:687:12)
    at TCP.callbackTrampoline (node:internal/async_hooks:130:17) {
  code: 'ECONNRESET'
}

[Duckinm]

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. (node:net:687:12) { code: 'ECONNRESET' }

[mdaverde]

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

[abriginets]

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)

[briva]

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. (node:net:709:12)

[ijjk]

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.

[abriginets]

@ijjk are there any plans for the near future to look into rewrites related issue?

[ijjk]

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.

[elamandeep]

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. (node:net:687:12) { code: 'ECONNRESET' }

[daveidivide]

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

[monsieurnebo]

Similar issue over here.

If I try to open the page right after started the local server, I encounter the following error:

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

If I wait for the page build, then open the page: no error.

[ijjk]

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.

[monsieurnebo]

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 👏

[gee06robson]

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. (node:net:709:12) { code: 'ECONNRESET' }

Here too, using useEffect to call google api.

[elamandeep]

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.

Still getting error ☹

[youzooyou]

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

[bryanprimus]

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

[johnb0]

Just tried with 12.2.4-canary.8 and the issue is still there.

Logs: FetchError: request to http://localhost:3100/localization failed, reason: socket hang up at ClientRequest.<anonymous> (/app/node_modules/next/dist/compiled/node-fetch/index.js:1:65763) at ClientRequest.emit (events.js:400:28) at Socket.socketOnEnd (_http_client.js:499:9) at Socket.emit (events.js:412:35) at endReadableNT (internal/streams/readable.js:1334:12) at processTicksAndRejections (internal/process/task_queues.js:82:21)

[daveidivide]

I doubt this is what's causing most peoples issues...but the fix for me was that in my function in my api folder it was using 'return data' instead of 'res.status(200).json(data)'.

return data; -> res.status(200).json(data);

Once I sorted that, my API call in getStaticProps() worked fine and the error went away.

[elamandeep]

I doubt this is what's causing most peoples issues...but the fix for me was that in my function in my api folder it was using 'return data' instead of 'res.status(200).json(data)'.

return data; -> res.status(200).json(data);

Once I sorted that, my API call in getStaticProps() worked fine and the error went away.

I don't think so because i have freshly created new project still it's showing me that error very strange 🤔.

[shazamshakeel]

I doubt this is what's causing most peoples issues...but the fix for me was that in my function in my api folder it was using 'return data' instead of 'res.status(200).json(data)'.

return data; -> res.status(200).json(data);

Once I sorted that, my API call in getStaticProps() worked fine and the error went away.

It's strange but it worked for me ! I was also having this error

[youzooyou]

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.

[johnb0]

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.

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

[youzooyou]

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

[Tuno88]

hi, is there any solution to fix this?

[darkpiv]

Got this with node 16.16

[darkpiv]

hi, is there any solution to fix this?

I think we should wait since the canary version ([email protected]) is fine.

[monsieurnebo]

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

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

[elamandeep]

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

#36251 (comment)

Yup !! You are right

[tonyYo00]

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.

what's up this one ?

[zodman]

this issue could be fixed with a nginx configuration

if you have something like this:

async rewrites() {
        return [
          {
            source: '/gql/:path*',
            // this configuration its overwritten by nginx. 
            destination:
              (process.env.NEXT_PUBLIC_API_URL || '') + '/graphql/:path*', // Proxy to Backend
          },

you proxy with this ...

location  /gql {
        proxy_pass http://your-backend/graphql;
        proxy_set_header Host yout-backend.domain.com;
        proxy_read_timeout 300s;
}

In this way know you have control of the timeout

[denysderihlazov]

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

If someone knows, how to fix it, I'll be really apreciate :)

[denysderihlazov]

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

[monsieurnebo]

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

[azihassan]

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 ?

[johnb0]

I noticed strange thing, when I disable keepAlive (https://nextjs.org/docs/api-reference/next.config.js/disabling-http-keep-alive) the error goes away. Unfortunately it has negative impact on response time under high load