Terraform Proxy Failures Across Downloads, Providers and Remote Runs
Distinguish Terraform registry downloads, Git module fetches, provider API calls and remote execution when a proxy works for only part of a run.
A provider download succeeding says little about a later cloud API call. Start with the first failing hostname and operation, then identify its owner:
| Operation | Follow this path |
|---|---|
| Registry lookup or installation download | Terraform process, installation source and proxy environment |
| Git-backed module fetch | The source URL and Git transport; SSH and HTTPS use different settings |
| Cloud API call | The provider plugin and its SDK's routing and trust configuration |
| Remote execution | The runner's environment and network, rather than the laptop's |
For an HTTP proxy that supports CONNECT, this environment value can correctly select it for HTTPS destinations:
HTTPS_PROXY=http://proxy.example:3128The variable names the destination scheme; the value names the proxy's transport. Use https:// only when the listener offers TLS and the requesting client supports it. Providers are separate plugins and can use SDK-specific settings, so this value is not a promise about every provider.
At the identified owner, distinguish the error layer before changing a setting: a refused proxy connection, proxy 407, rejected CONNECT, certificate error and cloud API 403 each narrow the next investigation differently. Keep the phase, destination, execution environment and first error together.
Apply the supported setting to that component. A laptop export does not configure a remote runner, and proxy credentials do not authenticate to the registry or cloud API.