HTTP, HTTPS e SOCKS5: escolhendo um proxy por perfil

No que os protocolos de proxy realmente diferem, como se comparam endereços residenciais, de datacenter e móveis, e por que um proxy deve ser verificado antes de colocar uma conta atrás dele.
Um perfil com armazenamento próprio e identidade de dispositivo própria ainda sai do seu computador pelo mesmo endereço de todos os outros perfis, a menos que você lhe dê uma rota de rede própria. É esse o papel do proxy aqui, e é a parte que as pessoas mais costumam errar.
Os protocolos
| Protocolo | Opera na camada | O que vale saber |
|---|---|---|
| HTTP | Aplicação | Entende requisições HTTP e pode lê-las e modificá-las. Serve para tráfego simples e é a opção mais fraca para qualquer outra coisa. |
| HTTPS | Aplicação, via túnel | Abre um túnel CONNECT em cujo interior o proxy não consegue ler. A escolha habitual para navegar na web. |
| SOCKS5 | Sessão | Encaminha TCP e UDP sem interpretar o conteúdo. Agnóstico quanto ao protocolo, suporta autenticação e lida com tráfego não HTTP que os outros não conseguem. |
Para perfis de navegador, HTTPS e SOCKS5 são ambos razoáveis. O SOCKS5 é o mais geral dos dois e o que se deve preferir quando o provedor oferece escolha, porque encaminha tudo o que o navegador faz, e não apenas as partes que reconhece.
De onde vem o endereço
O protocolo é uma decisão menor do que o tipo de endereço por trás dele.
- Endereços de datacenter pertencem a provedores de hospedagem. São rápidos e baratos, e qualquer pessoa que consulte um vê que é espaço de datacenter.
- Endereços residenciais são atribuídos a conexões domésticas por provedores de consumo. Custam mais e são mais lentos, e, só pelo endereço, parecem tráfego doméstico comum.
- Endereços móveis vêm de operadoras de telefonia móvel, em geral compartilhados por muitos assinantes por meio de CGNAT (NAT em nível de operadora). São os mais caros e os de aparência mais comum, justamente porque tanta gente real fica atrás de cada um.
Há ainda a questão estático versus rotativo. Um endpoint rotativo entrega um endereço diferente por requisição ou por intervalo, o que é útil para coletar dados e ativamente prejudicial para uma conta autenticada: uma sessão cujo endereço muda a cada poucos minutos não parece uma pessoa sentada a uma mesa. Contas precisam de um endereço fixo (sticky).
Combinando a rota com a identidade
Um proxy não é um componente que se encaixa separado da identidade do perfil. Os dois precisam concordar.
Esse é o problema autoinfligido mais comum no trabalho com várias contas, e é totalmente evitável. Defina o fuso horário e a localidade do perfil de acordo com a rota que ele usa, e confira os dois juntos, e não separadamente.
Verifique antes de confiar
Provedores de proxy vendem um endpoint. O que esse endpoint realmente faz é uma questão à parte, e vale responder a ela antes de haver uma conta atrás dele.
O PowerOps mantém os proxies como uma biblioteca, e não como um campo enterrado dentro de cada perfil. Um endpoint é adicionado uma vez e depois testado, individualmente ou com a lista inteira de uma vez. O teste informa o endereço realmente observado, e não o que lhe foi vendido. Atribuir um proxy o copia para o perfil, de modo que dois perfis nunca compartilham uma credencial ativa, e uma rota pode ser aplicada a vários perfis numa única ação.
- Adicione o endpoint à biblioteca com protocolo, host, porta e credenciais.
- Teste-o. Confirme que o endereço e o país observados são os que o provedor informou.
- Defina o fuso horário e a localidade do perfil de acordo com esse país.
- Atribua-o e teste a biblioteca de novo periodicamente. Os endpoints se degradam em silêncio.
O status da rede fica no cabeçalho do aplicativo pelo mesmo motivo: uma queda visível é uma queda, e uma queda invisível parece um defeito na sua conta.


