proxychains does LD_PRELOAD tricks to hook libc functions. Go doesn't use libc, so this is unfeasible.

Please file a separate bug if cmd/go isn't respecting HTTP_PROXY somewhere. But I don't know where. Note that Go's implementation of HTTP_PROXY also supports SOCKS, so you should be able to proxy to HTTP, HTTPS, or SOCKS.

I think if gcloud can, then go commands also can.

gcloud is written in Python, which uses libc, so proxychains happens to work. This wasn't a decision on gcloud's part.

This is not a problem can be solved by GOPROXY and http(s)_proxy env vars.

Why?

proxychains is much more convenient and has better controls.

Which controls?

But yes, for proxychains users it'd be more convenient if it worked, but unfortunately it can't for Go programs.

@bradfitz
Thanks for your detailed reply.

Which controls?
Why?

With proxychains, it is convenient to switch between proxy-on and proxy-off mode, though it is only a little more convenient.

And proxychains supports remote dns resolving.

I just run some go get -u commands to confirm the behaviors of go commands. It looks go commands respect http_proxy and https_proxy, but not all_proxy, which curl respects. In my opinion, all_proxy is a little more convenient than http_proxyandhttps_proxy`.

I have not got a full understanding on GOPROXY yet. When its value is set as the value of https_proxy, go get -u doesn't work.

More info: my proxy is a socks5 proxy.

And proxychains supports remote dns resolving.

So does Go's SOCKS5 implementation.

I have not got a full understanding on GOPROXY yet.

GOPROXY is the proxy cache to get modules from. For instance, use https://proxy.golang.org/

But you can use it with HTTPS_PROXY to set your SOCK5 proxy for that.

Anyway, there's nothing to do here it seems so I'm going to close this bug.

Would it be better to fallthrough to all_proxy if http[s]_proxy is not set?