Deno ListenOptions hostname does not bind to ipv6 by default

[itspa1]

When a hostname is not provided to a method the ListenOptions defaults it to 0.0.0.0, the process binds to only ipv4 address and for binding an ipv6 address it requires explicit mentioning via the hostname, for example, the hostname should be set to [::1] to bind it to an ipv6 address and so on. Need to check whether to bind the ipv6 address by default, or keep the same functionality as of now.

[shortdiv]

Related discussion in #5144

[SikoJobs]

Honestly, I think it would be better to bind both 0.0.0.0 and [::] by default if IPv6 is available on the operating system. IPv6 will become mainstream in the future, and Deno should face to the future.

[itspa1]

update on if this needs to change or not?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bodograumann]

As mentioned here binding to [::] is enough to handle both IPv4 and IPv6 requests. This should really be the default these days.

I just got stung by this issue. Somehow localhost is resolved to IPv6 by default now on my Arch Linux, so the deno server was not reachable anymore and it was a real pain to even find the issue.

[ghost]

I have found on Windows 10 that it is actually only possible to listen on either IPv6 or IPv4, not sure why that is, so I can not have Deno listen to both IPv4 and IPv6 at the same time, I wanted to switch from Node.js which is HORRIBLY insecure to Deno but when the most basic of things doesn't work properly or as expected, it kind of put a damper on putting in the work to move over.

Here's to hoping this gets proper attention because this is just annoying.

Just a small addition, I did just try to connect to both 127.0.0.1 and also local network IP 10.0.0.242 neither respond to requests but if I enter the IPv6 address of the machine it answers when listening on :: so yeah, that should respond to both IPv6 and IPv4 and ::1 should respond only to IPv6! So as it stands at least on Windows, it is not possible to listen to both socket types, and you can't just run another copy of Deno as the port number is in use. So if you want a web server on Windows using Deno you can either have IPv4 (by default) or IPv6 but NOT both.

[bnoordhuis]

As mentioned here binding to [::] is enough to handle both IPv4 and IPv6 requests.

That's not universally true, notably on openbsd.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[ghost]

This is still an ongoing issue that needs work so go away stale bot, we're not letting this go!

[treysis]

I have found on Windows 10 that it is actually only possible to listen on either IPv6 or IPv4, not sure why that is, so I can not have Deno listen to both IPv4 and IPv6 at the same time

On Windows, you need to set IPV6_V6ONLY for the socket to false, as the default value on Windows - contrary to Linux - is true.

[hansSchall]

I did some testing on Windows 11 (with Deno.serve) and would like to share my findings.

1. Deno.serve({ hostname: "::" }, /* ... */); and Deno.serve({ hostname: "[::]" }, /* ... */); are equivalent.
2. Deno.serve({ hostname: "::" }, /* ... */); and Deno.serve({ hostname: "0.0.0.0" }, /* ... */); both work when using localhost, but when using my own IP or 127.0.0.1/::1 only the same IP family works.
3. In order to support IPv4 and IPv6 at the same time, I had to call Deno.serve twice, fortunately this works even on the same port.

Until IPv6 is supported by default, this workaround can be used (example with Hono):

const app = new Hono();

app.get("/foo", ...);

Deno.serve({
    port: 80,
    hostname: "::"
}, app.fetch);

Deno.serve({
    port: 80,
    hostname: "0.0.0.0"
}, app.fetch);

[empz]

+1 to automatically bind both ipv4 and ipv6 addresses, or at least provide a flag to Deno.serve.

Not binding to IPv6 addresses break the experience of running private Deno apps in platforms like Fly.io.

[fry69]

I encountered issues running Deno in a rootless Podman container on an IPv6-only network. The runtime was unable to make outbound HTTP(S) requests, which broke both the initial module resolution (likely due to integrity checks) and application-level API calls. This setup works for other tools that correctly support IPv6 networking.

Podman now defaults to the pasta network stack in rootless mode, which mirrors the host's IPv6 config. Kubernetes also supports IPv6-only clusters, with outbound IPv4 handled via NAT64. These environments are increasingly common (AWS), and tools like Deno need to support them reliably.

Binding only to 127.0.0.1 or 0.0.0.0 and relying solely on IPv4 for outbound requests makes Deno incompatible out-of-the-box in these cases. A more robust approach would be dual binding ([::1] and [::]) and full support for IPv6-based outbound connections. A feature flag or environment-based configuration might be a good compromise if changing the default isn't viable.

+1 for improving IPv6 support in Deno