🐛 BUG: wrangler dev listens only on ipv4 localhost, not ipv6

[kentonv]

What version of Wrangler are you using?

2.6.2

What operating system are you using?

Linux

Describe the Bug

wrangler dev (with --experimental-local in my case, not sure if that matters) says that it listens on localhost:8787, but when it says this, it is actually listening specifically on 127.0.0.1:8787. On systems that support ipv6, the hostname localhost resolves to two different addresses, ::1 and 127.0.0.1. wrangler dev does not appear to listen on [::1]:8787.

This is usually not a problem, as "correct" programs (e.g. web browsers, curl, or workerd) will try all addresses returned by the DNS query until one of them works. However, Node 18's fetch() function only attempts the first address, throwing an exception if that fails. The first address is always ::1, therefore fetch("localhost:8787") always fails in Node.

Arguably both Node and Wrangler are buggy here. Node should be trying all matching addresses, but Wrangler should also be binding to all matching addresses. Fixing the bug on either side solves the specific problem.

(In my case, I am developing a SvelteKit app with a separate Workers-based backend. Although the SvelteKit app is intended to run on Workers itself, it's easiest to develop using the SvelteKit development workflow on Vite, which uses Node. I wanted it to talk to my local wrangler dev instance and ran into this issue.)

[JacobMGEvans]

(In my case, I am developing a SvelteKit app with a separate Workers-based backend. Although the SvelteKit app is intended to run on Workers itself, it's easiest to develop using the SvelteKit development workflow on Vite, which uses Node. I wanted it to talk to my local wrangler dev instance and ran into this issue.)

Interesting! Can definitely take a look at this, thanks for the report Kenton 😃

[yoav-lavi]

Hey!

Wanted to add our experience with this:

We have a CLI that (among other functionality) simulates our production generated user API by running a few of our workers locally in miniflare.

We normally start a miniflare at 127.0.0.1:PORT (normally 4000) but we’ve been seeing some issues when people try to use localhost from an IPv6 based application, since localhost translates to ::1 rather than 127.0.0.1.

We'd love to be able to listen on both IPv4 and IPv6 to avoid these cases.

Thanks!

[jspspike]

This fix for this is in miniflare so I will be transferring the issue there

[lrapoport-cf]

reopening because #3733 was reverted with #4014

[Sammy-T]

I'm encountering this issue running a local pages environment. Related #2244