Acessibilidade da API de diferentes países: 5 métricas visíveis apenas para IP externo

Se o seu monitoramento de API está rodando em um servidor em um único data center, você verá apenas uma parte do quadro. Um usuário no Brasil pode estar recebendo um erro 500, enquanto seu painel em Moscovo mostra um status verde de "tudo funcionando". Vamos analisar quais 5 métricas de acessibilidade não podem ser medidas sem uma solicitação através de um IP externo real de outro país e como fazer isso sem uma infraestrutura complexa.

Por que o monitoramento local engana

A maioria das equipes configura o monitoramento da API através do UptimeRobot, Pingdom ou um script cron próprio que faz uma chamada ao endpoint uma vez por minuto. O problema é que essas solicitações quase sempre vêm de uma ou duas regiões — geralmente dos EUA ou da Europa, onde estão localizados os servidores dos serviços de monitoramento. Se sua audiência está na Índia, Brasil ou Sudeste Asiático, provedores locais podem estar cortando o tráfego, um nó de CDN pode estar sobrecarregado, e o DNS pode estar resolvendo para um IP desatualizado.

Outro cenário comum é o geo-blocking no nível de CDN ou WAF (Cloudflare, Akamai). Algumas regras de segurança bloqueiam faixas inteiras de IP de determinados países, e sua API pode estar fisicamente indisponível para parte dos usuários, embora do seu IP de escritório tudo funcione perfeitamente. Esses problemas são impossíveis de diagnosticar se você testar apenas de um único ponto.

Um terceiro cenário é o balanceamento de carga através de Anycast ou CDNs regionais. Uma solicitação da Alemanha pode ser direcionada para um nó, enquanto uma de Cingapura vai para outro completamente diferente, com uma versão de cache ou configuração diferente. A diferença no comportamento da API entre regiões não é teoria, mas algo que as equipes enfrentam regularmente, especialmente aquelas com usuários distribuídos pelo mundo.

5 métricas de acessibilidade visíveis apenas através de um IP externo

Abaixo estão cinco métricas que mostram o quadro real de acessibilidade apenas quando a solicitação é feita a partir de um endereço IP que está fisicamente localizado no país-alvo ou pelo menos roteado através de sua rede.

1. Tempo de resposta (Latência / RTT)

Round-Trip Time — o tempo desde o envio da solicitação até o recebimento do primeiro pacote de resposta. De um servidor na Europa, a latência até sua API pode ser de 20 ms, enquanto um usuário do Sudeste Asiático pode esperar 400-600 ms devido à distância geográfica e ao número de nós intermediários (hops). Se não medir a latência de diferentes regiões, é fácil perder o momento em que o serviço se torna praticamente inutilizável para parte da audiência — especialmente crítico para APIs que dependem de operações em tempo real: lances em publicidade, chats, transações fintech.

2. TTFB (Time To First Byte)

TTFB mostra quanto tempo o servidor leva para processar a solicitação antes de começar a enviar a resposta. Essa métrica depende não apenas da rede, mas também de qual nó da CDN ou balanceador está atendendo a região específica. Muitas vezes, um servidor edge em um país pode armazenar em cache a resposta e entregá-la em 50 ms, enquanto em outro país a solicitação chega ao servidor de origem a cada vez e é processada novamente, levando 800 ms ou mais. A diferença no TTFB entre regiões é um sinal claro de problemas de configuração da CDN ou cobertura insuficiente dos nós edge.

3. Tempo de resolução DNS

A resolução DNS é uma fonte separada de atrasos e erros, que depende totalmente do resolvedor local do usuário. Se você tem o GeoDNS configurado (diferentes registros A dependendo da região da solicitação), um erro na configuração pode fazer com que usuários de um país sejam resolvidos para um data center em outro continente — com uma enorme latência. Esse problema só é visível ao solicitar a resolução DNS de um IP real do país-alvo; um teste local sempre será resolvido "corretamente" em relação à sua própria geolocalização.

4. Percentual de solicitações bem-sucedidas (Uptime) por regiões

Uptime de 99.9% em um painel de monitoramento que faz solicitações de um único ponto não garante 99.9% para usuários em outro país. Provedores locais podem ter problemas de peering especificamente com seu provedor de hospedagem, resultando em parte das solicitações do país X falhando por timeout, enquanto o resto do mundo não percebe o problema. Para ver o uptime real, é necessário contar solicitações bem-sucedidas e não bem-sucedidas separadamente para cada região, e não de forma agregada.

5. Diferenças de conteúdo e códigos de status (geo-blocking e personalização)

A quinta métrica não é sobre velocidade, mas sobre o próprio conteúdo da resposta. A API pode retornar 403 Forbidden para determinados países devido a regras de WAF, retornar um conjunto reduzido de dados devido a restrições de licenciamento, ou mostrar uma versão diferente do conteúdo devido a testes A/B vinculados à geolocalização. Se você testar a API apenas do seu IP, tais diferenças passarão despercebidas — e são essas diferenças que frequentemente causam reclamações de usuários de regiões específicas.

Como configurar o monitoramento de diferentes países

A lógica de configuração é simples: você envia a mesma solicitação HTTP para sua API de vários pontos simultaneamente, registra todas as cinco métricas e compara os resultados. Passo a passo, isso se parece com:

1. Faça uma lista de países prioritários — geralmente os 5 principais países em termos de volume de tráfego ou receita.
2. Para cada país, prepare um ponto de saída com um IP real desse país (servidor proxy ou servidor físico).
3. Configure um script ou serviço que envie a solicitação idêntica através de cada ponto com um intervalo definido (por exemplo, a cada 5 minutos).
4. Registre todas as 5 métricas separadamente para cada país em um banco de dados ou sistema de métricas (Grafana, Prometheus, ClickHouse).
5. Configure alertas para desvios das métricas em relação ao nível básico — por exemplo, se a latência de um país específico aumentou 3 vezes em uma hora.

O ponto chave é o item 2. Sem uma saída real para o país necessário, todos os outros passos são inúteis, pois as métricas estarão medindo não o que o usuário vê, mas o que seu próprio servidor de monitoramento vê.

Qual tipo de proxy escolher para monitoramento

Para construir um monitoramento geograficamente distribuído, geralmente são utilizados servidores proxy — isso é mais barato e rápido do que alugar servidores físicos ou VPS em cada país necessário. A escolha do tipo de proxy depende do que exatamente você deseja medir.

Tipo de Proxy	Quando usar	Características
Proxies de Data Center	Verificação básica de acessibilidade e latência, quando não é necessário simular um usuário real	Alta velocidade, baixo custo, mas IP facilmente identificado como de data center — não adequado para testar geo-blocking por provedores
Proxies Residenciais	Verificação do que um usuário real vê com um provedor residencial	IP pertence a provedores reais em um país específico, refletindo mais precisamente a roteação e as regras de WAF
Proxies Móveis	Teste de acessibilidade da API para aplicativos móveis e tráfego móvel	IP de redes de operadoras móveis, mostra latências e bloqueios específicos para tráfego móvel

Se sua API atende principalmente tráfego web de desktops e servidores, para construir um monitoramento básico, proxies de data center são suficientes — eles oferecem velocidade estável e latência previsível. Mas se você precisa verificar exatamente o que um usuário real enfrenta — incluindo regras de geo-blocking configuradas por ASN do provedor — vale a pena usar proxies residenciais, pois eles são roteados através das redes de provedores de internet comuns do mesmo país. Para aplicativos móveis e SDKs que fazem solicitações à API, é sensato adicionar verificações através de proxies móveis, uma vez que as operadoras móveis frequentemente usam NAT e suas próprias regras de roteação, diferentes da internet residencial.

Script pronto em Python para coleta de métricas

Abaixo está um exemplo simplificado de um script que envia uma solicitação através de um proxy em um país específico e coleta quatro das cinco métricas (as diferenças de conteúdo precisam ser comparadas separadamente, correlacionando as respostas). O script utiliza a biblioteca requests e o módulo socket para medir o tempo de resolução DNS.

import time
import socket
import requests

def measure_api(url, proxy, country_label):
    hostname = url.split("//")[1].split("/")[0]

    # 1. Tempo de resolução DNS
    dns_start = time.time()
    try:
        socket.gethostbyname(hostname)
    except socket.gaierror:
        pass
    dns_time = time.time() - dns_start

    proxies = {
        "http": proxy,
        "https": proxy,
    }

    try:
        start = time.time()
        response = requests.get(
            url,
            proxies=proxies,
            timeout=10,
            stream=True
        )
        ttfb = time.time() - start  # TTFB aproximado

        full_load_time = time.time() - start
        status_code = response.status_code
        success = status_code == 200

        result = {
            "country": country_label,
            "dns_time_ms": round(dns_time * 1000, 2),
            "ttfb_ms": round(ttfb * 1000, 2),
            "total_time_ms": round(full_load_time * 1000, 2),
            "status_code": status_code,
            "success": success,
        }
    except requests.exceptions.RequestException as e:
        result = {
            "country": country_label,
            "dns_time_ms": round(dns_time * 1000, 2),
            "ttfb_ms": None,
            "total_time_ms": None,
            "status_code": None,
            "success": False,
            "error": str(e),
        }

    return result


# Exemplo de uso com proxies de diferentes países
endpoints = [
    {"label": "Alemanha", "proxy": "http://user:[email protected]:port"},
    {"label": "Brasil", "proxy": "http://user:[email protected]:port"},
    {"label": "Cingapura", "proxy": "http://user:[email protected]:port"},
]

API_URL = "https://api.yourservice.com/health"

for ep in endpoints:
    data = measure_api(API_URL, ep["proxy"], ep["label"])
    print(data)

Para a versão de produção desse script, é recomendável adicionar o registro dos resultados em um banco de dados (por exemplo, ClickHouse ou InfluxDB), visualização através do Grafana e alertas via bot do Telegram ou webhook do Slack ao ultrapassar valores limites. É melhor executar o script através do cron ou um agendador de tarefas com um intervalo de 5-15 minutos para cada país.

Se você precisar de uma verificação rápida sem escrever código, uma solicitação semelhante pode ser feita através do cURL medindo o tempo:

curl -x http://user:[email protected]:port \
  -o /dev/null -s -w "DNS: %{time_namelookup}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s | HTTP: %{http_code}\n" \
  https://api.yourservice.com/health

Como interpretar os resultados

Após coletar dados de todos os países por pelo menos uma semana, um nível básico (baseline) aparece para cada região. A partir daí, você deve observar não os números absolutos, mas as variações em relação a esse baseline. Se a latência do Brasil se mantém estável em 350 ms — isso é normal para a geografia, e um alerta deve ser acionado se o valor de repente subir para 1500 ms. O mesmo se aplica ao uptime: 99.5% para uma região complicada com internet instável pode ser uma norma aceitável, enquanto uma queda para 95% já é um sinal de problema do lado do provedor ou da CDN.

Atenção especial deve ser dada aos códigos de status 403 e 451 — eles quase sempre indicam geo-blocking por parte do WAF ou CDN, e não um problema com a própria API. Se esses códigos aparecem apenas de um país específico e somente ao usar proxies de um determinado tipo (por exemplo, de data center), isso pode significar que o bloqueio está configurado com base no critério "IP parece ser de um data center", e não pela geolocalização real — nesse caso, um teste com proxies residenciais dará uma imagem mais honesta.

Serviços prontos vs solução personalizada

Se você não quer manter seu próprio script, existem serviços prontos de monitoramento sintético no mercado com pontos de presença em diferentes países: Pingdom, Uptrends, Site24x7, Checkly. Eles eliminam a necessidade de configurar a infraestrutura, mas geralmente são limitados a um conjunto fixo de locais e não oferecem flexibilidade na escolha do tipo de IP (residencial, móvel, data center) para um teste específico.

Uma solução personalizada baseada em proxies oferece mais controle: você pode testar exatamente os países que são importantes para o seu negócio, alternar entre tipos de IP para diagnosticar problemas específicos (por exemplo, geo-blocking por ASN) e integrar métricas diretamente em seu sistema de monitoramento sem intermediários desnecessários. A combinação de ambas as abordagens é um equilíbrio sensato: serviços prontos para monitoramento básico de SLA, script próprio com proxies para diagnóstico pontual de problemas em regiões específicas.

Conclusão

O monitoramento local a partir de um único ponto mostra apenas uma parte da verdade sobre a acessibilidade da API. Para ver o quadro real, é necessário medir latência, TTFB, tempo de resolução DNS, uptime e diferenças de conteúdo separadamente para cada país — e fazer isso através de um IP que realmente é roteado pela rede da região-alvo. Sem isso, é fácil perder um problema que impede parte dos usuários de usar o serviço, enquanto o painel mostra "tudo verde".

Para construir esse monitoramento, proxies residenciais são os mais adequados se for importante ver o mesmo que um usuário real com internet residencial em um país específico. Para uma verificação básica de acessibilidade mais barata e rápida, proxies de data center são suficientes, enquanto para diagnosticar problemas especificamente na audiência móvel, é sensato adicionar verificações através de proxies móveis. Essa abordagem combinada fornece uma visão completa de como sua API é percebida de qualquer ponto do mundo, e não apenas do servidor onde está implantada.