The symptom

A task on a CI/automation platform needed to access a public container registry at quay.io.

Instead, the task log reported connection refused while it was attempting to reach the registry endpoint at https://quay.io/v2/.

The image was public, so registry credentials were not the obvious boundary. The error looked like a remote connectivity failure.

What made it weird

The surrounding environment already had a working HTTPS proxy configuration.

That made the refusal easy to read as evidence against the public endpoint or the network beyond the platform. But the process making the request was not the host or another service with the proxy configured. It was the task itself, running in its own execution context.

The relevant evidence was inside that context: the task environment did not contain HTTPS_PROXY.

Diagnostic path

The evidence supports this diagnostic path:

  1. Locate the failing stage. The task reached the point where it attempted to connect to the registry endpoint, but no successful TLS or registry API exchange occurred.
  2. Inspect the task’s environment. Proxy configuration elsewhere did not establish that the task inherited it.
  3. Compare the failing context with the required network path. Internet access in this environment required an HTTPS proxy, while the task lacked HTTPS_PROXY.
  4. Change one variable. HTTPS_PROXY was added to the same task without changing credentials, the image, or other network settings.
  5. Retest the same operation. The task then accessed the registry successfully.

The confirmed root cause

The task failed because its own environment was missing the required HTTPS_PROXY variable.

The CI/automation platform could not apply that variable globally to every task, so proxy configuration elsewhere was not inherited automatically. Adding only HTTPS_PROXY to the affected task made the operation work. No further change was required.

The lesson

Network configuration belongs to the execution context that performs the request.

A proxy configured on a host, service, or automation platform is irrelevant to a task that does not inherit it. When a spawned process cannot reach an external service, inspect that process’s environment before treating surrounding configuration as proof that the required path is active.

The endpoint named in a connection error identifies where the task was trying to go; it does not by itself identify which network component rejected the connection.

This is the same boundary mistake seen in the VM migration where the required VLAN existed elsewhere but not on the physical path the workload actually used: configuration can be correct in the environment generally and still be absent from the one path that matters.

A proxy everywhere except in the requesting process is functionally no proxy at all.