Next.js server returns `connection: close` header for all routes

[DamianEdwards]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.1.0: Sun Oct  9 20:14:30 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T8103
    Binaries:
      Node: 20.3.0
      npm: 9.6.7
      Yarn: 1.22.19
      pnpm: N/A
    Relevant packages:
      next: 13.4.7-canary.2
      eslint-config-next: 13.4.6
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.3

Which area(s) of Next.js are affected? (leave empty if unsure)

Middleware / Edge (API routes, runtime), Standalone mode (output: "standalone")

Link to the code that reproduces this issue or a replay of the bug

npx create-next-app

To Reproduce

1. Create a new app using npx create-next-app@latest
2. Run the app using npx next dev
3. Launch a browser and open the Network tab in the developer tools
4. Navigate to http://localhost:3000
5. In the Network tab, select the request for localhost and note that in the Response headers connection: close is listed. Select other requests and note the same header is sent for all responses.
6. Back in the terminal, Ctrl+C to stop the dev server
7. Run npx next build to build the app, then run npx next start to run it
8. Back in the browser, refresh the page and observe that the same behavior is present once the app is built

Describe the Bug

The nodejs server created by Next.js, whether it be in dev mode, production mode after building, or production mode when standalone deployment is configured, returns a connection: close response header to clients when rendering routes. This instructs the client to close the underlying TCP connection, rather than returning connection: keep-alive which allows the client to reuse the TCP connection when making subsequent requests, greatly reducing latency. This behavior is leading to high latencies for server-rendered Next.js routes.

I reproduced this behavior on multiple machines, including OSX and Windows 11, on multiple versions of nodejs, including latest LTS and Current releases, using next 13.4.x and canary, with multiple browsers including Edge and Firefox.

Expected Behavior

The nodejs server created by Next.js should utilize HTTP 1.1 keep-alive to allow clients to keep TCP connections open.

Which browser are you using? (if relevant)

Edge, Firefox

How are you deploying your application? (if relevant)

next start

[flux0uz]

Perhaps it's related with this issue ? 51605

[NadhifRadityo]

This is happening because of how Nextjs handles incoming packets. By default, Nextjs will start two HTTP servers. One server sits in the main thread that acts like a proxy, and another thread sits in a forked mode, where your main app will be running (See start-server.ts#L240).

I think the devs structured this way to avoid memory leaks. If the memory usage on the forked thread exceeds a certain threshold, the main thread simply restarts the forked thread without killing the main HTTP server.

Now, back to the main question. Why does it put Connection: close to the header? The problem is how the packets are relayed to the forked thread. Nextjs uses a library called http-proxy (See start-server.ts#L255) which just proxies incoming request and relays it to another server (in this case the other HTTP server that sits on forked thread). Internally the library doesn't handle keepalive connections. Thus, it appends Connection: close to the header. Edit: Nope, the library does support keep-alive connection under some conditions (See node-http-proxy/.../web-outgoing.js#L46).

An alternative solution would be turning off the worker thread, but the devs have not given that an option yet (See next-dev.ts#L220). Typically, Nextjs only handles web server and should not handle anything else, as it will create more complexities on the project. Personally, I would just put a reverse proxy (like nginx) in front of Nextjs server. Thus, making closed TCP connection not much of a big deal.

[NadhifRadityo]

Perhaps it's related with this issue ? 51605

I read the stack trace and it starts with TLSSocket. And if I am not mistaken, Nextjs doesn't handle TLS/SSL. Furthermore, referring to my former comment, when the main thread relays the request to the forked thread, it uses plain old HTTP.

[DamianEdwards]

@NadhifRadityo it's not clear (at least to me) from the code you link to why that's resulting in a connection: close header. To my understanding, Node will only respond with connection: close if keep-alive is explicitly disabled by setting server.keepAliveTimeout to 0. The keep-alive timeout is accepted as a parameter that defaults to null and is only set on the server if it's not null, so 0 would need to be passed in, or some other part of the server logic is causing the issue.

[NadhifRadityo]

After further digging into the code, I have a small working patch to make the server utilizes keep-alive connections.

Edit the file node_modules/next/dist/server/lib/start-server.js starting at line 221 to the following patch:

const proxyServer = httpProxy.createProxy({
    target: targetUrl,
    changeOrigin: false,
    ignorePath: true,
    xfwd: true,
    ws: true,
    followRedirects: false,
+    agent: new (require("http")).Agent({
+        keepAlive: true
+    })
});

Explanation:
Apparently, my former comment was partially correct. After a bit of experimenting, I realized:

1. The forked thread did not put Connection: close to the response header (and server.keepAliveTimeout is the node's default value by the documentation you mentioned.)
   

   next.js/packages/next/src/server/lib/render-server.ts

   Lines 81 to 83 in 57ab281

   	if (opts.keepAliveTimeout) {
   	server.keepAliveTimeout = opts.keepAliveTimeout
   	}

2. The proxied response already has Connection: close. Now this is a bit weird. Because the original request specified Connection: keep-alive, but the server responded otherwise.
3. The http-proxy library explicitly sets Connection: close to the proxied request. This explains why the server responded Connection: close on point 2.
   https://github.com/http-party/node-http-proxy/blob/9b96cd725127a024dabebec6c7ea8c807272223d/lib/http-proxy/common.js#L62-L74

By setting a custom agent, http-proxy will use that agent to manage live TCP connections. Currently, a manual patch is required, since Nextjs don't have options to manage http-proxy yet.

Note: The same patch probably also applies to IPC communications between Next's router and Next's actual page renderer.

next.js/packages/next/src/server/lib/server-ipc/invoke-request.ts

Lines 26 to 31 in 57ab281

	const invokeReq = http.request(
	parsedTargetUrl.toString(),
	{
	headers: invokeHeaders,
	method: requestInit.method,
	},

[NadhifRadityo]

I noticed Next.js changed its request proxying recently. Currently, Next.js uses built-in fetch instead of http-proxy for basic HTTP request. These changes made the Connection header as-is, as opposed to the http-proxy which overrides the header.

In the latest canary version, Connection header already defaulted to keep-alive with timeout of 5 seconds (which is the default nodejs http keep-alive timeout).
For reference, please see the following snippets:

next.js/packages/next/src/server/lib/router-server.ts

Lines 368 to 376 in 2b38118

	invokeRes = await invokeRequest(
	renderUrl,
	{
	headers: invokeHeaders,
	method: req.method,
	signal: signalFromNodeResponse(res),
	},
	getRequestMeta(req, '__NEXT_CLONABLE_BODY')?.cloneBodyStream()
	)

next.js/packages/next/src/server/lib/server-ipc/invoke-request.ts

Lines 27 to 46 in 2b38118

	return await fetch(parsedTargetUrl.toString(), {
	headers: invokeHeaders as any as Headers,
	method: requestInit.method,
	redirect: 'manual',
	signal: requestInit.signal,
	...(requestInit.method !== 'GET' &&
	requestInit.method !== 'HEAD' &&
	readableBody
	? {
	body: readableBody as BodyInit,
	duplex: 'half',
	}
	: {}),
	next: {
	// @ts-ignore
	internal: true,
	},
	})

If you think the problem no longer exists, please consider closing this issue. Thank you!

[ugurrdemirel]

I had same problem with docker based on node:20-bookworm image and tried node:20-alpine as well. When I changed to node:19, it fixed the issue. Hope this helps

[NadhifRadityo]

I had same problem with docker based on node:20-bookworm image and tried node:20-alpine as well. When I changed to node:19, it fixed the issue. Hope this helps

I think there is (or should be) NO correlation between node version 19/20 that made the connection header keep-alive by itself. Since the behaviour is based on Next.js' code handling request. Can you confirm that you were running the same Next.js version?

Though, this issue is actually been resolved by the latest Next.js version, as per my last message.

[ugurrdemirel]

I think there is (or should be) NO correlation between node version 19/20 that made the connection header keep-alive by itself. Since the behaviour is based on Next.js' code handling request. Can you confirm that you were running the same Next.js version?

Though, this issue is actually been resolved by the latest Next.js version, as per my last message.

I was facing this issue on next@13.4.12. I tried to install latest nextjs version which was next@13.4.18. I removed both .next & node_modules folders from my project to avoid any cache or something and I build the project again. The result was same. Then I've become the man who hits every key to pass the level and tried to change nodejs version from docker and it fixed it.

[autsada]

I am facing this error Error: Connection closed. at c on one specific route when deployed to Vercel. This route works fine in the local build. I used next@13.5.4 and also tried to downgrade to several versions, but none worked.

[ColeTownsend]

@autsada had a similar issue