[HN Gopher] When Curl Works but IntelliJ Doesn't: The Ollama Con...
___________________________________________________________________
When Curl Works but IntelliJ Doesn't: The Ollama Connection Mystery
Author : tymscar
Score : 57 points
Date : 2025-10-05 00:39 UTC (3 days ago)
(HTM) web link (blog.tymscar.com)
(TXT) w3m dump (blog.tymscar.com)
| syntaxing wrote:
| 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.
| tymscar wrote:
| Good point! Wireshark was the next step actually if this didnt
| work!
| devmor wrote:
| Even if you know how to use Wireshark already, a lot of times
| it's faster and easier to use mitmproxy for something simple.
|
| I use it for reverse engineering IoT apps on android emulators
| regularly.
| ofrzeta wrote:
| You have to work around TLS, though. Although it is possible
| with Wireshark, extracting the shared keys through from the
| browser, I never could get it to work. With mitmproxy I was
| more successful and could even get iOS Safari to accept my
| self-issued certificate and read HTTP traffic from a third-
| party app that I re-routed through my own proxy.
| bauruine wrote:
| In this case it's possible that it would have worked if he had
| used mitmproxy.
| pixl97 wrote:
| Yep, pretty much any proxy would have resolved the issue,
| unless of course it was java based and used the same
| connection methods.
| bigiain wrote:
| There's nothing more frustrating than having your debugging
| tools change the behaviour enough to hide the bug...
| misja111 wrote:
| 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.
| delfinom wrote:
| >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.
| tymscar wrote:
| Yeah, I am aware of this and its totally fine for me for now!
| rileytg wrote:
| i wasted days on a similar issue... thanks for the write up,
| hopefully this saves someone else in the future
| gopalv wrote:
| 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.
| re wrote:
| It's a good write-up but I wish this blog post went just a
| little bit deeper with the investigation to confirm whether
| this is the issue (ollama.tymscar.com having an AAAA record);
| it's missing the answer to "Why is the JVM trying (or
| initializing toward) an IPv6 path first and not gracefully
| falling back?"
| frogger8 wrote:
| 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
| jeroenhd wrote:
| I don't see the point in applying such a hack when the problem
| is a DNS server that they themselves control. Fix/remove the
| AAAA record and the problem goes away without leaving a footgun
| on your system to hurt you years down the line by altering the
| network priority order.
| JohnMakin wrote:
| 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.
| cyberax wrote:
| 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.
| jeroenhd wrote:
| In the situation you're describing, Happy Eyeballs would've
| kept spamming unnecessary packets across the internet from any
| framework/language. Python's (technically correct) usage of
| IPv6 forced someone to actually fix the problem (the
| misconfigured firewall or DNS).
|
| 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.
| ActorNightly wrote:
| The problem here is that Java is being used.
| o1bf2k25n8g5 wrote:
| Sometimes, when people have a problem, they think, "I know!
| I'll use Java."
|
| Then they have 2 problems.
___________________________________________________________________
(page generated 2025-10-08 23:00 UTC)