Red Hat Registration Works, but DNF Proxy Downloads Fail

Successful registration confirms access to the subscription service. DNF repository metadata and package downloads can use different settings and hostnames, so start with the repository ID, effective URL and first error of the failed operation.

For subscription-manager, the server section of /etc/rhsm/rhsm.conf uses separate fields:

[server]
proxy_hostname = proxy.example.net
proxy_port = 8080
proxy_user = service-account
proxy_password = REPLACE_WITH_MANAGED_SECRET

Replace these values in the existing configuration and protect the file containing the real secret. proxy_hostname takes a hostname, not a complete credential-bearing URL.

For DNF, inspect the affected repository and main configuration. Its proxy option is a URL; proxy_username, proxy_password and proxy_auth_method are separate options. A repository can override the global value. An absent proxy option can permit environment lookup, while an explicit empty value disables a configured parent value for that section. Follow the installed DNF generation's reference. For DNF 4, separate repository inheritance from environment bypass rules.

If a repository file is generated by subscription tooling, identify that owner before editing it. A change overwritten on refresh belongs in the supported configuration source, not in a repeated repair of the output file.

Then classify the first failure. Connection to the proxy precedes either service's account check. A 407 asks for proxy authentication; a TLS error concerns the failing connection's trust; an origin rejection concerns subscription or repository access. Package CDN hosts can differ from registration hosts, so an allowlist for one does not establish access to the other.

Keep the effective endpoint, selected proxy and account identifier with each comparison, excluding secrets. Older rhn_register and /etc/sysconfig/rhn/up2date recipes describe another tooling generation and do not identify a current RHSM or DNF request's settings.