Duas configurações de proxy podem criar uma cadeia que você não pretendia

Sua aplicação aponta para o proxy B, mas foi iniciada por um wrapper configurado para o proxy A. Qual saída o site vê? A resposta depende de qual conexão o wrapper intercepta.

Em um arranjo aninhado simples, a aplicação primeiro tenta conectar-se a B. O wrapper intercepta essa conexão e a conduz através de A. Depois a aplicação fala o protocolo de proxy de B sobre o fluxo resultante, e B faz a conexão final ao site.

application → wrapper proxy A → application proxy B → website

O site vê a conexão de saída final de B. B vê uma conexão chegando através de A. Isso é diferente de o wrapper sobrescrever silenciosamente a configuração de proxy da própria aplicação.

O diagrama simples tem condições

Regras de desvio, chamadas de socket não suportadas, processos existentes e o modelo de interceptação de cada produto podem alterar o caminho. Alguns wrappers podem excluir seu próprio proxy ou destinos selecionados. Não presuma que cada par de ferramentas se combina da mesma forma.

A descrição do proxychains-ng explica sua abordagem de interceptação e suas limitações. Um programa que usa suporte nativo a proxy ainda faz uma conexão de rede com esse proxy, o que é um candidato à interceptação.

Para uma cadeia deliberada de endpoints públicos não autenticados, a lista de proxies gratuitos oferece candidatos cujos protocolos devem corresponder a cada ferramenta. Para uma saída inesperada, registre três endereços separadamente: o endpoint escolhido pela aplicação, o endpoint escolhido pelo wrapper e o resultado que o site vê. Olhar apenas as configurações do navegador ignora a camada intermediária.

Use uma rota enquanto estabelece o comportamento pretendido e depois adicione a outra apenas se a cadeia for necessária. Saltos extras podem adicionar pontos de falha e relações de confiança diferentes. Eles não apagam automaticamente cookies identificadores nem fazem todas as conexões da aplicação seguirem a mesma rota.