next.js: [NEXT-1336] Cannot run with custom https at localhost

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 23.0.0: Tue Jun 13 21:16:44 PDT 2023; root:xnu-10002.0.116.505.3~3/RELEASE_ARM64_T6000
    Binaries:
      Node: 18.16.0
      npm: 9.5.1
      Yarn: 1.22.19
      pnpm: 8.6.2
    Relevant packages:
      next: 13.4.7
      eslint-config-next: 13.4.7
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.0.4

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

Middleware / Edge (API routes, runtime)

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

https://app.replay.io/recording/cannot-start-serverjs-at-localhost--df722455-73b5-4762-9a1a-aa18008a907c

To Reproduce

I have custom server to run https at local host as bellow, it’s works well with pervious next version. But it’s occurs on v13.4.7

const { createServer } = require('https')
const { parse } = require('url')
const next = require('next')
const fs = require('fs')
const port = 3001
const dev = process.env.NODE_ENV !== 'production'
const app = next({ dev })
const handle = app.getRequestHandler()

const httpsOptions = {
  key: fs.readFileSync(process.cwd() + '/config/localhost-key.pem'),
  cert: fs.readFileSync(process.cwd() + '/config/localhost.pem')
}

app.prepare().then(() => {
  createServer(httpsOptions, async (req, res) => {
    const parsedUrl = parse(req.url, true)
    await handle(req, res, parsedUrl)
  }).listen(port, (err) => {
    if (err) throw err
    console.log('ready - started server on url: https://localhost:' + port)
  })
})

Describe the Bug

yarn run v1.22.19
$ cross-env APP_ENV=development node server.js
ready - started server on url: https://localhost:3001
- event compiled client and server successfully in 88 ms (20 modules)
- wait compiling...
- event compiled client and server successfully in 74 ms (20 modules)
Error: connect ECONNREFUSED ::1:53504
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16) {
  errno: -61,
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '::1',
  port: 53504
}
Error: connect ECONNREFUSED ::1:53504
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16) {
  errno: -61,
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '::1',
  port: 53504
}

Expected Behavior

Expect it will run without Error:

Error: connect ECONNREFUSED ::1:53504
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16) {
  errno: -61,
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '::1',
  port: 53504
}

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

_NEXT-1336

About this issue

Original URL
State: open
Created a year ago
Reactions: 9
Comments: 17 (7 by maintainers)

Most upvoted comments

Edit: It seems that this workaround is no longer needed for our apps as of next@13.5.4 🙌 - now we can remove hostname or set hostname: 'localhost' with no problems.

Workaround

I can confirm, switching our hostname from 'localhost' to '127.0.0.1' in our custom server worked for next@13.4.7 (at least for a temporary fix - not sure about the potential downsides of doing this):

const app = next({
-  hostname: 'localhost',
+  // Use '127.0.0.1' instead of 'localhost' to temporarily work around issues
+  // with ECONNREFUSED (connection refused) errors with high port numbers
+  // https://github.com/vercel/next.js/issues/51684#issuecomment-1609345705
+  //
+  // TODO: Revert to 'localhost' when the issue is resolved https://github.com/vercel/next.js/issues/51684
+  hostname: '127.0.0.1',

Thanks for the tip @greifmatthias 🙌

I guess this bug should probably stay open though, since it’s still broken for anyone using hostname: 'localhost' 🤔

+12

karlhorky on Oct 4, 2023

This is particularly annoying problem for output: 'standalone' because the server gets autogenerated and it passes the hostname as localhost by default.

You can overwrite it with HOSTNAME=127.0.0.1 npm run start although I wouldn’t expect devs to have to define the HOSTNAME var everytime they want to test the built app.

Also the static and public folders should have an option to be symlinked in the config in my opinion.

moshie on Jun 29, 2023

What about when you deploy it? How will it bind to 0.0.0.0?

I don’t know what you mean with this, but I can confirm that deploying our app to production (it is a Custom Server with Express in front of it, deployed to Render) works for us.

Maybe not a solution for non-Custom Server deployments? Maybe some other people who added a thumbs-up to my post can respond about whether deploying to production worked for them? (and which hosting provider / configuration, if possible)

karlhorky on Jul 5, 2023

I have been unable to update from next@13.4.6 to next@13.4.7 to because of ECONNREFUSED. The app builds but the standalone Next.js instance returns Internal server error on every request. Node process output is full of messages like this one:

Error: connect ECONNREFUSED ::1:36901
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1481:16) {
  errno: -111,
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '::1',
  port: 36901
}

Interestingly, this error only manifests itself when I run node server.js (standalone). Running pnpm next start works, although with a warning:

- warn "next start" does not work with "output: standalone" configuration. Use "node .next/standalone/server.js" instead.

I have reverted the version for now, my current best guess is that the error is related to https://github.com/vercel/next.js/pull/51378.

kachkaev on Jun 25, 2023

@karlhorky Yeah, I realize this was my issue: https://github.com/vercel/next.js/issues/52215#issuecomment-1622400161

Sorry for the confusion!

michaelangeloio on Jul 6, 2023

I know this might be completely unrelated but I was trying to do this on my own cloud and faced this issue with

next v13.4.0
ubuntu 22.04
node v18.16.1

I solved this by switching to

node v16.20.0

Just keeping this comment here in case it benefits someone.

stackyism on Sep 5, 2023

Lol 4 minutes later, got it working by checking the code of #51378 . Changed hostname from localhost to 127.0.0.1 and works like before.

greifmatthias on Jun 27, 2023