Error: connect ECONNREFUSED

[dincerpece]

Verify canary release

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

Provide environment information

Operating System:
      Platform: win32
      Arch: x64
      Version: Windows 10 Pro
    Binaries:
      Node: 18.15.0
      npm: N/A
      Yarn: N/A
      pnpm: N/A
    Relevant Packages:
      next: 13.4.8
      eslint-config-next: 13.4.7
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.3
    Next.js Config:
      output: N/A

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

No response

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

i am running my project on big localhost

To Reproduce

Describe the Bug

I get an error on next custom server both in production and development mode for nextjs 13.4.7 and later.

Expected Behavior

I expect it to work normally on my nextjs custom server like next dev and next start. 13.4.6 works fine on 13.4.7 and later I get this error.

Which browser are you using? (if relevant)

Chrome 114.0.5735.199

How are you deploying your application? (if relevant)

localhost, next custom server

[oriolgm]

I got this error too, I was able to fix it by changing host from localhost to 127.0.0.1 while creating the app on the custom server, but it seemed to me a breaking change.

[schimi-dev]

It seems that this problem occurrs since the below pull request that was added in v13.4.7-canary.0:
#51378

It seems that some part of the application's IPC still tries to use IPv6 if localhost resolves to an IPv6 address but cannot do so (for a reason I don't understand). In the Pull Request the IP address used for IPC was locked to 0.0.0.0, so my understanding is that this issue occurrs when localhost resolves to an IPv6 address while IPC seems locked to IPv4. You can see in your log that the address in your case is an IPv6 address.

Setting the HOSTNAME environment variable to an IPv4 address solves this problem, but I think that this might be something that is worth looking into by the maintainers.

Best regards,

Michael

[schimi-dev]

Moreover, this issue seems related to: #51684

[dincerpece]

Yes, on my custom server, when I set the hostname to 127.0.0.1, I was able to connect with localhost.Thanks.

[vinceve]

Even without a custom server and/or https it is occuring. Seems like a regression!

[michaelangeloio]

Yes, on my custom server, when I set the hostname to 127.0.0.1, I was able to connect with localhost.Thanks.

I don't think setting it to 127.0.0.1 is the solution. What about when you deploy it? How will it bind to 0.0.0.0?

[dincerpece]

If I connect with ip in local, it works naturally, even though it gives a certificate problem with 127.0.0.1. localhost is already fine. I don't have any problems on the server side either. This is fixed anyway, as a temporary solution, at least I can work like this right now.

[balazsorban44]

I'll close it as a duplicate of #51684 which we already track internally. Follow that thread for updates, and leave comments there, thanks!

[github-actions]

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.