Happy Eyeballs gives us the fastest content to our web browser, choosing either IPv4 or IPv6, whichever is faster.īecause speed is king. On top of the fact that if DNS query was faulty, then curl couldn't possibly work either.Humans like speed, especially when it comes to the internet. There is definitely a bit different behaviour regarding handling this though, since switching to curl handler solves the initial issue for me, as well as hardcoding IPv4 address manually in /etc/hosts. This is just my theory though, I really don't know socket handler internals, you're the expert here. Socket handler probably times out on IPv6, and doesn't even have enough of time to try out IPv4 next. But it's somehow smart and detects in a fraction of second that IPv6 connection fails, then moves out to IPv4 immediately, making it in time regarding supplied timeout. If CURL got 'stuck' on that IPv6, then it'd time out as well, eventually. I mean, it's not intended to send 2 requests through 2 different IP addresses right away, so there has to be some kind of timeout to move forward. It might have something to do with the fact that IPv4 query is not even being tried since we time out with IPv6, and we don't have enough of time to try IPv4 next. It happened to be google server in my case, why exactly - probably a coincidence, temporary issue, or some machine-specific problem I'm going to find out myself, since it's not important for this issue. I'm pretty sure that you can reproduce this reliably with any IPv6-enabled machine requesting any domain with AAAA and A DNS entries where IPv6 address simply times out, while IPv4 works just fine. make it work like curl handler), since I strongly believe that it'd greatly benefit HttpClient if it did exactly the same what curl does - attempt to try the next (different) IP address for the same domain, if possible.

Question is, if this is intended behaviour (then we can close the issue), or if perhaps we could do something to improve it (e.g. SocketHttpHandler doesn't do that, once it gets IPv6 from DNS resolve, it'll try to connect through that IP address only, even if it doesn't work while IPv4 address does. Like you can see, it tries IPv6 first, fails, then tries IPv4 next. It could also be some IPv6-related bug in socket handler, although in this case I'm pretty sure somebody else would find it out much sooner than me, maybe it's some specific combination, I'll try to find out. I wonder if curl handler also uses IPv6 by default, this could be the reason why I see behaviour change between those two, gonna keep digging and let you know if I found out something more. Since I don't have more IPv6 machines around, could you try to reproduce this bug for me on IPv6-enabled Linux machine? I don't believe Debian has anything to do with it, so it could be any Linux machine. So this issue is IPv6 related, now the question is whether this is still my machine-specific IPv6 related issue, or something more global.

On the machine with the bug reproduced, I forced usage of IPv4 by manually hardcoding 216.58.215.46 to /etc/hosts, and that one did the trick, I couldn't run into the bug anymore. My dev machines that I tried to reproduce this issue on (and had no luck) don't have IPv6, they used IPv4 address of the and that worked. Yes, one machine for now, and I found out the first clue.

Happy eyeballs