O APT pode usar SOCKS5h sem wrapper

Respostas antigas sobre «APT através de SOCKS» recomendam frequentemente um wrapper ou um relay HTTP-para-SOCKS. Essas respostas podem descrever limitações reais das versões antigas. Não são, porém, a única opção numa versão do APT que documenta suporte para socks5h.

Um fragmento de configuração pode usar as chaves de transporte de aquisição existentes:

Acquire::http::Proxy "socks5h://127.0.0.1:1080/";
Acquire::https::Proxy "socks5h://127.0.0.1:1080/";

Este exemplo pressupõe que já existe um ouvinte SOCKS5 autorizado na mesma máquina. Não inicia nenhum. Um encaminhamento dinâmico SSH é uma forma de criar esse ouvinte local. Se o proxy for remoto, use antes o seu endpoint realmente acessível; os candidatos da lista de proxies SOCKS5 só se aplicam onde proxies públicos são permitidos para os pedidos ao repositório.

O esquema faz parte da instrução

O manual de transporte do APT lista socks5h para SOCKS5 com resolução DNS remota. Use o esquema documentado para a versão instalada em vez de o encurtar para um rótulo que outro programa aceita por acaso.

Do mesmo modo, Acquire::socks::Proxy num antigo excerto de fórum não é prova de que o método de aquisição HTTP leia essa definição. Um analisador de configuração pode aceitar uma chave sem que um método de descarga a use.

O endereço local tem um limite

Quando o APT é executado dentro de um contentor ou máquina virtual, 127.0.0.1 refere-se a esse ambiente. Um ouvinte SOCKS no anfitrião é outro endpoint. Verifique onde o APT é executado antes de diagnosticar uma ligação local recusada.

O suporte a SOCKS também não elimina as verificações de assinatura do repositório nem do certificado HTTPS. Mantenha essas proteções ativas. Se o APT instalado não tiver a capacidade documentada, escolha uma alternativa aprovada ou um caminho de atualização em vez de tratar um esquema de URI desconhecido como um problema de palavra-passe.