APT Can Use SOCKS5h Without a Wrapper
For APT versions with documented SOCKS5h support, the proxy URI belongs under the HTTP or HTTPS transport settings, not an invented Acquire::socks section.
Older answers to “APT through SOCKS” often recommend a wrapper or an HTTP-to-SOCKS relay. Those answers can describe real limitations of old releases. They are not the only option on an APT version that documents socks5h support.
A configuration fragment can use the existing acquisition transport keys:
Acquire::http::Proxy "socks5h://127.0.0.1:1080/";
Acquire::https::Proxy "socks5h://127.0.0.1:1080/";This example assumes an authorized SOCKS5 listener already exists on the same machine. It does not start one. An SSH dynamic forward is one way to create that local listener. If the proxy is remote, use its actual reachable endpoint instead; candidates from the SOCKS5 proxy list apply only where public proxies are allowed for the repository requests.
The scheme is part of the instruction
The APT transport manual lists socks5h for SOCKS5 with remote DNS resolution. Use the documented scheme for the installed version rather than shortening it to a label that another program happens to accept.
Likewise, Acquire::socks::Proxy in an old forum snippet is not evidence that the HTTP acquisition method reads that setting. A configuration parser can accept a key without a download method using it.
The local address has a boundary
When APT runs inside a container or virtual machine, 127.0.0.1 refers to that environment. A SOCKS listener on the host is a different endpoint. Check where APT executes before diagnosing a refused local connection.
SOCKS support also does not remove repository signature or HTTPS certificate checks. Keep those protections enabled. If the installed APT lacks the documented capability, choose an approved alternative or update path instead of treating an unrecognized URI scheme as a password problem.