Proxies residenciais são o que vendemos, então pode parecer estranho escrevermos sobre quando você não precisa de um. Mas equipes que compram proxies para todas as tarefas gastam demais, e equipes que culpam o proxy por todas as falhas desperdiçam semanas. Saber quais sites precisam de um IP residencial, quais não precisam de nada e quais precisam de outra coisa totalmente diferente é a otimização mais barata na coleta de dados web.
Para tornar isso concreto, realizamos um pequeno teste. Em 9 de outubro de 2026, solicitamos 30 páginas públicas, três vezes cada uma, a partir de um servidor em nuvem com um endereço IP de datacenter, e depois novamente através de proxies residenciais Shifter com saídas nos EUA. Ambas as execuções usaram o mesmo cliente HTTP Python simples. Dezesseis das 30 páginas funcionaram a partir do IP de datacenter em todas as tentativas. 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.
Nosso teste: 30 páginas, IP de datacenter vs proxies residenciais
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 solicitaçã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ó contou como sucesso se continha um marcador que aparece apenas no conteúdo real, como um card de resultado de busca. Páginas de bloqueio que retornam status 200, o que é comum, portanto contaram 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 barreira 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 pode muito bem ter sucesso nesses sites; este teste não tentou isso.
Por categoria, os resultados somam assim:
| Categoria | Páginas | Nenhum proxy necessário | IP residencial necessário | Falhou dos dois jeitos |
|---|---|---|---|---|
| APIs públicas e dados abertos | 5 | 5 | 0 | 0 |
| Referência e documentação | 6 | 5 | 0 | 1 |
| Notícias | 6 | 3 | 0 | 3 |
| Busca em e-commerce | 5 | 1 | 1 | 3 |
| Viagens | 5 | 1 | 2 | 2 |
| Redes sociais, empregos e busca | 3 | 1 | 0 | 2 |
| Total | 30 | 16 | 3 | 11 |
O que o teste de 30 páginas mostra
APIs públicas, dados abertos e documentação não precisam de proxy. Toda API e página de referência que tentamos, exceto uma, funcionou a partir de um IP de datacenter em todas as tentativas. Esses serviços são construídos para serem usados por programas. O que eles querem é um User-Agent descritivo, taxas de solicitaçã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 do 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.
Amazon e Airbnb funcionaram, cada um, três vezes em três a partir do IP de datacenter e duas vezes em três através de saídas residenciais. Com três tentativas por site, uma falha está dentro da variação normal, não é evidência de que IPs residenciais se saem pior ali. Cada solicitação residencial parte de uma conexão doméstica diferente, e uma saída individual pode estar lenta, ou ter sido vista recentemente pelo mesmo site, de um jeito que um servidor em nuvem fixo não está. A lição é testar várias vezes antes de decidir, o que a verificação abaixo facilita.
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 em todas as tentativas e serviram conteúdo através de saídas residenciais. Esses sites avaliam a rede de onde vem uma solicitação, e o endereço de um servidor em nuvem pontua mal. 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 saber do 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 apareça apenas no conteúdo que você quer, como o nome de classe de um card de 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 barreiras 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 vai rodar (um servidor em nuvem, não seu laptop, se for ali que a produção vive), algumas vezes ao longo de um dia. Os resultados se traduzem em uma decisão:
| O que você vê a partir de um servidor em nuvem | O que 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 de uma conexão doméstica | 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 |
| Barreiras 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 solicitações de um servidor em nuvem pode bloquear dez mil. Teste novamente 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.
Quando dados específicos de localização precisam de um proxy residencial
Nosso teste fez uma pergunta: o site serve seu conteúdo de alguma forma? Uma segunda pergunta frequentemente importa mais: ele serve o conteúdo que uma pessoa real em um determinado lugar veria?
Um servidor em nuvem fica em um punhado de localizações de data center, e muitos sites reconhecem endereços de data center e mostram a eles uma versão padrão: a página inicial global, preços em dólares americanos, nenhum estoque local, ou nenhum anúncio. Se sua tarefa depende do que usuários em um país ou cidade específico veem, você precisa de uma saída ali, em uma rede que esses usuários realmente usam. Isso cobre:
- Resultados e rankings de busca local, que mudam por cidade.
- Preços, disponibilidade e opções de entrega, que varejistas e sites de viagem definem por mercado.
- Anúncios e páginas de destino, que anunciantes direcionam por localização e que frequentemente não são mostrados a tráfego de data center. Verificá-los é o núcleo da verificação de anúncios.
- Conteúdo licenciado ou restrito por país.
Nesses casos o site pode nunca bloquear um IP de datacenter, e mesmo assim você coletaria os dados errados sem uma saída residencial no lugar certo.
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 bons para sites que não os bloqueiam. Nossa comparação entre proxies ISP e de datacenter cobre quando eles são suficientes.
- Proxies ISP são endereços registrados a provedores de internet de consumo, mantidos para você por um período mais longo. Eles são adequados para sessões longas e logins em suas próprias contas. Os proxies ISP da Shifter permanecem na cidade e no ISP (ASN) que você escolher durante todo o período de cobrança e vêm com tráfego ilimitado, então também são adequados para cargas de trabalho pesadas e constantes em sites que os aceitam.
- Uma API de scraping lida com o navegador, as tentativas repetidas e a 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 solicitação: quando o mesmo cliente tem sucesso a partir de uma conexão doméstica e falha a partir de um servidor em nuvem.
Perguntas frequentes
Preciso de um proxy para web scraping?
Nem sempre. Em nosso teste, 16 das 30 páginas públicas, incluindo todas as APIs públicas e a maioria dos sites de documentação, serviram conteúdo real para um servidor em nuvem sem nenhum proxy. Teste seus alvos primeiro, a partir de onde seu scraper vai rodar.
Quando preciso de um proxy residencial?
Quando um site bloqueia solicitações de IPs de datacenter mas serve o mesmo cliente a partir de uma conexão doméstica. Em nosso teste, três dos 30 sites (Walmart, Kayak e Booking.com) se comportaram assim.
Por que ainda sou 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 falta de JavaScript os identificam como scripts. Onze das 30 páginas em 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.
Qual é a diferença entre um IP de datacenter e um IP residencial?
Um IP de datacenter pertence a um provedor de hospedagem ou nuvem. Um IP residencial pertence a um provedor de internet de consumo e é usado por uma conexão doméstica real. Muitos sites confiam mais em endereços residenciais, porque visitantes comuns os usam.
Como testo se um site bloqueia IPs de datacenter?
Solicite algumas páginas a partir de um servidor em nuvem e verifique a resposta quanto a um marcador que aparece apenas no conteúdo real, não apenas o código de status. Depois repita através de uma saída residencial. Se o servidor em nuvem for recusado e a saída residencial for servida, o site bloqueia pela reputação do IP.
Preciso de um proxy residencial para dados específicos de localização?
Geralmente, sim. Mesmo sites que nunca bloqueiam servidores em nuvem frequentemente mostram a eles uma versão padrão da página. Para ver os resultados locais, preços ou anúncios que usuários em um país ou cidade veem, você precisa de uma saída naquele lugar.
Por que Amazon e Airbnb funcionaram com menos frequência através de proxies residenciais no seu teste?
Cada um falhou uma vez em três tentativas residenciais, o que está dentro da variação normal para três tentativas. Cada solicitação residencial parte de uma conexão doméstica diferente, e uma única saída pode estar lenta ou ter sido vista recentemente pelo site. Teste várias vezes antes de tirar uma conclusão.
Conclusão
Um proxy residencial resolve um problema específico: um site que julga solicitações pela rede de onde 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 ele muda o resultado. Nossas melhores práticas de web scraping cobrem o restante da coleta responsável.