Por que uma mudança de DNS não configura um proxy SOCKS
Explica por que direcionar o nome de host de um site para um servidor SOCKS não faz um navegador não configurado usar o proxy.
Alterar uma resposta DNS muda apenas o endereço ao qual o navegador se conecta. Não muda o protocolo que o navegador fala depois de chegar lá.
Ao visitar um URL HTTP comum, o navegador envia HTTP. Ao visitar um URL HTTPS, ele inicia TLS para esse site. Um servidor SOCKS5, porém, espera primeiro a sua própria negociação: escolha de método, qualquer autenticação e um pedido que nomeie o destino. Um navegador não configurado não envia nada disso.
Isso explica por que um listener Dante alcançável pode fechar uma conexão imediatamente após uma mudança de DNS. O serviço pode estar saudável; os bytes que chegam pertencem ao protocolo errado. Mover o listener para a porta 80 ou 443 não transforma esses bytes em SOCKS.
Configure a interface SOCKS do navegador, como as definições SOCKS do Firefox, ou uma definição de proxy específica da aplicação, para que ele faça o handshake e peça ao proxy para conectar adiante. Um ficheiro PAC pode escolher uma rota de proxy suportada para as aplicações que o usam. Continua a ser uma configuração de proxy separada, não uma propriedade de um registo A ou AAAA.
O HTTPS acrescenta outro obstáculo à ideia de apenas DNS. O navegador continua a esperar a identidade do site no URL. Um certificado para o host do proxy não pode satisfazer essa expectativa só porque o DNS enviou a conexão para lá.
A interceção de rede transparente é um desenho diferente que envolve encaminhamento e software de interceção compatível. Não se obtém devolvendo o endereço de um servidor SOCKS a partir do DNS.