Next.js server returns connection: close header for all routes
#51592
Comments
github-actions
bot
added
Runtime
|
Perhaps it's related with this issue ? 51605 |
|
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 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. |
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. |
|
@NadhifRadityo it's not clear (at least to me) from the code you link to why that's resulting in a |
|
After further digging into the code, I have a small working patch to make the server utilizes keep-alive connections. Edit the file const proxyServer = httpProxy.createProxy({
target: targetUrl,
changeOrigin: false,
ignorePath: true,
xfwd: true,
ws: true,
followRedirects: false,
+ agent: new (require("http")).Agent({
+ keepAlive: true
+ })
});Explanation:
By setting a custom agent,
|
|
I noticed Next.js changed its request proxying recently. Currently, Next.js uses built-in fetch instead of In the latest canary version, next.js/packages/next/src/server/lib/router-server.ts Lines 368 to 376 in 2b38118 next.js/packages/next/src/server/lib/server-ipc/invoke-request.ts Lines 27 to 46 in 2b38118 If you think the problem no longer exists, please consider closing this issue. Thank you! |
|
I had same problem with docker based on |
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 |
|
I am facing this error |
|
@autsada had a similar issue |
|
facing a similar issue... using api endpoints with
export async function POST(req: Request) {
...some logic
let tmp = new URL(path, req.url);
tmp.searchParams.set("updated", "true");
return NextResponse.redirect(tmp);
}
the api page acted perfectly, but when redirected, the issue throws.(refreshing the redirected page, it shows normally) |
|
@PassionPenguin You can use: to solve your issue. I bet you were using redirect() in a POST route handler? If that's the case then you can use the workaround of Response.redirect. The Next.js team will have to fix redirect() probably. It turns out any |
yes u're correct! thx!!!! |
…handlers (#58885) ### What? Calling `redirect` or `permanentRedirect` with a route handler used by a server action will result in that POST request following the redirect. This could result in unexpected behavior, such as re-submitting an action (in the case where the redirected URL makes use of the same server action). ### Why? By spec, 307 and 308 status codes will attempt to reuse the original request method & body on the redirected URL. ### How? In all cases when calling a `redirect` handler inside of an action, we'll return a `303 See Other` response which is a typical status code when redirecting to a success / confirmation page as a result of a POST/PUT. The other option would be to use 301 / 302 status codes, but since we're already doing a 303 status code [here](https://github.com/vercel/next.js/blob/canary/packages/next/src/server/app-render/action-handler.ts#L603), this aligns the behavior for the route handler case. Closes NEXT-1733 See also: #51592 (comment) [Slack x-ref](https://vercel.slack.com/archives/C03S8ED1DKM/p1700060786749079)
Verify 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.3Which 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
npx create-next-app@latestnpx next devlocalhostand note that in the Response headersconnection: closeis listed. Select other requests and note the same header is sent for all responses.npx next buildto build the app, then runnpx next startto run itDescribe 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: closeresponse header to clients when rendering routes. This instructs the client to close the underlying TCP connection, rather than returningconnection: keep-alivewhich 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
The text was updated successfully, but these errors were encountered: