Monitore o uso da sua chave antes de atingir um limite
Acompanhar seus cabeçalhos de cota ao longo do caminho mostra quando um limite está se aproximando, bem antes de uma requisição ser realmente rejeitada.
Diferencie visitantes IPv4 e IPv6 nos seus logs
Um endereço como 203.0.113.42 e outro como 2001:db8::1 parecem obviamente diferentes, mas quando os endereços estão enterrados em um arquivo de log ou em uma coluna de banco de dados, um script que presume um formato vai tratar o outro de forma errada sem avisar.
Como ler o campo version
O endpoint /v1/ip retorna um campo version em todas as respostas, 4 ou 6, junto com o restante dos dados de localização. Não é preciso analisar a string do endereço por conta própria para descobrir a qual família ele pertence.
GET /v1/ip?ip=2001:db8::1{
"status": "ok",
"ip": "2001:db8::1",
"version": 6,
"found": true,
"country": "Canada",
"country_code": "CA",
"region": "Ontario",
"city": "Toronto",
"postcode": "M5H",
"lat": 43.6511,
"lon": -79.3808,
"timezone": "America/Toronto",
"asn": 4321,
"org": "Example ISP"
}Por que a distinção importa para a cota
A cota gratuita é contada por rede, e essa rede é definida de forma diferente para cada família de endereços: todos os endereços IPv4 que compartilham um /24 compartilham uma cota, e todos os endereços IPv6 que compartilham um /48 compartilham uma cota. Um único cliente IPv6 com um grande bloco alocado pode aparecer como muitos endereços diferentes nos seus logs, embora esteja dentro de uma única cota compartilhada, e saber a versão ajuda a agrupar as entradas de log pelo tipo certo de limite de rede, em vez de tratar cada string de endereço distinta como algo sem relação.
Um caso concreto em que isso causa problemas
Um visitante com uma conexão de internet residencial que suporta as duas famílias de endereços pode aparecer nos seus logs como dois endereços aparentemente sem relação em duas visitas, um IPv4 e um IPv6, dependendo de qual deles o dispositivo usou naquele dia. Tratado de forma ingênua, isso parece dois visitantes diferentes. Agrupar pela versão junto com um identificador estável, como um cookie de sessão, em vez de apenas pelo endereço bruto, evita inflar a contagem de visitantes ou dividir o histórico de um cliente em dois perfis.
Tratamento prático de logs
Quando você escreve sua própria análise ou detecção de abuso sobre logs brutos, crie uma ramificação com base no campo version antes de tentar calcular um prefixo de rede, já que uma máscara /24 não faz sentido aplicada a um endereço IPv6 e uma máscara /48 não faz sentido aplicada a um endereço IPv4. Armazene a versão junto com o próprio endereço, em vez de deduzi-la novamente analisando a string toda vez que ler o log.
Um erro que vale a pena evitar
Aplicar uma única expressão regular escrita para a notação IPv4 com pontos a uma coluna que também contém endereços IPv6 é uma fonte silenciosa de linhas de log descartadas ou classificadas errado. Teste qualquer código de análise de endereços explicitamente com os dois formatos, incluindo a notação abreviada com dois-pontos duplos que os endereços IPv6 costumam usar, em vez de presumir que um padrão cobre as duas famílias.
Custo da verificação
Consultar a versão dessa forma custa uma requisição por endereço verificado, igual a qualquer outra consulta de IP. Se você estiver auditando um arquivo de log grande, envie os endereços em lote por meio de um POST em massa, em vez de uma requisição por linha, mantendo o mesmo custo por item em muito menos chamadas.
Tratar IPv4 e IPv6 como famílias de endereços realmente separadas, e não apenas como strings de tamanhos diferentes, evita uma classe de bugs que só aparece quando o tráfego IPv6 passa a representar uma parcela significativa dos seus visitantes. A documentação de consulta IPv6 cobre o endpoint por completo.