RPM Proxy Options for URL-Based Package Downloads

rpm -Uvh https://packages.example.net/example.rpm includes a network-fetch step. Before package verification or installation, RPM must obtain the file.

A working DNF proxy configuration does not establish the settings used by that separate invocation. RPM's manual documents --httpproxy and --httpport for its HTTP retrieval path. The installed RPM version and its URL-helper arrangement determine the details. RPM 6's common-options reference marks these network-fetch options deprecated and recommends a dedicated fetch tool such as curl or GNU Wget instead.

For a workflow you are maintaining, first establish which layer fetches the URL. For a new workflow, an explicit approved download followed by local package verification and installation avoids depending on these deprecated fetch options.

Keep the fields in their documented format. Do not guess that every version accepts a credential-bearing URL wherever a proxy hostname is requested, or edit a distribution's global macro file just because an old answer did so.

Locate the failure stage: could the fetch reach the proxy, was authentication accepted, and did the package endpoint return the intended file? A later signature or dependency error is a different problem from a stalled proxy connection.

Preserve normal package verification. Making the download route work is not a reason to disable signature checks, install an untrusted file or treat a successful DNF command as proof that this RPM fetch followed the same route.