accept-dns=true causes ECONNRESET for all fetches from Bun runtime on macOS (Intel), curl unaffected

What is the issue?

With Tailscale connected and accept-dns enabled, every outbound HTTPS request made from the Bun JavaScript runtime fails immediately with ECONNRESET, to any host. curl from the same shell, same machine, same moment, succeeds normally.

Setting --accept-dns=false fixes it instantly, with Tailscale still up and the tailnet fully working.

IPv6 was also broken in the same state: curl -6 to any host reset immediately, and started working again after --accept-dns=false.

Expected: fetch() should succeed, as curl and other system-resolver-based clients do under the same network configuration.

Resolvers while failing: 100.100.100.100, 192.168.4.1, fd7a:115c:a1e0::53

An arm64 Mac (M2) on the same tailnet, same Tailscale version, same Bun version, same network does not reproduce. Only the Intel machine is affected.

Ruled out during diagnosis:

• macOS application firewall — disabled entirely, no change
• Code signing / quarantine — valid Developer ID signature, no quarantine attribute
• Screen Time content filter — webfilterproxyd and webfilterDNSd killed, no change
• Bun version — 1.3.11 and 1.4.2 both affected
• Corrupt install — clean reinstall via install script, still affected
• No exit node configured, no subnet routes in use

tcpdump with Tailscale down shows a normal, complete TLS session (full handshake, ~6.8 KB transferred, clean FIN). No RST on the wire in the working case.

Bun ships its own DNS resolver rather than using the macOS system resolver APIs, which I suspect is the relevant difference from curl, but I have not verified the mechanism.

Steps to reproduce

Three-state test, everything else held constant.

1. Tailscale up, accept-dns=true (default):

$ bun -e 'fetch("https://example.com").then(r=>console.log("OK:",r.status)).catch(e=>console.log("FAIL:",e.code))'
FAIL: ECONNRESET

$ curl -sS -o /dev/null -w '%{http_code}\n' https://example.com
200

2. Tailscale down:

$ tailscale down
$ bun -e 'fetch("https://example.com").then(r=>console.log("OK:",r.status)).catch(e=>console.log("FAIL:",e.code))'
OK: 200

3. Tailscale up, accept-dns=false:

$ tailscale up
$ tailscale set --accept-dns=false
$ bun -e 'fetch("https://example.com").then(r=>console.log("OK:",r.status)).catch(e=>console.log("FAIL:",e.code))'
OK: 200

Fails against every host tried: example.com, registry.npmjs.org, api.anthropic.com. Not host-specific.

Are there any recent changes that introduced the issue?

No. This appears to be a long-standing interaction rather than a regression. Reproduced on Bun 1.3.11 and again after upgrading to 1.4.2.

OS

macOS

OS version

macOS 15.8 (24H23)

Tailscale version

1.102.4

Other software

Bun 1.4.2 (JavaScript runtime, x86_64 build) — this is the affected client. Also reproduced on Bun 1.3.11.

Claude Code 2.1.278, which ships as a Bun-compiled binary. This is how the issue surfaced: every outbound request it made (API, MCP registry, telemetry, OAuth login) failed with ECONNRESET while the machine's network was otherwise healthy.

Ruled out during diagnosis: macOS application firewall (socketfilterfw, disabled entirely with no change) and the Screen Time content filter (webfilterproxyd / webfilterDNSd, killed with no change).

Bug report

BUG-586df861e4084a6be0ec1118b7c3bab235b3364ca4bfa2855125fc934769d4a9-20260921115529Z-b9661c7c05c2224a