When Curl Works but IntelliJ Doesn't: The Ollama Connection Mystery

It is a meme, but it's always DNS

This error can happen if there's an AAAA record, but it contains the ipv4 address packed inside a ipv6 mask.

If the AAAA record says ::ffff:10.0.0.105, then you can either fix DNS or do what's in the blog, which should stop checking for quad A records.

From the Oracle/Java documentation:

java.net.preferIPv4Stack (default: false) If IPv6 is available on the operating system the underlying native socket will be, by default, an IPv6 socket which lets applications connect to, and accept connections from, both IPv4 and IPv6 hosts. However, in the case an application would rather use IPv4 only sockets, then this property can be set to true. The implication is that it will not be possible for the application to communicate with IPv6 only hosts.

It's strange that things didn't work with this flag to false. It should be able to connect to both IPv4 and IPv6. Now that the author has set it to true, the drawback is that his IntelliJ won't be able to connect to IPv6-only hosts anymore.

Not too dissimilar to what I and some colleagues went through with our local dev tooling yesterday. Not related to DNS, but the frustration was on par.

Went around in circles deleting the repo, deleting packages from homebrew, reimporting the tool chain from our private repo, constantly got HTTP 400 errors from the Rails Console when we were attempting to use our local dev instance to talk to third party APIs.

Eventually found out it was because of a recent release of OpenSSL:

1. https://github.com/ruby/openssl/issues/949#issuecomment-3367... 2. https://github.com/openssl/openssl/issues/28758#issuecomment...

Had to rollback OpenSSL to a prior version, we were dangerously close to "time to wipe the Mac".

Fun read, but you probably could have installed mitmproxy with brew, pointed your IntelliJ instance through this proxy (you can either set it in your settings or run it with environment variable HTTP_PORT or HTTPS_PORT). This allows you intercept the request like wireshark and diagnose. You honestly can just intercept the interface request using wireshark but the learning curve is stepper.

macOS doesn’t give you a built-in toggle — but you can use a resolver config tweak. sudo nano /etc/gai.conf Add this..

precedence ::ffff:0:0/96 100

it will boosts IPv4 preference when resolving hostnames that return both A (IPv4) and AAAA (IPv6) records. (The file may not exist; if so, you’re creating it. It’s honored by getaddrinfo, which Java ultimately uses through the OS.)

Keeps IPv6 alive but prefers IPv4

So I understand why preferring ipv4 would fix an issue while using DNS, but why would Java fail to connect when directly using the ip address?

i wasted days on a similar issue… thanks for the write up, hopefully this saves someone else in the future

I had a similar issue with Python long ago. We had a server running in AWS that was configured for IPv4 and IPv6 addresses, but we accidentally forgot to set up the firewall rules to allow inbound routing for IPv6.

Everything worked fine in Go, because the built-in client uses the Happy Eyeballs protocol. But Python clients silently failed for _some_ people when working from home. Why? Because they had IPv6 enabled, and Python tried to use it exclusively.

I'm now convinced that the lack of Happy Eyeballs early in the IPv6 deployment was the main culprit for its sad state.

This sounds similar to an infuriating issue I've been dealing with AWS Client VPN for at least a year - it does not support ipv6, but depending on your setup, requests may try to resolve a ipv6 address first, not find one, and then stall/fail. Only solution seems to be trying to guarantee ipv6 resolution is disabled.

The problem here is that Java is being used.