A client can authenticate to an Apache forward proxy using one account while Apache authenticates to a parent proxy using another:

client ── client account ── Apache ── parent account ── parent proxy

For a fixed parent account on httpd 2.4.59 or later, ProxyRemote accepts a third argument:

ProxyRemote "*" "http://parent.example:3128" "parent-user:replace_with_private_password"

This supplements the existing access-controlled forward-proxy configuration, such as a private listener requiring both a client IP and a proxy login. The account belongs to the selected parent. Protect the configuration containing it, and choose the match scope required by the deployment.

Apache sends these Basic credentials preemptively, without first waiting for a challenge. That makes the parent connection’s transport and account policy important; the website’s later HTTPS session does not itself protect a cleartext HTTP hop to the parent.

When the same incoming account should continue

Apache normally consumes proxy authentication addressed to itself. The proxy-chain-auth environment setting instead permits forwarding the client’s proxy credentials to the next proxy:

SetEnv proxy-chain-auth On

This is appropriate only for an intentionally shared authentication chain. It passes the incoming account material onward; it does not invent a different parent username and password.

With ProxyRemote’s explicit credential argument, proxy-chain-auth has no effect. Choose the credential source deliberately rather than layering both settings in the hope that whichever password works will be selected.

These mechanisms authenticate proxy hops. A destination website’s Authorization header remains a separate exchange.

Erthyglow kevrennek