When Curl Works but Intellij Doesn't: the Ollama Connection Mystery
Posted3 months agoActive3 months ago
blog.tymscar.comTechstory
supportivepositive
Debate
20/100
JavaIpv6NetworkingDebugging
Key topics
Java
Ipv6
Networking
Debugging
The blog post describes a frustrating debugging experience with IntelliJ and Ollama, which was resolved by understanding Java's IPv6 behavior, and the discussion shares similar experiences and solutions.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
1d
Peak period
21
84-96h
Avg / period
6.8
Comment distribution27 data points
Loading chart...
Based on 27 loaded comments
Key moments
- 01Story posted
Oct 4, 2025 at 8:39 PM EDT
3 months ago
Step 01 - 02First comment
Oct 6, 2025 at 7:37 AM EDT
1d after posting
Step 02 - 03Peak activity
21 comments in 84-96h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 9, 2025 at 12:04 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45477983Type: storyLast synced: 11/20/2025, 7:55:16 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
I use it for reverse engineering IoT apps on android emulators regularly.
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.
I'm very sure the author has no such need.
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.
He might have setup IPv4 internal DNS server and java might have used the public IPv6 DNS to resolve the domain.
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
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.
The more of these half-solutions you make default, the more fragile and confusing networks become. Things like these are what I find so infuriating about "opinionated" frameworks like Go's standard library, because they'll happily apply patch jobs that'll probably mostly work most of the time as a default and leave you to reverse engineer the problem when the workaround eventually collapses.
Then they have 2 problems.
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".