Controla el uso de tu clave antes de alcanzar un límite
Vigilar las cabeceras de cuota sobre la marcha te indica cuándo te acercas a un límite, mucho antes de que se rechace realmente una solicitud.
Distingue en tus registros a los visitantes que llegan por IPv4 y por IPv6
Una dirección como 203.0.113.42 y otra como 2001:db8::1 se ven claramente distintas, pero una vez que las direcciones quedan enterradas en un archivo de registro o en una columna de una base de datos, un script que da por hecho un formato gestionará mal el otro sin avisar.
Leer el campo version
El endpoint /v1/ip devuelve un campo version en cada respuesta, 4 o 6, junto con el resto de los datos de ubicación. No hace falta que analices tú la cadena de la dirección para averiguar a qué familia pertenece.
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 qué la distinción importa para la cuota
La cuota gratuita se cuenta por red, y esa red se define de forma distinta para cada familia de direcciones: todas las direcciones IPv4 que comparten un /24 comparten una cuota, y todas las direcciones IPv6 que comparten un /48 comparten una cuota. Un solo cliente IPv6 con un bloque asignado grande puede aparecer en tus registros como muchas direcciones distintas mientras en realidad está dentro de una única cuota compartida, y conocer la versión te ayuda a agrupar las entradas del registro según el tipo correcto de límite de red, en lugar de tratar cada cadena de dirección distinta como algo sin relación.
Un caso concreto en el que esto da problemas
Un visitante con una conexión a internet doméstica que admite ambas familias de direcciones puede aparecer en tus registros como dos direcciones aparentemente sin relación en dos visitas, una IPv4 y otra IPv6, según la que su dispositivo haya usado ese día. Tratado de forma ingenua, eso parece dos visitantes distintos. Agrupar por versión junto con un identificador estable, como una cookie de sesión, en lugar de solo por la dirección sin más, evita inflar el recuento de visitantes o dividir el historial de un cliente en dos perfiles.
Gestión práctica de los registros
Cuando construyas tu propia analítica o detección de abusos sobre los registros sin procesar, bifurca según el campo version antes de intentar calcular un prefijo de red, ya que una máscara /24 no tiene sentido aplicada a una dirección IPv6 y una máscara /48 no tiene sentido aplicada a una IPv4. Guarda la versión junto a la propia dirección en lugar de volver a deducirla analizando la cadena cada vez que leas el registro.
Un error que conviene evitar
Aplicar una única expresión regular escrita para la notación decimal con puntos de IPv4 a una columna que también contiene direcciones IPv6 es una fuente silenciosa de filas del registro descartadas o mal clasificadas. Prueba de forma explícita cualquier código que analice direcciones con ambos formatos, incluida la notación abreviada con dos puntos dobles que suelen usar las direcciones IPv6, en lugar de suponer que un solo patrón cubre las dos familias.
Coste de la comprobación
Consultar la versión de esta forma cuesta una solicitud por dirección comprobada, igual que cualquier otra consulta de IP. Si estás auditando un archivo de registro grande, agrupa las direcciones en un POST masivo en lugar de hacer una solicitud por línea, con el mismo coste por elemento en muchas menos llamadas.
Tratar IPv4 e IPv6 como familias de direcciones realmente separadas, y no solo como cadenas de distinta longitud, evita un tipo de errores que solo aparece cuando el tráfico IPv6 pasa a ser una parte importante de tus visitantes. La documentación de consulta IPv6 describe el endpoint por completo.