A configuration file can parse successfully and still fail to configure the proxy. APT accepts a tree of named options; it does not treat every plausible-looking branch as an instruction to its HTTP transport.

For the HTTP route, the APT proxy setting is:

Acquire::http::Proxy "http://proxy.example.net:8080/";

Use an HTTP endpoint from your service or the HTTP proxy list when public repository access may use public proxies. Wrapping the same setting in an extra scope changes its name:

APT {
    Acquire {
        http {
            Proxy "http://proxy.example.net:8080/";
        };
    };
};

That places the value at APT::Acquire::http::Proxy. It is not another spelling of Acquire::http::Proxy. The HTTP acquisition method looks for the latter.

Ask for the exact value

apt-config shell HTTP_PROXY_VALUE Acquire::http::Proxy
apt-config shell NESTED_VALUE APT::Acquire::http::Proxy

These are read-only configuration inspections. Output can expose user information if the URI contains it, so keep credentials out of shared transcripts. Compare the same configuration files, options and account context that launch the failing package operation.

A missing value at the correct path explains why a valid-looking file did not select the endpoint. It says nothing yet about whether that endpoint is reachable.

Check punctuation at the right layer. Names use double-colon separators; ordinary value assignments need quotes and a trailing semicolon. Case is not significant in APT option names, so changing proxy to Proxy is not a repair for an extra scope. A semicolon inside the URI string is data rather than the statement terminator.

Correct the declaration rather than adding more exports around it. Once APT reports the intended setting, a connection refusal, 407 or certificate error belongs to a later stage.

Mikanda mikatakata