winget install fails behind a proxy

Package installs work on a test machine with open egress and then fall over on the corporate network. Usually it is the installer download rather than the manifest, and usually the proxy wants authentication.

Why this is awkward for any package manager

Several things have to agree: the package manager itself, the HTTP stack underneath it, and whatever runs the download. Each may or may not honour system proxy settings, and each may or may not have anywhere to put credentials. Running as SYSTEM makes it worse, because a proxy configuration that lives in a user’s profile is not there for a service account, and an authenticating proxy has no interactive session to prompt.

The result is a download that hangs or 407s in a context where nobody can see the prompt.

What we actually offer

Our answer is structural rather than configurational, and it is worth being precise about the difference.

We do not give you a proxy settings page. What we do is remove most of the reason an endpoint needs to traverse the proxy at all. Once a package is admitted, its verified installer bytes are retained and served from your own feed on your own network, and the endpoint is fenced to that single source. The endpoint stops making outbound calls to a rotating set of vendor CDNs, and starts making one call to a host inside your perimeter.

For most fleets that turns “the proxy breaks installs” into a question that no longer arises on the endpoint side, because the traffic never leaves the network.

That is a genuine answer to the operational problem. It is not the same thing as proxy support, and we would rather draw that line ourselves than have you discover it during a pilot.

What we do not have

• No proxy configuration surface. There is no setting, no credential store, no per-client proxy override anywhere in the product. Our agent’s HTTP clients use the platform defaults, so an unauthenticated system-wide proxy may be picked up implicitly by the underlying stack — but that is inherited behaviour, not a feature we implement or test against.
• No TLS pinning, deliberately. No setting selects TLS versions or cipher suites anywhere in shipped code. This is a deliberate constraint, enforced by a test that scans the source tree and fails if such a knob is introduced, and it exists partly for export-classification reasons. TLS policy is the operating system’s, and your existing SChannel configuration is the control.
• Ingest effectively bypasses proxies. The fetcher used for catalog ingest resolves DNS itself and connects to the resolved address, with redirects individually re-validated. It also rejects private address ranges outright. So pointing ingest at an internal proxy or an internal mirror on a private address does not work today.

The practical shape

If your endpoints are behind a proxy, fence them to an internal feed and the problem largely disappears — that is the design and it works.

If your control plane must reach the internet through an authenticating proxy, that is not currently supported, and the honest recommendation is to give the control plane a direct egress path to the hosts it ingests from. If that is impossible in your environment, tell us before you invest time in a pilot rather than after.