Proxies residenciais são o que vendemos, então pode parecer estranho escrevermos sobre quando você não precisa de um. Mas times que compram proxies para todo trabalho gastam mais do que deveriam, e times que culpam o proxy por toda falha perdem semanas. Saber quais sites precisam de um IP residencial, quais não precisam de nada, e quais precisam de outra coisa completamente diferente é a otimização mais barata na coleta de dados na web.
Para tornar isso concreto, fizemos um pequeno teste. Em 9 de outubro de 2026 requisitamos 30 páginas públicas, três vezes cada, a partir de um servidor em nuvem com um endereço IP de datacenter, e depois novamente através de proxies residenciais da Shifter com saídas nos EUA. Ambas as execuções usaram o mesmo cliente HTTP simples em Python. Dezesseis das 30 páginas funcionaram a partir do IP de datacenter todas as vezes. Três funcionaram apenas através de saídas residenciais. As onze restantes falharam dos dois jeitos, por motivos que um IP residencial não resolve.
O teste
Os alvos cobriram seis tipos de site: APIs públicas e dados abertos, sites de referência e documentação, páginas iniciais de notícias, páginas de busca de e-commerce, páginas de busca de viagens, e um conjunto de páginas de redes sociais, empregos e busca. Cada requisição usou o mesmo User-Agent de navegador desktop e foi verificada quanto a conteúdo real, não apenas um código de status: uma resposta só contava como sucesso se contivesse um marcador que aparece apenas no conteúdo real, como o card de um resultado de busca. Páginas de bloqueio que retornam status 200, o que é comum, portanto contavam como falhas.
Escolhemos os marcadores inspecionando respostas salvas de ambas as redes antes da execução final, e descartamos cinco páginas candidatas nas quais não conseguimos distinguir conteúdo real de uma tela de login ou de um shell JavaScript vazio.
| Categoria | Site | IP de datacenter | Saídas residenciais | Veredito |
|---|---|---|---|---|
| APIs públicas e dados abertos | en.wikipedia.org | 3 de 3 | 3 de 3 | Nenhum proxy necessário |
| APIs públicas e dados abertos | api.github.com | 3 de 3 | 3 de 3 | Nenhum proxy necessário |
| APIs públicas e dados abertos | data.sec.gov | 3 de 3 | 3 de 3 | Nenhum proxy necessário |
| APIs públicas e dados abertos | api.worldbank.org | 3 de 3 | 3 de 3 | Nenhum proxy necessário |
| APIs públicas e dados abertos | ecb.europa.eu | 3 de 3 | 3 de 3 | Nenhum proxy necessário |
| Referência e documentação | docs.python.org | 3 de 3 | 3 de 3 | Nenhum proxy necessário |
| Referência e documentação | developer.mozilla.org | 3 de 3 | 3 de 3 | Nenhum proxy necessário |
| Referência e documentação | rfc-editor.org | 3 de 3 | 3 de 3 | Nenhum proxy necessário |
| Referência e documentação | en.wikipedia.org | 3 de 3 | 3 de 3 | Nenhum proxy necessário |
| Referência e documentação | arxiv.org | 3 de 3 | 3 de 3 | Nenhum proxy necessário |
| Referência e documentação | stackoverflow.com | 0 de 3 | 0 de 3 | Bloqueado dos dois jeitos |
| Notícias | bbc.com | 3 de 3 | 3 de 3 | Nenhum proxy necessário |
| Notícias | reuters.com | 0 de 3 | 0 de 3 | Bloqueado dos dois jeitos |
| Notícias | nytimes.com | 0 de 3 | 0 de 3 | Bloqueado dos dois jeitos |
| Notícias | theguardian.com | 3 de 3 | 3 de 3 | Nenhum proxy necessário |
| Notícias | edition.cnn.com | 3 de 3 | 3 de 3 | Nenhum proxy necessário |
| Notícias | bloomberg.com | 0 de 3 | 0 de 3 | Bloqueado dos dois jeitos |
| Busca em e-commerce | amazon.com | 3 de 3 | 2 de 3 | Nenhum proxy necessário |
| Busca em e-commerce | walmart.com | 0 de 3 | 3 de 3 | IP residencial necessário |
| Busca em e-commerce | ebay.com | 0 de 3 | 0 de 3 | Bloqueado dos dois jeitos |
| Busca em e-commerce | bestbuy.com | 0 de 3 | 0 de 3 | Tempo esgotado dos dois jeitos |
| Busca em e-commerce | etsy.com | 0 de 3 | 0 de 3 | Bloqueado dos dois jeitos |
| Viagens | booking.com | 0 de 3 | 2 de 3 | IP residencial necessário |
| Viagens | expedia.com | 0 de 3 | 0 de 3 | Bloqueado dos dois jeitos |
| Viagens | airbnb.com | 3 de 3 | 2 de 3 | Nenhum proxy necessário |
| Viagens | tripadvisor.com | 0 de 3 | 0 de 3 | Bloqueado dos dois jeitos |
| Viagens | kayak.com | 0 de 3 | 3 de 3 | IP residencial necessário |
| Redes sociais, empregos e busca | linkedin.com | 3 de 3 | 3 de 3 | Nenhum proxy necessário |
| Redes sociais, empregos e busca | indeed.com | 0 de 3 | 0 de 3 | Bloqueado dos dois jeitos |
| Redes sociais, empregos e busca | google.com | 0 de 3 | 0 de 3 | Precisa de um navegador |
“Bloqueado dos dois jeitos” significa que um cliente HTTP simples foi bloqueado em ambas as redes. Um navegador real ou uma API de scraping que lida com verificações de navegador bem pode ter sucesso nesses sites; este teste não tentou isso.
O que os resultados dizem
APIs públicas, dados abertos e documentação não precisam de proxy. Toda API e página de referência que testamos, exceto uma, funcionou a partir de um IP de datacenter em toda tentativa. Esses serviços são construídos para serem usados por programas. O que eles querem é um User-Agent descritivo, taxas de requisição sensatas e, para alguns, uma chave de API. Um proxy adiciona custo e nada mais.
Muitos sites grandes não bloqueiam IPs de datacenter de forma alguma. Três das seis páginas iniciais de notícias, a busca da Amazon, a busca do Airbnb e uma página de empresa no LinkedIn serviram conteúdo real a um servidor em nuvem três vezes em três. Para coleta de baixo volume a partir de sites como esses, começar sem proxy é razoável, desde que você permaneça dentro dos termos e limites de taxa do site.
Alguns sites bloqueiam pela reputação do IP, e é aí que as saídas residenciais importam. Walmart, Kayak e Booking.com recusaram o IP de datacenter todas as vezes e serviram conteúdo através de saídas residenciais. Esses sites avaliam a rede de onde vem uma requisição, e o endereço de um servidor em nuvem é mal avaliado. Esse é o caso para o qual os proxies residenciais existem.
Alguns sites bloqueiam o cliente, não o IP. eBay, Etsy, Expedia, Tripadvisor, Indeed, Stack Overflow e três sites de notícias bloquearam o cliente Python simples em ambas as redes. Eles verificam como o cliente se conecta e se comporta, como sua impressão digital TLS, seus cabeçalhos HTTP e se ele executa JavaScript, antes de olhar de onde ele vem. Um IP residencial não conserta um cliente que se anuncia como um script. Nosso guia sobre impressão digital de TLS e HTTP/2 explica como essas verificações funcionam.
Algumas páginas precisam de um navegador independentemente da rede. A busca do Google retornou uma página pedindo JavaScript para ambas as redes, sem resultados no HTML. Para páginas assim, a escolha é entre um navegador headless e uma API que retorna os dados diretamente.
Como descobrir o que um site precisa
Você pode classificar a maioria dos alvos nesses grupos em uma tarde, antes de comprar qualquer coisa. A função abaixo é a verificação que usamos no teste: ela busca uma página e decide se você obteve o conteúdo real, um bloqueio, um erro ou um shell vazio.
import re
import requests
BLOCK = re.compile(r"captcha|access denied|are you a robot|just a moment|unusual traffic|"
r"verify you are human|request blocked|pardon our interruption|enable javascript and cookies",
re.IGNORECASE)
HEADERS = {
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 "
"(KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36",
"Accept-Language": "en-US,en;q=0.9",
}
def check(url, marker, proxies=None):
"""Did this request get the real content, or a block, an error or an empty shell?"""
try:
response = requests.get(url, headers=HEADERS, proxies=proxies, timeout=30)
except requests.RequestException as error:
return {"url": url, "result": "error", "detail": type(error).__name__}
body = response.text
if response.status_code != 200:
result = "blocked" if response.status_code in (202, 401, 403, 429, 503) else "error"
elif BLOCK.search(body[:20000]) and marker.lower() not in body.lower():
result = "blocked"
elif marker.lower() not in body.lower():
result = "no content"
else:
result = "ok"
return {"url": url, "result": result, "status": response.status_code, "bytes": len(response.content)}Escolha um marcador que só apareça no conteúdo que você quer, como o nome de classe do card de um resultado ou um nome de campo em uma resposta JSON. Não use uma palavra do título da página: páginas de bloqueio e telas de login frequentemente a repetem. Depois execute em algumas páginas de cada alvo:
from check import check
print(check("https://api.github.com/repos/python/cpython", '"full_name"'))
print(check("https://www.ebay.com/sch/i.html?_nkw=laptop", "srp-results")){'url': 'https://api.github.com/repos/python/cpython', 'result': 'ok', 'status': 200, 'bytes': 6617}
{'url': 'https://www.ebay.com/sch/i.html?_nkw=laptop', 'result': 'blocked', 'status': 403, 'bytes': 1832}Execute a partir de onde seu scraper realmente rodará (um servidor em nuvem, não seu laptop, se for onde a produção vive), algumas vezes ao longo de um dia. Os resultados mapeiam para uma decisão:
| O que você vê a partir de um servidor em nuvem | O que isso geralmente significa | O que usar |
|---|---|---|
| Conteúdo real, de forma consistente | O site não bloqueia tráfego de datacenter no seu volume | Nenhum proxy, ou um IP de datacenter para escala |
| Bloqueios ou desafios, e conteúdo real a partir de uma conexão residencial | O site bloqueia pela reputação do IP | Proxies residenciais |
| Bloqueios em todas as redes | O site verifica o cliente | Um navegador real ou uma API de scraping, geralmente com IPs residenciais por baixo |
| Shells vazios sem dados | O conteúdo é renderizado por JavaScript | Um navegador headless, ou a API que a página chama |
| Telas de login | O conteúdo não é público | Não colete sem permissão |
Dois refinamentos:
- O volume muda a resposta. Um site que ignora dez requisições de um servidor em nuvem pode bloquear dez mil. Reteste na taxa em que você planeja operar, não apenas uma vez.
- A localização muda a resposta. Sites servem conteúdo diferente e aplicam regras diferentes por país. Se você precisa de dados como vistos a partir da Alemanha, teste a partir da Alemanha.
As opções intermediárias
A escolha não é apenas entre nenhum proxy e proxies residenciais.
- IPs de datacenter são baratos e rápidos, e funcionam bem para sites que não os bloqueiam. Nossa comparação entre proxies ISP e proxies de datacenter cobre quando eles são suficientes.
- Proxies ISP são endereços estáticos registrados em provedores de internet para consumidores. Eles servem bem para sessões longas e logins nas suas próprias contas, onde você quer o mesmo IP por dias. Os proxies ISP da Shifter vêm com tráfego ilimitado, então também servem bem para cargas de trabalho pesadas e constantes em sites que os aceitam.
- Uma API de scraping cuida do navegador, das novas tentativas e da escolha de IP para você, e cobra por página bem-sucedida em vez de por gigabyte. Geralmente é a opção mais barata para sites que verificam o cliente, porque você não precisa construir e manter a camada de navegador você mesmo. Veja nosso guia sobre scraping de sites com muito JavaScript.
- Proxies residenciais são a ferramenta certa quando um site julga a rede de onde vem uma requisição: quando o mesmo cliente tem sucesso a partir de uma conexão residencial e falha a partir de um servidor em nuvem.
Perguntas frequentes
Eu preciso de um proxy para web scraping?
Nem sempre. No nosso teste, 16 das 30 páginas públicas, incluindo toda API pública e a maioria dos sites de documentação, serviram conteúdo real a um servidor em nuvem sem nenhum proxy. Teste seus alvos primeiro, a partir de onde seu scraper vai rodar.
Quando eu preciso de um proxy residencial?
Quando um site bloqueia requisições de IPs de datacenter mas serve o mesmo cliente a partir de uma conexão residencial. No nosso teste, três dos 30 sites (Walmart, Kayak e Booking.com) se comportaram assim.
Por que ainda estou sendo bloqueado com um proxy residencial?
Geralmente porque o site está verificando o cliente, não o IP. Muitos sites bloqueiam clientes HTTP cuja impressão digital TLS, cabeçalhos ou ausência de JavaScript os identificam como scripts. Onze das 30 páginas no nosso teste falharam em ambas as redes com um cliente Python simples. Um navegador real ou uma API de scraping é a solução, não um IP diferente.
Proxies de datacenter são suficientes para scraping?
Para APIs públicas, documentação, muitos sites de notícias e alguns grandes varejistas, sim, em volumes moderados. Para sites que avaliam a reputação do IP, não. Teste cada alvo em vez de presumir.
Conclusão
Um proxy residencial resolve um problema específico: um site que julga requisições pela rede de onde elas vêm. Ele não ajuda com sites que verificam o cliente, e é desnecessário para APIs públicas e sites que não bloqueiam tráfego em nuvem. Teste cada alvo a partir de onde seu scraper vai rodar, classifique-o em um desses grupos, e pague por tráfego residencial apenas onde isso muda o resultado. Nosso guia de boas práticas de web scraping cobre o resto da coleta responsável.