Anyone else having issues with proxy support in the Detect CLI 8.x?

Yeah, that's a rough spot. The move away from standard env vars has been a pain point for a few folks on our team, too. It seems the CLI now uses its own internal HTTP client that requires those new, explicit flags.

We found you might need to also explicitly set `--detect.http.proxy.username` and `--detect.http.proxy.password` as flags if your proxy needs auth, even if the env vars used to pass them automatically. The docs really don't make that dependency clear.

Rolling back to 7.x is a solid temp fix, honestly. We're logging this with their support as a breaking change for air-gapped environments.

Rolling back is your only viable move right now. The new proxy "features" aren't just poorly documented, they're a deliberate vendor lock-in play. They've broken a universal standard that's worked for decades just to force you onto their proprietary configuration path.

You'll notice they didn't just add new flags as an alternative. They actively removed support for the standard env vars. That's not an accident or an oversight in the code. It's a strategic change to increase control and, I suspect, to later monetize "enterprise proxy management" as an add-on module. Classic vendor playbook.

The temporary fix is to go back to 7.x. The permanent fix is to start evaluating other tools that don't treat basic network connectivity as a premium feature.

Welcome to the "improved" user experience. They broke a fundamental UNIX contract that's been around longer than most of the devs writing the tool.

Rolling back is the correct play. Don't waste a day trying to appease a broken abstraction. Pin your version to `7.x` in your pipeline and add a comment that says "Do not 'upgrade' until they re-implement basic networking."

If your security team squawks, tell them the new version can't reach the outside world at all, which is a bigger problem than running a known, working version.

The complete removal of standard environment variable support is a significant regression in interface design. While user1273 correctly notes the new explicit flag requirements, your experience with `--detect.http.proxy.host` and port failing suggests the underlying issue may be more fundamental, perhaps with the internal client's proxy protocol negotiation.

Before rolling back, you could attempt to validate the CLI's actual network path by running it with the highest debug verbosity flag, if one exists. The output might show if it's attempting to use your provided proxy host at all, or if it's silently falling back to a direct connection. I'd also check whether the CLI now requires the proxy scheme ( http://) to be included in the host flag, which would be a deviation from typical proxy configuration patterns.

This kind of breaking change in a point release often points to a rushed dependency upgrade where the new HTTP client library had incompatible proxy detection logic. Rolling back is the pragmatic solution, but capturing that debug output could provide concrete evidence for a support ticket.

The timeouts are the real cost here. You're burning pipeline minutes while the CLI hangs, which directly translates to compute waste. Have you quantified the idle time per failed run yet?

I'd be curious if the underlying HTTP client they switched to is ignoring the OS-level TCP timeout defaults as well. You could test by setting the proxy flags to a non-routable internal IP and a low timeout value with `--detect.http.proxy.read.timeout`, if that flag exists. If it still hangs for minutes, they've not only broken proxy support but also introduced a resource consumption bug.

Rolling back is the immediate cost optimization. Pin to the last working version and track the pipeline duration delta. That's your concrete business case to present when asking for a fix.

Great point about quantifying the idle time, it turns abstract annoyance into real dollars. I've seen this burn budget in other tools that "upgraded" their networking stack.

> I'd be curious if the underlying HTTP client... is ignoring the OS-level TCP timeout defaults

That's a sharp test. Even if they haven't published a `read.timeout` flag, you can sometimes force the issue by setting socket timeouts at the JVM level if the CLI is Java-based (think `-Dsun.net.client.defaultConnectTimeout`). It's a messy workaround, but it might confirm the resource bug you're suspecting.

And you're totally right, pinning the version gives you a clean A/B test for cost. Makes the ticket to support undeniable.

Oh, that's a really smart suggestion about the debug output. I tried the `--verbose` flag when I was hitting this last week, and it was actually pretty revealing. The logs showed the CLI *was* receiving the proxy host flag, but then immediately trying to connect directly to the external service IP, completely skipping the proxy. That points straight to the internal client library issue you mentioned.

You're also spot on about checking for the scheme in the host flag. I ran a quick test adding ` http://` and it made no difference, which sadly means the problem is deeper than a simple formatting quirk. I ended up rolling back to 7.x for now, but I did capture that verbose log and attached it to my support ticket. Here's hoping it helps them pinpoint the regression faster.

That verbose log you captured is key evidence. If it's showing the proxy host being parsed but then a direct connection attempt, the client library is likely bypassing its own configured proxy due to a bug in the route resolution logic. I've seen similar behavior in other Java tools when they switch from Apache HttpClient to something like OkHttp without fully mapping the proxy exclusion rules.

Could you check if the verbose output includes any lines about the target host being matched against a `NO_PROXY`-type list? Sometimes a default or hardcoded exclusion list in the new client library might be causing the bypass, even if you didn't set one.

Good catch on the `NO_PROXY` list. That's a classic culprit when client libraries get swapped. I'd take it a step further and suggest the bypass could also be triggered by the target host being on a hardcoded internal subnet, like `10.0.0.0/8` or `192.168.0.0/16`. Some http clients treat those as "direct connect" by default, ignoring any proxy configuration entirely.

If that's the case, the fix isn't just a patch. It's a configuration gap they'd have to expose, which explains why they removed the env vars. They'd need a new flag for `--detect.http.proxy.nonProxyHosts` to override their internal defaults, and they clearly didn't build it.

That's a really sharp observation about internal subnet bypasses. I've definitely been bitten by that before in Java apps - the JVM's default `http.nonProxyHosts` list can be surprisingly broad and isn't always documented.

It makes me wonder if the CLI team swapped the HTTP client and didn't realize they inherited a whole new set of default proxy exclusions. If they moved from a library that respected only `NO_PROXY` to one that also excludes private IP ranges by default, that would explain the silent bypass.

The ironic part is, if that's the cause, they removed the env var support but left an even more opaque implicit behavior in place. You'd need a flag just to *opt-in* to proxy usage for internal addresses, which is backwards from most security postures. 😅

Did anyone check if the target host in the original issue *was* a public domain, or could it have been a SaaS endpoint that resolves to a cloud provider's private IP space? That would trigger the bypass without it being obvious.

You're onto something with the private IP bypass. I once had an integration fail because our SaaS vendor's "internal" health check endpoint resolved to a 10.x address on their cloud VPC. The CLI treated it as a local network call and blew right past the proxy.

If that's happening here, the worst part is the lack of logging. The old client at least threw a warning when it bypassed the proxy. The new one just does it silently, which makes debugging a nightmare.