Please expose keepAliveTimeout and headersTimeout without requiring a custom server

[tabuchid]

Describe the feature you'd like to request

When deploying behind a load balancer its good to configure the application server with a longer timeout than the load balancer. See AWS ALB reccomendation

We also recommend that you configure the idle timeout of your application to be larger than the idle timeout configured for the load balancer.

AWS defaults a ALB to a 60 second idle timeout so it would be desirable to configure next to have a 61 second timeout.

It looks like this has been discussed in a few places with little to no response from the maintainers:

• AWS ECS & ALB & CloudFront. sometimes happed status code 502 #16544
• Is there a way to modify the keepAliveTimeout without using a custom server? #19618
• Allow a configurable keep alive timeout in next config #22204

Here is a discussion of a similar issue in node. nodejs/node#27363
and two blogs about people hitting similar issues with ALB's generating 502s using express servers where the solution was to increase the keepAliveTimeout.

• https://adamcrowder.net/posts/node-express-api-and-aws-alb-502/
• https://shuheikagawa.com/blog/2019/04/25/keep-alive-timeout/

Describe the solution you'd like

Allow setting keepAliveTimeout and headersTimeout.

Describe alternatives you've considered

Ugly hacks

We are doing something similar to patch, just an awk on the bundle after build. As patch replaces the whole file (IIRC) it’s more likely to break things than a regex search and insert.

#19618 (comment)

We're using patch-package to fix this issue, please make server.keepAliveTimeout a next.js settings 🙏🏻

#19618 (comment)

or setting the ALB/ELB to a timeout of 4 seconds

Heya the only solution I was able to find was to modify the IdleTimeout on the AWS ELB to be 4 seconds, i.e 1 second less than node's default 5 seconds.

#16544 (comment)

[tabuchid]

@timneutkens Since this was converted to a discussion. Do you care to discuss?

[onordgren]

Any good way of solving this for apps running in standalone mode? Would it be a possibility to be able to set this with a env var that can be picked up in the standalone server.js?

[Miikis]

@onordgren I don't think there's any env var for keep-alive timeouts. I have a workaround idea — that I haven't tried yet — but it should work I think:

The custom-server Next.js generates is a bare-bones, Node.js http-server. The idea is to add a post-build step (in your CI, container etc.) that updates node's http-server's keep-alive timeout settings.

So, you have Next.js that generate a standalone server that looks something like:

const NextServer = require('next/dist/server/next-server').default
const http = require('http')
const path = require('path')
process.env.NODE_ENV = 'production'
process.chdir(__dirname)

// Make sure commands gracefully respect termination signals (e.g. from Docker)
// Allow the graceful termination to be manually configurable
if (!process.env.NEXT_MANUAL_SIG_HANDLE) {
  process.on('SIGTERM', () => process.exit(0))
  process.on('SIGINT', () => process.exit(0))
}

let handler

const server = http.createServer(async (req, res) => {
  try {
    await handler(req, res)
  } catch (err) {
    console.error(err);
    res.statusCode = 500
    res.end('internal server error')
  }
})
const currentPort = parseInt(process.env.PORT, 10) || 3000
const hostname = process.env.HOSTNAME || 'localhost'

server.listen(currentPort, (err) => {
  if (err) {
    console.error("Failed to start server", err)
    process.exit(1)
  }
  const nextServer = new NextServer({
    hostname,
    port: currentPort,
    dir: path.join(__dirname),
    dev: false,
    customServer: false,
    conf: {},
  })
  handler = nextServer.getRequestHandler()

  console.log(
    'Listening on port',
    currentPort,
    'url: http://' + hostname + ':' + currentPort
  )
})

and you then sed (or whatever tool you want to use) something like the below:

const KEEP_ALIVE_TIMEOUT = 70 * 1000;
server.keepAliveTimeout = KEEP_ALIVE_TIMEOUT;
server.headersTimeout = KEEP_ALIVE_TIMEOUT * 1.1;

Report back if you try it out :)

[onordgren]

Hey @Miikis! Thx for the suggestion :) We are actually already doing something similar in our docker file, like below

RUN echo ";server.keepAliveTimeout = 620000;" >> ./server.js

It works fine but it felt a bit hacky and potentially error prone when/if server.js implementation changes.

An env var similar to how process.env.NEXT_MANUAL_SIG_HANDLE works would be great for this, at least in my head but maybe there was a reason for not doing this with env vars.

[Miikis]

@onordgren Nice! Glad to see it works. I second the env var feature too, tho — I think Next is just waiting for a PR from the community tho at this point lol

[aNyMoRe0505]

@Miikis
Thank you for your PR.
I'd like to confirm whether the PR does not include headersTimeout.
If not, I would like to ask how you addressed the issue
Thank you

[nelson-lark]

any momentum on this? Or any workaround gist?

[timneutkens]

As said feel free to open a PR.
#28642 (reply in thread)

[jessethomson]

For those using standalone mode:

With this change to NextJS, it looks like you can now use a KEEP_ALIVE_TIMEOUT environment variable to set the keepAliveTimeout value on the server.

Unfortunately, I don't see this documented anywhere so this was very hard to find.

I should add that from what I can tell, there is still no way to set the headersTimeout value (without hacking some code into node_modules or dist). However, it's not clear to me if that is still needed or not. It seems others have mentioned this commit on NodeJS and maybe this change in NodeJS means everything is fine without headersTimeout? I'm not sure, but would love if someone could shed some light on that.

[cyounkins]

I can confirm setting ENV KEEP_ALIVE_TIMEOUT 61000 in our Dockerfile immediately eliminated our random 502's. 61 sec is appropriate for our environment with a 60 sec timeout in the load balancer.