HTTP ou SOCKS5: qual IP de proxy escolher?
Escolha o tipo de proxy conforme a aplicação, o tráfego compatível e a necessidade de DNS resolvido pelo proxy.
Abra primeiro as configurações de proxy da aplicação. Os protocolos aceitos determinam quais entradas da lista você pode usar; um rótulo impressionante ou uma porta conhecida não adiciona suporte ao cliente.
| Sua aplicação ou tarefa | O que escolher e verificar |
|---|---|
| Oferece apenas um campo de proxy HTTP | Um endpoint compatível da lista de proxies HTTP. Teste também HTTPS CONNECT se precisar de destinos HTTPS. |
| Aceita SOCKS5 e precisa de opções de conexão ou DNS | Um endpoint SOCKS5 com as opções necessárias aceitas nas duas pontas. |
| Precisa de UDP | Verifique suporte a UDP no cliente e no endpoint; o rótulo SOCKS5 não basta. |
| Exige SOCKS4 | Um endpoint SOCKS4 compatível e o modo correspondente no cliente. |
| Não aceita proxy | Um IP de uma lista não configura a aplicação sozinho. |
Para requisições web e API, um proxy HTTP costuma bastar. Ele encaminha HTTP e, quando permitido, transporta HTTPS por CONNECT. Uma página HTTP simples funcionar não comprova suporte a túnel: o serviço pode exigir autenticação do túnel ou restringir destinos e portas.
SOCKS funciona abaixo da camada de requisições HTTP. Uma aplicação compatível pede que ele estabeleça uma conexão sem interpretar uma requisição HTTP, tornando-o útil também para outros tráfegos aceitos. SOCKS5 define endereços IPv4, IPv6 e de domínio, autenticação e associação UDP. Uma aplicação ou endpoint gratuito específico pode implementar só parte disso. A rota TCP SOCKS do navegador não cobre automaticamente outro aplicativo ou serviço UDP.
Onde o nome do destino é resolvido?
No curl, a escrita da URL SOCKS5 determina onde o DNS do destino é resolvido: socks5:// resolve destinos localmente; socks5h:// pede ao proxy que os resolva. Visões DNS diferentes podem fazer uma opção funcionar e a outra falhar. Outros clientes podem usar uma caixa de seleção ou opção separada. Selecionar SOCKS5 não comprova que toda consulta DNS passe por ele.
SOCKS4 tem menos recursos; SOCKS4a acrescenta tratamento de nomes de host. Se cliente e serviço aceitam SOCKS5 e não há razão para usar o protocolo antigo, uma entrada SOCKS5 adequada é uma primeira escolha razoável. Inserir um endpoint SOCKS4 mantendo o cliente no modo SOCKS5 é uma incompatibilidade de protocolo.
Quando o protocolo estiver adequado, teste o destino real e identifique a primeira falha. Nem HTTP nem SOCKS5 mede anonimato: confiança no operador, TLS do destino e a rota real da aplicação ainda determinam a proteção obtida.