Go dependency resolution, unlike other popular systems like NPM, RubyGems, Gradle, and Maven, does not have a unified way to express proxy configurations and ensure that these configurations propagate down to the constituent dependency resolution clients. This makes it difficult to manage large Go dependency trees in restricted environments where access to VCS repositories is tightly controlled through proxy servers.

Mayhap this situation is improved through the recent Go modules system, though I suspect go get is still a pain point for managing developer tools, that are not currently included in the Go modules dependencies specification. In any case, it would be helpful to provide for simplified proxy configuration for Go projects, independent of whether Go modules, or vendored dependencies, or unvendored dependencies, are involved.

The current situation is a mess, with many incomplete and erroneous Google results on how to configure go get / go install. Some posts say to declare a http_proxy environment variable. Other posts mention that git, subversion, and/or mercurial must separately be configured with the proxy details. In practice, it is really easy to get the configurations wrong. I therefore propose that the go tool receive a standard set of proxy parameters, such as through clearly defined environment variable names, and automatically propagate these through to any downstream go get / go install subcommands and their constituent clients, be they HTTP, HTTPS, git, Subversion, Mercurial, etc. etc.

A simple http_proxy environment variable could suffice for many of these configurations. If we like, we can also support HTTP_PROXY, as some applications prefer the uppercase name. https_proxy / HTTPS_PROXY are helpful for specifying different proxies based on the URL scheme. And if we really want to get fancy, SOCKS_SERVER could allow for more advanced proxy configurations.

Perhaps environment variables are too cumbersome, maybe we need standard CLI flags across the different go subcommands to express proxies. But I think we deserve something, so that Go users don't have to setup proxy configuration at multiple abstraction levels, and have to guess which one of these is the root cause of their woes!