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

abriginets · 2022-04-18T20:24:44Z

Verify canary release

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.

The text was updated successfully, but these errors were encountered:

linrock · 2022-05-03T19:32:59Z

+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 · 2022-06-23T02:41:43Z

Same issue here!

tonyYo00 · 2022-07-19T08:54:16Z

Same issue here!

GRIM-xx · 2022-07-25T02:55:51Z

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 · 2022-07-25T06:52:48Z

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 · 2022-07-25T19:10:55Z

Same issue with node 14.18

youzooyou · 2022-07-27T04:41:58Z

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

bryanltobing · 2022-07-27T09:32:23Z

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 · 2022-07-27T11:44:16Z

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 · 2022-07-27T11:47:05Z

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 · 2022-07-27T12:07:23Z

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 · 2022-07-27T23:37:39Z

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 · 2022-07-28T20:31:51Z

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 · 2022-07-28T20:36:37Z

Hi, the unhandledRejection error has been fixed in v12.2.4-canary.4 specifically this PR #39091 and was unrelated to rewrites in next.config.js like this issues is describing.

abriginets · 2022-07-28T20:40:16Z

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

ijjk · 2022-07-28T20:44:45Z

The initial issue appears to be related to the timeout with proxying to external resources which can be seen here

next.js/packages/next/server/next-server.ts

Line 517 in a818606

proxyTimeout: 30_000, // limit proxying to 30 seconds

Potentially this timeout could be configurable via an experimental config.

elamandeep · 2022-07-29T04:57:33Z

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 · 2022-07-29T06:50:16Z

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 · 2022-07-29T14:31:14Z

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 · 2022-07-29T14:34:44Z

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 · 2022-07-29T14:43:50Z

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 · 2022-07-29T16:53:26Z

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 · 2022-07-30T03:56:55Z

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 · 2022-08-01T01:14:00Z

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

bryanltobing · 2022-08-01T08:23:56Z

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 · 2022-08-01T14:00:19Z

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 · 2022-08-01T14:48:38Z

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 · 2022-08-01T16:23:12Z

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 · 2022-08-02T02:48:29Z

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 · 2022-08-02T06:36:49Z

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 · 2022-08-02T07:49:36Z

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 · 2022-08-02T08:44:11Z

@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 · 2022-08-03T04:34:10Z

hi, is there any solution to fix this?

darkpiv · 2022-08-03T07:58:05Z

Got this with node 16.16

darkpiv · 2022-08-03T08:02:42Z

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.

monsieurnebo · 2022-08-03T13:23:03Z

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

#36251 (comment)

elamandeep · 2022-08-04T08:43:05Z

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

#36251 (comment)

Yup !! You are right

tonyYo00 · 2022-08-05T07:12:47Z

The initial issue appears to be related to the timeout with proxying to external resources which can be seen here

next.js/packages/next/server/next-server.ts

Line 517 in a818606

proxyTimeout: 30_000, // limit proxying to 30 seconds

Potentially this timeout could be configurable via an experimental config.

what's up this one ?

zodman · 2022-08-05T19:34:31Z

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 · 2022-08-10T08:34:00Z

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

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

denysderihlazov · 2022-08-10T08:46:09Z

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

monsieurnebo · 2022-08-10T12:07:57Z

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.

#36251 (comment)

azihassan · 2022-08-11T11:02:02Z

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 · 2022-08-12T09:13:05Z

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

## Bug - [X] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` Fixes #36251

github-actions · 2022-10-08T12:07:08Z

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

abriginets added the bug Issue was opened via the bug report template. label Apr 18, 2022

abriginets changed the title ~~[next.config.js rewrites]Error: socket hang up~~ [next.config.js rewrites] Error: socket hang up Apr 18, 2022

viniciusbitt mentioned this issue Apr 30, 2022

[next.config.js] rewrites be able to change the proxyTimeout #36586

Closed

NerOcrO mentioned this issue Jul 27, 2022

(hel-171) Suppression de minify-stream et mise à jour de NextJs DNUM-SocialGouv/helios#97

Merged

abriginets mentioned this issue Aug 22, 2022

Increase proxy limit from 30s to 60s #39814

Closed

3 tasks

bcheidemann mentioned this issue Sep 6, 2022

Add experimental proxy timeout option #40289

Merged

3 tasks

ijjk closed this as completed in #40289 Sep 7, 2022

github-actions bot locked as resolved and limited conversation to collaborators Oct 8, 2022

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

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

Comments

abriginets commented Apr 18, 2022

Verify canary release

Provide environment information

What browser are you using? (if relevant)

How are you deploying your application? (if relevant)

Describe the Bug

Expected Behavior

To Reproduce

linrock commented May 3, 2022

reuixiy commented Jun 23, 2022

tonyYo00 commented Jul 19, 2022

GRIM-xx commented Jul 25, 2022 • edited

hunghg2505 commented Jul 25, 2022 • edited

gothic-a commented Jul 25, 2022

youzooyou commented Jul 27, 2022

bryanltobing commented Jul 27, 2022

domosedov commented Jul 27, 2022 • edited

Duckinm commented Jul 27, 2022

mdaverde commented Jul 27, 2022

abriginets commented Jul 27, 2022

briva commented Jul 28, 2022

ijjk commented Jul 28, 2022

abriginets commented Jul 28, 2022

ijjk commented Jul 28, 2022

elamandeep commented Jul 29, 2022

daveidivide commented Jul 29, 2022 • edited

monsieurnebo commented Jul 29, 2022

ijjk commented Jul 29, 2022 • edited

monsieurnebo commented Jul 29, 2022

gee06robson commented Jul 29, 2022

elamandeep commented Jul 30, 2022

youzooyou commented Aug 1, 2022

bryanltobing commented Aug 1, 2022

johnb0 commented Aug 1, 2022

daveidivide commented Aug 1, 2022

elamandeep commented Aug 1, 2022

ShazamShakeel commented Aug 2, 2022 • edited

youzooyou commented Aug 2, 2022

johnb0 commented Aug 2, 2022

youzooyou commented Aug 2, 2022 • edited

Tuno88 commented Aug 3, 2022

darkpiv commented Aug 3, 2022

darkpiv commented Aug 3, 2022

monsieurnebo commented Aug 3, 2022

elamandeep commented Aug 4, 2022

tonyYo00 commented Aug 5, 2022

zodman commented Aug 5, 2022

denysderihlazov commented Aug 10, 2022 • edited

denysderihlazov commented Aug 10, 2022

monsieurnebo commented Aug 10, 2022

azihassan commented Aug 11, 2022 • edited

johnb0 commented Aug 12, 2022

github-actions bot commented Oct 8, 2022

GRIM-xx commented Jul 25, 2022 •

edited

hunghg2505 commented Jul 25, 2022 •

edited

domosedov commented Jul 27, 2022 •

edited

daveidivide commented Jul 29, 2022 •

edited

ijjk commented Jul 29, 2022 •

edited

ShazamShakeel commented Aug 2, 2022 •

edited

youzooyou commented Aug 2, 2022 •

edited

denysderihlazov commented Aug 10, 2022 •

edited

azihassan commented Aug 11, 2022 •

edited