Node.js server fails to bind on ipv6 if ipv4 is not available

[Olafcio1]

Version

v24.18.1

Platform

Linux ssh2 6.18.43-alwaysdata #1 SMP PREEMPT_DYNAMIC Fri Aug  7 07:39:43 UTC 2026 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

1. Run a HTTP server (code below)
2. Try to connect to it (via e.g. python, netcat, a browser etc.)

code:

const http = require("http");
const server = http.createServer((req,res)=>{
     res.writeHead(200, "Content-Type", "text/plain");
     res.write("ok");
     res.end();
});

server.listen({ port: 8300 }, ()=> {
    console.log("Server is running");
});

I also tried all the following:

server.listen({ port: 8300, host: "::" }, ()=> {
    console.log("Server is running");
});

server.listen({ port: 8300, host: "::", ipv6Only: true }, ()=> {
    console.log("Server is running");
});

server.listen({ port: 8300, host: "", ipv6Only: true }, ()=> {
    console.log("Server is running");
});

server.listen({ port: 8300, host: "0.0.0.0", ipv6Only: true }, ()=> {
    console.log("Server is running");
});

server.listen({ port: 8300, host: "::1", ipv6Only: true }, ()=> {
    console.log("Server is running");
});

server.listen({ port: 8300, host: "" }, ()=> {
    console.log("Server is running");
});

server.listen(8300, "::", ()=> {
    console.log("Server is running");
});

server.listen(8300, "", ()=> {
    console.log("Server is running");
});

// maybe even more i forgot

How often does it reproduce? Is there a required condition?

TCPv4 must not be available on the OS.
For example, netstat -lntp must say this:

netstat: no support for `AF INET (tcp)' on this system.

netstat -lntp6 must not say that, however - instead, it should succeed:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name

What is the expected behavior? Why is that the expected behavior?

The server should be accessible

What do you see instead?

No error is thrown or logged, however, I cannot connect to the server in any imaginable way

Additional information

edit: offensive comment removed by moderator

[suii2210]

hey I wanna work on this issue

[efekrskl]

Thanks for reporting this issue!

However, I must note that Node.js is largely maintained by volunteers, and I don't think your remarks about Node.js are particularly fair or constructive toward the people spending their time contributing to the project. Could you remove this section?

Thx for the ai-generated slop which is node.js nowadays.
Why does every single project have to use this?
It's not like I have a choice on whether to use node.js or not, if I don't want to spend a lot of money nor a lot of time, and I'm trying to host something in javascript, I do have to use Node.js. And there's only 1, one single Node.js alternative that doesn't use AI, that seems good, that I found. Yeah, I love my life...

@suii2210 we usually don't assign issues, so feel free to work on this.

[avivkeller]

Thx for the ai-generated slop which is node.js nowadays.
Why does every single project have to use this?
It's not like I have a choice on whether to use node.js or not, if I don't want to spend a lot of money nor > a lot of time, and I'm trying to host something in javascript, I do have to use Node.js. And there's only 1, one single Node.js alternative that doesn't use AI, that seems good, that
I found. Yeah, I love my life...

This a completely unrelated and unfair remark against the project. Node.js adopts an AI Policy to ensure that code generated with the assistance of AI toolings is vetted to the same high standard (if not higher) that human written code is. Calling Node.js "ai-generated slop" is disrespectful to every collaborator, contributor, and community member that volunteers their time to maintain this project. As said above, please self moderate and delete the offending content, and I suggest that you rethink your definition of "ai-generated slop".

[MikeMcC399]

@suii2210

hey I wanna work on this issue

Since you have now submitted PR #65669 please let us know:

• Were you able to reproduce the issue reported here?
• Is net: fallback to IPv6-only when dual-stack bind fails #65669 intended to resolve this issue (fully or partially)?

[suii2210]

@suii2210

hey I wanna work on this issue

Since you have now submitted PR #65669 please let us know:

• Were you able to reproduce the issue reported here?
• Is net: fallback to IPv6-only when dual-stack bind fails #65669 intended to resolve this issue (fully or partially)?

I have not reproduced the original issue on a real IPv6-only host. The regression test in this PR simulates EAFNOSUPPORT during the default dual-stack IPv6 bind and verifies that Node retries with an IPv6-only socket.
Therefore, this PR is intended as a partial fix for that specific EAFNOSUPPORT fallback case. I cannot yet confirm that it completely fixes the reported unreachable-server behavior or the explicit ipv6Only: true cases.