Proxies para Google Maps API: geocodificação e extração de dados de negócios sem bloqueio de chaves

Google Maps API é uma ferramenta poderosa para geocodificação de endereços, busca de organizações e coleta de dados sobre negócios locais. Mas assim que você começa a trabalhar com ele em volumes industriais, surgem bloqueios de chaves, excedentes de limites e solicitações suspeitas. Neste artigo, vamos discutir por que isso acontece e como configurar proxies para que as chaves não sejam queimadas e os dados sejam coletados de forma estável.

Por que o Google Maps API bloqueia chaves e solicitações

Quando você envia centenas ou milhares de solicitações ao Google Maps API a partir de um único endereço IP ou uma única chave, o Google percebe isso como uma atividade anômala. O sistema de proteção opera com base em vários critérios simultaneamente: frequência de solicitações, geografia do IP, padrões comportamentais e histórico da chave.

Aqui estão as principais razões pelas quais as chaves recebem restrições ou um bloqueio total:

• Excedendo o limite diário de solicitações — cada chave tem uma cota, e ao esgotá-la, a API retorna o erro OVER_QUERY_LIMIT.
• Alta frequência de solicitações de um único IP — mesmo dentro do limite, o Google registra solicitações sequenciais muito rápidas como automação.
• Um IP para várias chaves — se você rotaciona chaves, mas não rotaciona IP, o Google as associa a uma única sessão.
• Incompatibilidade geográfica entre chave e IP — a chave está registrada em um país, mas as solicitações vêm de outro, o que levanta suspeitas.
• Falta de atrasos entre as solicitações — padrões de máquina sem pausas são detectados instantaneamente.
• Uso de IPs de data center sem mascaramento — o Google conhece bem os intervalos de IP dos provedores de nuvem (AWS, GCP, Azure) e aumenta o nível de verificação para eles.

É importante entender: o Google Maps API é um produto pago, e o Google o protege não apenas contra abusos, mas também contra contornos de cobrança. É por isso que o sistema de detecção aqui é significativamente mais rigoroso do que, por exemplo, na pesquisa web comum. O bloqueio de uma chave significa perda de acesso aos dados e a necessidade de criar uma nova conta no Google Cloud — o que por si só é trabalhoso.

Quem e por que usa o Google Maps API nos negócios

Antes de entrar nos detalhes técnicos, vamos discutir cenários reais de uso. Isso ajudará a escolher o tipo certo de proxy e a estratégia de rotação para a tarefa específica.

Geocodificação de endereços em massa

Empresas de logística, agregadores de imóveis e marketplaces de entrega convertem regularmente milhares de endereços textuais em coordenadas. Por exemplo, ao carregar uma base de 50.000 endereços de clientes para a construção de rotas. O Geocoding API permite automatizar isso, mas 50.000 solicitações de uma única chave em um curto período é um caminho direto para o bloqueio.

Coleta de dados sobre negócios locais (Places API)

Agências de marketing, geradores de leads e bancos de dados de empresas usam o Places API para coletar informações sobre organizações: nomes, telefones, sites, classificações, horários de funcionamento, avaliações. Uma tarefa típica é coletar todos os restaurantes, dentistas ou oficinas mecânicas em várias cidades para posterior contato ou envio de e-mails.

Monitoramento de concorrentes e geoanálise

Varejistas monitoram a abertura de novos pontos de concorrentes em suas regiões. Redes de franquias analisam locais potenciais para novas lojas. Agências de publicidade verificam o geotargeting — como é a apresentação em uma cidade ou bairro específico.

Enriquecimento de dados de CRM

Produtos SaaS e serviços B2B enriquecem automaticamente os perfis de empresas em CRM: adicionam coordenadas, verificam a validade dos endereços, puxam dados do Google Business Profile. Isso requer solicitações regulares em segundo plano à API de forma automatizada.

Todos esses cenários têm uma coisa em comum: alta frequência de solicitações, que sem proxies inevitavelmente leva a bloqueios. A abordagem para a solução, no entanto, varia dependendo da tarefa.

Quais proxies são adequados para trabalhar com Google Maps API

A escolha do tipo de proxy afeta diretamente a estabilidade do trabalho e a probabilidade de bloqueios. Vamos considerar três opções principais em relação às tarefas do Google Maps API.

Proxies residenciais — a escolha ideal para a maioria das tarefas

Proxies residenciais utilizam endereços IP de usuários reais da internet. Para o Google, eles parecem pessoas comuns abrindo mapas no navegador. Isso os torna a opção mais segura para trabalhar com o Places API e geocodificação com alta frequência de solicitações. Um grande pool de IP permite fazer rotação a cada solicitação ou a cada algumas solicitações — o Google não consegue associá-los a uma única sessão.

Proxies móveis — quando a máxima confiabilidade é necessária

IPs móveis de operadoras de telefonia são um caso especial. Um único IP móvel é realmente utilizado por muitos dispositivos por meio de NAT, portanto, o Google raramente bloqueia esses endereços, mesmo com alta atividade. Se sua tarefa é crítica e não pode haver interrupções — proxies móveis proporcionarão a máxima estabilidade. A desvantagem é o preço mais alto e um pool menor de endereços.

Proxies de data center — apenas para tarefas não sensíveis

Proxies de servidor são rápidos e baratos, mas o Google Maps API os trata com suspeita elevada. Se você os usar para geocodificação de um grande volume de endereços com frequência moderada e boa rotação — eles podem funcionar. Mas para coleta do Places API ou trabalho em regiões com restrições rigorosas, o risco de bloqueio da chave é significativamente maior.

Configuração de proxies para geocodificação: guia passo a passo

Vamos discutir a configuração prática usando o Geocoding API — o cenário mais comum. Tarefa: converter uma lista de 10.000 endereços em coordenadas sem bloquear a chave.

Passo 1. Prepare a infraestrutura

Primeiro, determine o número de chaves e proxies. Regra básica: uma chave — um pool de IP. Não use o mesmo pool de proxies para diferentes chaves — o Google pode associá-los por padrões comportamentais. Para a tarefa de 10.000 endereços, recomenda-se ter pelo menos 2-3 chaves do Google Cloud e um pool de 50+ IPs residenciais.

Passo 2. Configure a rotação de IP

A estratégia ideal para geocodificação é mudar o IP a cada 10-20 solicitações, e não a cada solicitação. Mudanças muito frequentes de IP também podem parecer suspeitas. A maioria dos provedores de proxies residenciais oferece um endpoint rotativo — um único endereço que muda automaticamente o IP em um intervalo definido. Use esse endpoint, e não a troca manual.

import requests

GOOGLE_API_KEY = "SUA_CHAVE"
PROXY_HOST = "rotating.proxyprovider.com"
PROXY_PORT = "8080"
PROXY_USER = "username"
PROXY_PASS = "password"

proxies = {
    "http":  f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}",
    "https": f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}"
}

def geocode_address(address):
    url = "https://maps.googleapis.com/maps/api/geocode/json"
    params = {
        "address": address,
        "key": GOOGLE_API_KEY,
        "language": "pt"
    }
    response = requests.get(url, params=params, proxies=proxies, timeout=10)
    return response.json()

# Exemplo de uso
result = geocode_address("Moscovo, Rua Tverskaya, 1")
print(result["results"][0]["geometry"]["location"])

Passo 3. Adicione atrasos entre as solicitações

Nunca envie solicitações no modo "o mais rápido possível". Adicione um atraso aleatório de 0,5 a 2 segundos entre as solicitações. A aleatoriedade é importante — um intervalo fixo (por exemplo, exatamente 1 segundo) também parece um padrão de máquina. Em Python, isso é implementado através de time.sleep(random.uniform(0.5, 2.0)).

Passo 4. Configure os cabeçalhos de solicitação corretos

As solicitações da API para o Google Maps devem conter um User-Agent realista. Embora tecnicamente a API não exija um User-Agent de navegador, sua ausência ou um User-Agent padrão do Python aumenta a probabilidade de detecção. Use um User-Agent que imite um navegador real e não o altere com muita frequência dentro de uma única sessão.

Passo 5. Trate erros e tentativas de repetição

Implemente um tratamento adequado para os status de resposta. Ao receber OVER_QUERY_LIMIT — faça uma pausa de 60 segundos e mude o IP. Ao receber REQUEST_DENIED — a chave está bloqueada, mude para a reserva. Ao receber ZERO_RESULTS — há um problema com o endereço, não com o proxy.

Coleta de dados sobre negócios através do Places API com proxies

O Places API é um endpoint significativamente mais sensível do que o Geocoding API. O Google entende que o objetivo principal das solicitações em massa a ele é a coleta de dados comerciais, portanto, a proteção aqui é mais rigorosa. Vamos discutir a abordagem correta para trabalhar com ele.

Estratégia de coleta de dados através do Places API

O Places API funciona através de dois métodos principais: Nearby Search (busca por coordenadas e raio) e Text Search (busca por consulta textual). Para cobrir uma grande área, usa-se o método de grade — divisão da região em células sobrepostas, percorrendo sequencialmente cada célula com uma solicitação.

Uma característica chave: o Places API retorna no máximo 60 resultados por busca (3 páginas de 20). Se houver mais de 60 objetos na área — é necessário reduzir o raio de busca e aumentar a densidade da grade. Isso automaticamente aumenta o número de solicitações, tornando a rotação de proxies criticamente importante.

import requests
import time
import random

def search_places_nearby(lat, lng, radius, place_type, api_key, proxies):
    results = []
    url = "https://maps.googleapis.com/maps/api/place/nearbysearch/json"
    
    params = {
        "location": f"{lat},{lng}",
        "radius": radius,
        "type": place_type,
        "key": api_key,
        "language": "pt"
    }
    
    while True:
        response = requests.get(url, params=params, proxies=proxies, timeout=15)
        data = response.json()
        
        if data.get("status") == "OVER_QUERY_LIMIT":
            print("Limite de solicitações — pausa de 60 seg")
            time.sleep(60)
            continue
            
        results.extend(data.get("results", []))
        
        # Token da próxima página
        next_token = data.get("next_page_token")
        if not next_token:
            break
            
        # Pausa obrigatória antes da próxima página (exigência do Google)
        time.sleep(random.uniform(2.0, 3.5))
        params = {"pagetoken": next_token, "key": api_key}
    
    return results

Obtenção de dados detalhados através do Place Details

Após obter a lista de place_id através do Nearby Search ou Text Search, é necessário fazer uma solicitação separada do Place Details para cada local, a fim de obter telefone, site, horários de funcionamento e avaliações. Isso dobra o número de solicitações. Aqui, a rotação de IP é especialmente importante — cada solicitação do Place Details deve ser feita a partir de um novo endereço do pool.

Solicite apenas os campos necessários através do parâmetro fields. Isso reduz o custo da solicitação e diminui o volume de dados transmitidos, tornando o padrão de solicitações menos suspeito em termos de volume de tráfego.

Rotação de chaves e IP: como organizar um trabalho estável

Trabalhar profissionalmente com o Google Maps API requer não apenas proxies, mas uma abordagem sistemática para gerenciar chaves e IP. Aqui está como uma infraestrutura bem estruturada deve ser.

Pool de chaves do Google Cloud

Crie vários projetos na Google Cloud Console — no mínimo 3-5 para tarefas sérias. Cada projeto recebe sua própria chave de API. Distribua a carga entre as chaves de forma uniforme: se você tem 10.000 solicitações por dia e 5 chaves, cada chave faz 2.000 solicitações — significativamente abaixo do limite de suspeita.

Regra importante: vincule cada chave a um intervalo de IP separado do seu pool de proxies. A chave nº 1 funciona apenas através de IPs do intervalo A, a chave nº 2 — através do intervalo B. Misturar chaves e IPs é um dos principais erros que leva a bloqueios em massa.

Cronograma de solicitações

Não inicie todas as solicitações à noite ou fora do horário comercial — isso é um padrão atípico para um "usuário comum". Distribua as tarefas ao longo do dia, imitando a atividade natural. Se a tarefa permitir execução em vários dias — é melhor estendê-la por 3-5 dias com carga moderada do que fazer tudo em uma noite.

Monitoramento do estado das chaves

Implemente um monitoramento automático dos status das respostas da API. Ao primeiro sinal de restrições (aumento de erros OVER_QUERY_LIMIT) reduza imediatamente a frequência das solicitações para essa chave e dê a ela um "descanso" de algumas horas. Não espere um bloqueio total — consertar é significativamente mais difícil do que prevenir.

Limites do Google Maps API e como trabalhar com eles

Compreender os limites do Google Maps API é crucial para planejar a infraestrutura. Os limites são de dois tipos: cotas (quantas solicitações por dia/mês) e limites de taxa (quantas solicitações por segundo). Proxies ajudam com ambos os tipos quando usados corretamente.

Note que: os limites estão vinculados à chave, não ao IP. É por isso que a rotação de chaves em conjunto com a rotação de IP é a única maneira de escalar o trabalho sem aumentar os custos da API. Várias chaves com uma cota gratuita de $200 cada permitem aumentar significativamente o volume total de solicitações gratuitas.

Como os proxies ajudam com os limites de taxa

Um limite de taxa de 50 QPS para o Geocoding API significa: não mais que 50 solicitações por segundo de uma única chave. Proxies não ajudarão a contornar esse limite — ele está vinculado à chave. Mas eles ajudam a distribuir a carga entre as chaves de modo que cada chave permaneça na zona segura (recomendamos não exceder 70-80% do limite máximo de taxa).

Erros comuns e como evitá-los

Ao longo dos anos de trabalho com o Google Maps API, uma lista de erros típicos que levam à perda de chaves se formou. Vamos discutir cada um e oferecer uma solução específica.

Erro 1: Uso de um único IP para várias chaves

Este é o erro mais comum. Se você rotaciona chaves, mas todas as solicitações vêm de um único proxy ou de um pequeno pool de IPs — o Google vê que diferentes chaves estão sendo usadas a partir de um único endereço e as associa a uma única sessão. Quando uma chave é bloqueada, todas as outras estão em risco.

Solução: Separe rigorosamente os pools de IP por chaves. Cada chave deve funcionar apenas através de seu próprio intervalo de endereços dedicado.

Erro 2: Ignorar a pausa obrigatória entre as páginas do Places API

O Places API exige uma pausa de pelo menos 2 segundos antes de solicitar a próxima página usando pagetoken. Se você solicitar a próxima página imediatamente — a API retornará um resultado vazio ou um erro. Muitos desenvolvedores ignoram essa exigência e obtêm dados incorretos.

Solução: Sempre adicione uma pausa de 2-3 segundos antes de solicitar a próxima página. Esta é uma exigência documentada do Google, não uma recomendação opcional.

Erro 3: Chaves não protegidas no código

As chaves de API do Google Maps que caem em repositórios públicos no GitHub são automaticamente escaneadas por bots e usadas por criminosos. O Google detecta automaticamente vazamentos de chaves e envia notificações, mas o dano pode ser causado antes.

Solução: Armazene chaves em variáveis de ambiente ou sistemas de gerenciamento de segredos (Vault, AWS Secrets Manager). Nunca codifique chaves diretamente no código-fonte. Configure restrições de IP na Google Cloud Console — a chave deve funcionar apenas a partir de seus endereços de proxy.

Erro 4: Solicitar todos os campos no Place Details

Por padrão, o Place Details retorna todos os campos disponíveis, incluindo os caros (atmosfera, avaliações). Isso aumenta o custo de cada solicitação em 2-4 vezes. Além disso, um grande volume de resposta desacelera o processamento.

Solução: Sempre use o parâmetro fields e solicite apenas os dados necessários. Por exemplo: fields=name,formatted_phone_number,website,opening_hours,rating.

Erro 5: Uso de proxies gratuitos ou públicos

Proxies gratuitos de listas públicas são uma maneira certa de perder uma chave. Esses IPs já estão sendo usados por milhares de outros usuários, muitos dos quais estão fazendo exatamente o que o Google tenta proteger. A reputação desses IPs é extremamente baixa, e o Google os bloqueia preventivamente.

Solução: Use apenas proxies pagos de provedores confiáveis com IPs limpos e garantia de exclusividade de uso.

Conclusão

Trabalhar com o Google Maps API em volumes industriais é sempre um equilíbrio entre a velocidade de coleta de dados e a segurança das chaves. Proxies resolvem o problema de bloqueios por IP, mas não substituem uma arquitetura adequada: rotação de chaves, controle de frequência de solicitações, tratamento adequado de erros e separação de pools de IP por tarefas.

As principais conclusões do artigo: proxies residenciais com rotação são adequados para a maioria das tarefas com o Places API e geocodificação; cada chave deve operar através de seu próprio pool isolado de endereços; atrasos entre as solicitações são obrigatórios; o monitoramento do estado das chaves deve ser automatizado.

Se você planeja trabalhar regularmente com o Google Maps API — geocodificar endereços, coletar dados sobre negócios ou monitorar concorrentes — recomendamos considerar proxies residenciais. Eles oferecem um alto nível de confiança por parte do Google e um risco mínimo de bloqueio das chaves quando a rotação de IP é configurada corretamente. Para tarefas que exigem máxima confiabilidade sem interrupções, vale a pena considerar proxies móveis — seus IPs praticamente nunca são bloqueados, mesmo com alta atividade.