Repository navigation
opencode.ai resolves to four IPv6 addresses and stalls Bun fetch on IPv6 blackhole networks #36808
Description
Description
Over the past two days, multiple OpenCode users in China have reported that opencode-go becomes stuck indefinitely on networks with broken or blackholed IPv6. Other applications, including browsers accessing https://opencode.ai, quickly fall back to IPv4 and work normally.
opencode.ai returns exactly four AAAA records, while Bun/uSockets uses four concurrent connection slots. My hypothesis is that the four unreachable IPv6 addresses occupy every slot and block IPv4 fallback.
I reproduced this on dual-stack AWS by dropping TCP/443 only for the four IPv6 addresses while keeping IPv4 healthy. Bun 1.3.14 took 132 seconds to fall back to IPv4, and OpenCode v1.17.20 took approximately 133 seconds to receive an HTTP response. The test used the same OpenCode Go endpoint with dummy credentials because the delay occurs before authentication.
Could the number of AAAA records returned by opencode.ai be reduced from four to two as an immediate mitigation?
Related reports: #36029 and #35035. Related Bun issue: oven-sh/bun#33278
Plugins
None
OpenCode version
1.17.20 & v2 latest commit
Steps to reproduce
-
Use a dual-stack machine with working public IPv4 and IPv6.
-
Confirm that
opencode.aireturns four A and four AAAA records:dig @1.1.1.1 opencode.ai A +short dig @1.1.1.1 opencode.ai AAAA +short
-
Silently drop TCP/443 traffic to the four IPv6 addresses while leaving IPv4 working:
sudo nft add table inet opencode_repro sudo nft 'add chain inet opencode_repro output { type filter hook output priority -100; policy accept; }' sudo nft 'add rule inet opencode_repro output ip6 daddr { 2606:4700:78::90:0:140, 2606:4700:78::90:0:141, 2606:4700:78::90:0:142, 2606:4700:78::90:0:143 } tcp dport 443 counter drop'
-
Verify that IPv4 works while IPv6 times out:
curl -4 --connect-timeout 5 https://opencode.ai/ curl -6 --connect-timeout 5 https://opencode.ai/
-
Run OpenCode Go using an account with
opencode-goconfigured:time opencode run --model opencode-go/deepseek-v4-flash "Reply with hi"
-
The request should stall while the four IPv6 connections are blackholed. Compare with IPv6 disabled for the process:
time BUN_FEATURE_FLAG_DISABLE_IPV6=1 opencode run --model opencode-go/deepseek-v4-flash "Reply with hi"
Screenshot and/or share link
N/A. Reproduced with the commands above.
Operating System
Amazon Linux 2023, kernel 6.1.176-221.360.amzn2023.x86_64
Terminal
Not relevant; reproduced with non-interactive opencode run
Activity
github-actions commentedon Jul 14, 2026
This issue might be a duplicate of existing issues. Please check:
You've already referenced these in your report, which is great. Consider whether this issue adds new information (e.g., the hypothesis about four AAAA records filling all four connection slots, the AWS reproduction, and the mitigation request to reduce AAAA records) or if it should be consolidated into one of the existing issues.
heimoshuiyu commentedon Jul 14, 2026
One clarification: the information about Bun/uSockets having four concurrent connection slots came from source-code analysis performed by my coding agent. I am not familiar enough with Bun internals to independently confirm that this interpretation is completely correct.
However, I have now confirmed the observable behavior with a hostname that returns two A and two AAAA records.
miku.socialresolved in this order with Bun 1.3.14:I silently dropped TCP/443 traffic to both IPv6 addresses while keeping IPv4 healthy. Direct IPv6 timed out, direct IPv4 returned HTTP 200 in 1.145 seconds, and Bun
fetch("https://miku.social/")returned HTTP 200 in 1.241 seconds.In contrast, with all four
opencode.aiIPv6 addresses blackholed, Bun took approximately 132 seconds before falling back to IPv4. This supports the hypothesis that reducing theopencode.aiAAAA response from four addresses to two would provide an effective immediate mitigation.yao8762 commentedon Aug 6, 2026
Hi, we hit exactly the same root cause and found a reliable workaround.
Environment: Taiwan academic network (TANet) — IPv6 is half-broken; Router Advertisement periodically announces a default IPv6 route that silently blackholes packets (packets are dropped, not rejected).
Symptom: Python-based clients (OpenAI SDK/urllib, RFC 6724 IPv6-first) connect to opencode.ai over IPv6 → TCP SYN retries until ~125s timeout. curl/browsers are fine (Happy Eyeballs / IPv4-first). In our case the blackhole IPv6 route only appears intermittently (RA lifecycle), so the issue came and went — very confusing until we correlated it with
ip -6 route show default.Workaround (client-side, permanent) — pin opencode.ai to IPv4 in
/etc/hosts:After pinning: 100K-token context calls went from ~125s to ~5-8s.
Root cause is upstream DNS returning AAAA records on broken-IPv6 networks — a Happy Eyeballs (RFC 8305) fix in the client would solve it for everyone, but the hosts pin works today.
hylonGG commentedon Aug 15, 2026
奇怪的是之前的老版本一致用的正常，升级后就无法使用了，我也排查了好久，才发现是移动网络IPV6问题。
heimoshuiyu commentedon Sep 4, 2026
this was fix in bun v1.4.0
russrapper15-png commentedon Sep 4, 2026
Certainly! Here is the bio information from the profile you shared:
Kevin Costner at AllMusic
Yes, this is the really me.
LIVE Pro
FLEM Live Creator
The real profile
Kelvin Michael Costner