Problem
The transport is configured with:
Proxy: http.ProxyFromEnvironment,
so HTTP_PROXY, HTTPS_PROXY and NO_PROXY are all honoured. Neither the README nor --help says so.
Why it matters
Two directions, both bad:
- Users behind a corporate proxy don't know the tool already works, and go looking for a
--proxy flag that doesn't exist.
- Users in an environment with
HTTP_PROXY set for unrelated reasons get their requests silently rerouted, which is a genuinely confusing failure when a health check starts hitting the wrong host.
Suggested fix
Document the supported variables in the README, and consider a --proxy flag plus a --noproxy escape hatch for parity with curl. Logging the effective proxy at debug level would also help.
Problem
The transport is configured with:
so
HTTP_PROXY,HTTPS_PROXYandNO_PROXYare all honoured. Neither the README nor--helpsays so.Why it matters
Two directions, both bad:
--proxyflag that doesn't exist.HTTP_PROXYset for unrelated reasons get their requests silently rerouted, which is a genuinely confusing failure when a health check starts hitting the wrong host.Suggested fix
Document the supported variables in the README, and consider a
--proxyflag plus a--noproxyescape hatch for parity with curl. Logging the effective proxy at debug level would also help.