Lista completa dos campos de dados de IP que você precisa conhecer

Pergunte "quais dados é possível obter de um endereço IP?" e a maioria das respostas para em "uma localização aproximada". Essa é a menor parte do panorama da inteligência de IP. O mesmo endereço também diz qual rede é dona dele, se é uma linha doméstica ou um servidor alugado, se é uma VPN, uma saída Tor ou um relay de privacidade, se alguma blocklist o inclui e se é um rastreador verificado. Para entender como os campos de detecção são construídos, veja como funciona a detecção de VPN e proxy.

Esta referência mudou bastante desde a versão de julho. A API ganhou três campos, nossas tabelas tinham deixado dois de fora, a pontuação de uma saída Tor passou de 79 para 100, e vários campos retornam valores que as tabelas de julho descreviam de forma errada. Todos os exemplos abaixo vêm de GET api.geoiphub.com/v1/lookup/{ip} em 22 de outubro de 2026, e você pode reproduzir qualquer um deles com a ferramenta gratuita de consulta de IP.

Contamos 103 campos em sete respostas reais em 22 de outubro de 2026

Obtivemos sete respostas em 22 de outubro de 2026, entre 04:56 e 04:57 UTC, e contamos 103 campos em 10 grupos. Cinco campos são novos nesta lista desde julho, e 11 são placeholders. Os sete endereços eram infraestrutura pública, escolhidos para acionar grupos diferentes:

Um pequeno script em Node percorreu cada resposta e listou cada campo folha, contando geo.country_names como um único campo, porque é um mapa de traduções. As sete respostas tinham exatamente as mesmas 103 chaves. Veja como elas se dividem:

Cinco campos são novos nesta lista. Três foram adicionados à API em outubro: detection.residential_proxy_status, residential_proxy_evidence e residential_proxy_last_seen. Eles já estão na referência de campos da API, marcados como reservados. Os outros dois, threat.crawler.unverified e threat.spammer_last_seen, já estavam na resposta em julho, e nossas tabelas antigas simplesmente não os incluíam. Nenhum campo da lista de julho foi removido.

Onze campos são placeholders. Verificamos o código que monta a resposta da API: dez deles são gravados como um valor vazio constante ([], "none" ou 0) em todas as consultas, e crawler.spoofed ainda não tem nenhuma fonte de dados por trás. Outros oito campos trazem dados, mas são reservados, e não publicamos seus valores: blocklist_count, ptr_pattern nos dois grupos e os cinco campos de proxy residencial. As tabelas abaixo marcam os dois tipos.

Como os 10 grupos se encaixam em uma consulta de saída Tor

Os grupos ficam mais fáceis de entender quando acompanhados em um único endereço. Esta é a resposta real para 185.220.101.1, uma saída Tor, reduzida aos campos que contam sua história:

Os grupos confirmam uns aos outros. O ASN diz hosting, detection.is_tor vem da lista de saídas do Tor Project, threat.dnsbl_sources mostra uma listagem no Spamhaus ZEN, e o grupo de pontuação junta tudo isso em block, com os quatro métodos que dispararam.

A resposta também mostra uma lacuna. ptr_record é "none", então no_ptr_datacenter disparou, mas um dig -x 185.220.101.1 ao vivo na mesma manhã retornou um hostname tor-exit. O DNS reverso armazenado pela API fica atrás do registro ao vivo em alguns endereços. Essa lacuna também explica por que rdns_tor, mostrado na versão de julho deste post, não dispara mais. Essa verificação cruzada entre grupos é o motivo para carregar tantos campos. Agora, cada grupo por vez.

1. O próprio IP (ip)

O campo ip devolve o endereço exato que a API resolveu, como string. Use-o para confirmar que você consultou o que pretendia, principalmente depois de interpretar um cabeçalho X-Forwarded-For, em que escolher o salto errado é um bug clássico. Ele também é a chave natural para o seu próprio cache.

IPv4 e IPv6 são aceitos. Se você não tem certeza de qual é o seu endereço público, a ferramenta qual é o meu IP o mostra junto com tudo o que um site consegue inferir a partir dele.

2. Dados de rede e ASN (asn)

O grupo asn diz qual rede anuncia o endereço, e está entre os dados de IP mais confiáveis que você pode obter. Todo IP roteável pertence a um Autonomous System (sistema autônomo), e essa informação vem da tabela de roteamento global, não de uma estimativa.

Os valores mudam conforme o endereço. 1.1.1.1 voltou com asn_type: "cdn" e user_type: "content_delivery_network", e o Googlebot voltou com user_type: "search_engine_spider". O egress do Private Relay retornou asn_type: "unknown", connection_type: "unknown" e user_type: "consumer_privacy_network". Uma coisa mudou desde julho: 8.8.8.8 agora retorna rpki: "valid", enquanto o exemplo da nossa documentação ainda mostra "invalid".

O campo a observar é connection_type. Um endereço de datacenter em um login de consumidor merece uma segunda olhada. Mas hospedagem, por si só, não é fraude: 45.33.32.156 é hospedagem pura e recebeu 10, allow. Você pode verificar qualquer endereço com a verificação gratuita de IP de datacenter, e a página da API de geolocalização de IP explica o modelo de ASN.

3. Dados de geolocalização (geo)

O grupo geo coloca o endereço no mapa, e é o grupo em que mais se confia além da conta. Todos os 15 campos trouxeram dados em todas as consultas que fizemos.

O país é sólido, e a cidade é aproximada. Um estudo revisado por pares sobre geolocalização por DNS reverso, com dados de 2018, mediu erros medianos de 11,1 km e 16,7 km para dois bancos de dados comerciais. Reunimos mais evidências em quão precisa é a geolocalização de IP. Trate a cidade como um raio, nunca como um ponto exato, e nunca use um IP para localizar uma pessoa.

Leia geo_confidence junto com detection.is_anycast. 1.1.1.1 retornou 0,8 para Sydney, mas também é is_anycast: true, porque o mesmo endereço é anunciado de vários lugares ao mesmo tempo. Para um endereço anycast, a cidade é uma localização plausível entre várias.

Apareceram mais duas lacunas. timezone voltou como "none" para os três endereços dos EUA que consultamos (8.8.8.8, o 66.249.66.1 do Googlebot e 45.33.32.156), enquanto a cidade veio preenchida; portanto, derive o fuso você mesmo quando precisar dele. E o egress do Private Relay 104.28.46.99 foi localizado em Luanda, Angola, enquanto a própria lista de egress da Apple coloca essa faixa em Lusaka, Zâmbia. Para relays, use a localização da linha da Apple, como explicamos em como comparar IPs de relay com a lista de egress da Apple.

4. Dados de WHOIS e registro (whois)

O grupo whois diz quem registrou o bloco e quando, obtido via RDAP nos cinco Regional Internet Registries (registros regionais de internet). Ele acrescenta uma camada de titularidade que a geolocalização não cobre.

A cobertura varia conforme o registro. 8.8.8.8 e 45.33.32.156 retornaram "none" para org, netname, status e last_changed, com apenas country e registered preenchidos. O registro do servidor da Mullvad era completo: netname: "NET-31173-185-213-155-0-24", registrado em 19/07/2017 e alterado pela última vez em 11/11/2025.

Os indicadores de palavras-chave são evidência de apoio, nunca o único motivo para sinalizar um endereço. Os dois foram false para os sete endereços, inclusive o servidor da Mullvad, cujo org no registro diz "31173 Services AB infrastructure in Frankfurt, DE." sem nenhuma menção a VPN. É por isso que as listas de provedores das próximas seções importam mais.

5. Evidências de rede (network)

O grupo network traz o DNS reverso e o contato de abuso do registro. Três dos seus sete campos são placeholders hoje.

abuse_contact é o campo a que você recorre quando precisa denunciar alguma atividade, e ele veio preenchido em cinco dos nossos sete endereços. fcrdns_valid não é um boolean simples: ele retornou a string "none" para a saída Tor, o servidor da Mullvad e o relay, que não têm PTR armazenado. Código que testa === false deixa esse caso passar.

Não confie em um PTR armazenado sem verificá-lo. Para o Googlebot 66.249.66.1, o ptr_record armazenado pertence a um endereço vizinho, enquanto um dig -x ao vivo retorna crawl-66-249-66-1.googlebot.com. Confirmamos o valor de 8.8.8.8 (dns.google) e o de 1.1.1.1 (one.one.one.one) com dig -x na mesma manhã.

open_ports fica vazio mesmo quando uma sondagem obteve resposta. Ele é gravado como [] em todas as consultas. Observe que o wireguard_open do servidor da Mullvad não é resultado de sondagem: significa que a lista de servidores da Mullvad marca aquele servidor como WireGuard. Leia resultados de sondagem como openvpn_open em scoring.detection_methods até o campo ser implementado.

6. Detecção de VPN, proxy, Tor e relay (detection)

O grupo detection responde se o endereço anonimiza o usuário, e de que forma. Com 23 campos, é o maior grupo, e três deles são novos desde julho.

vpn_provider é o campo a destacar. A maioria das APIs consegue dizer que um IP é "uma VPN"; dar nome ao operador exige uma lista de provedores. Identificamos uma VPN pelas listas de servidores de nove provedores, por uma lista pública de terceiros ou por uma pequena tabela de redes de VPN conhecidas, e vpn_confidence mostra qual caminho disparou: 95 aqui significa a própria lista da Mullvad. Quando um endereço não está em nenhuma lista, vpn_provider retorna "none" mesmo que um handshake prove que é uma VPN. Detalhamos esses caminhos em como uma VPN é identificada pela sua própria lista de servidores, e você pode testar qualquer endereço com o teste de detecção de VPN.

is_relay e relay_provider funcionam em par. 104.28.46.99 retornou is_relay: true, relay_provider: "iCloud Private Relay", pontuação 9 e allow. A API também retorna "Cloudflare WARP" para as faixas de conexão WARP publicadas pela Cloudflare, os endereços aos quais o app WARP se conecta, e um valor não documentado, "Cloudflare", para outros egress de privacidade da Cloudflare que a lista da Apple não cobre.

is_anonymous não cobre relays. A /docs o descreve como verdadeiro para qualquer anonimizador, incluindo relays, mas o egress do relay retornou is_anonymous: false com anonymity_level: "medium". O indicador acompanha apenas VPN, proxy e Tor, então leia is_relay separadamente.

Os três novos campos de proxy residencial são reservados. Eles chegaram em uma mudança de backend em outubro e ainda não estão documentados. Detecção de proxy residencial não é um recurso que oferecemos hoje, então trate os cinco campos de proxy residencial como reservados e não crie regras com base neles. Se esse tipo de tráfego preocupa você, é aqui que explicamos o que uma consulta de IP consegue e não consegue ver.

7. Inteligência de ameaças e bots (threat)

O grupo threat verifica se o endereço é conhecido como abusivo ou como um bot legítimo. Ele tem 25 campos, e sete deles são placeholders.

A saída Tor preenche a outra metade desta tabela: is_spammer: true, threat_types: ["spammer", "tor"] e dnsbl_sources: ["zen.spamhaus.org"]. O servidor da Mullvad retornou threat_types: ["vpn"], então o array também repete os indicadores de anonimizador.

O objeto crawler é onde ficam as decisões sobre bots. Para 66.249.66.1, a API retornou verified: true, name: "Googlebot", operator: "Google" e verification_method: "ip_range_list", comparado com 19 feeds oficiais de faixas de rastreadores de 10 operadores. As categorias que vimos nas consultas de outubro são search_engine, ai e fetcher. Os nomes perdem os hífens, então o fetcher acionado por usuário do Google volta como GoogleUserTriggeredFetcher.

A detecção de falsificação acontece no seu código. A API vê apenas o IP, nunca o User-Agent. Uma requisição que diz ser o Googlebot, mas retorna crawler.verified: false, não é verificada, e essa comparação cabe a você. Mostramos como fazer isso em detecção de bots por IP e em como verificar rastreadores de IA por IP, rDNS e CIDR.

is_cgnat deve suavizar uma decisão, não endurecê-la. Um endereço CGNAT é compartilhado por muitos assinantes, por isso a pontuação tem um teto nesse caso, e um único mal-intencionado não deve bloquear uma operadora inteira. Veja a visão geral de inteligência de ameaças para conhecer os feeds por trás deste grupo.

8. DNS reverso (dns)

O grupo dns repete três campos de DNS reverso de network, para que o código que só precisa de rDNS leia um único objeto pequeno. Os valores são idênticos às cópias em network em todas as respostas que obtivemos.

fcrdns_valid é o campo em que confiar. Um PTR que, na resolução direta, aponta de volta para o mesmo IP é uma evidência muito mais forte do que apenas a string do PTR, que qualquer pessoa que controle a zona reversa pode definir. Vale o mesmo cuidado da seção 5: compare um PTR armazenado com um dig -x ao vivo antes de citá-lo.

9. Pontuação de risco (scoring)

O grupo scoring transforma as evidências em uma decisão. São quatro campos, e detection_methods é o que torna a pontuação auditável.

O fraud_score combina 36 motivos ponderados, e alguns motivos subtraem. O Googlebot mostra isso: datacenter_ip e verified_crawler dispararam, e a pontuação ficou em 0. Um relay nunca chega a block, porque as pontuações de relay têm teto de 60. O recommended_action associa a pontuação a faixas:

Imprima confidence como número, não como string: ele chega com todo o ruído de ponto flutuante. Explicamos o modelo no guia da pontuação de fraude de IP e em como cada motivo define a pontuação e sua confiança, e onde definir limites em como escolher o limite da pontuação de fraude de IP para login, cadastro e checkout. Você pode pontuar qualquer endereço com a verificação de pontuação de fraude de IP.

10. Metadados (meta)

O grupo meta data a resposta e identifica a requisição. Dois dos seus cinco campos significam algo diferente do que o nome sugere.

last_classified_at é o horário da resposta, não o da classificação. Nas sete consultas, ele ficou a cerca de um segundo do momento em que enviamos a requisição. Use last_scanned para avaliar a atualidade dos dados. Ele trouxe o mesmo valor de detection.last_seen em todas as respostas, e as sete tinham data de 20 de outubro.

Dados de IP desatualizados são dados de IP errados, porque as faixas mudam de dono. O request_id é o que você informa se achar que uma classificação está errada. A latência variou de 0 a 3 ms no servidor nas sete consultas.

Como outros provedores chamam os mesmos campos

Outros provedores de dados de IP cobrem um terreno parecido com nomes de campos diferentes, e alguns reservam os campos mais ricos para planos superiores. Lemos a documentação pública de três provedores em 22 de outubro de 2026 e mantivemos apenas o que essas páginas afirmam.

Fontes: respostas dos web services GeoIP da MaxMind, dados de detecção de privacidade da IPinfo, dados de ASN da IPinfo e parâmetros de resposta da detecção de proxy da IPQualityScore.

Daí saem duas lições práticas. A escala de uma pontuação só faz sentido ao lado dos limites documentados: o 75 da IPQualityScore é "suspeito", enquanto o nosso 76 já é block. E um campo com o mesmo nome pode significar coisas diferentes, então mapeie os campos pelo significado documentado, não pelo nome. Nosso checklist do comprador para escolher um provedor de dados de IP transforma isso em um teste curto que você pode aplicar a qualquer API.

Quais campos de dados de IP importam para cada decisão

Raramente você precisa dos 103 campos de uma vez. Associe os campos à decisão e ignore os placeholders:

Em uma investigação, a ordem em que você lê os grupos importa tanto quanto os campos. Nosso guia passo a passo para investigar um endereço IP acompanha três IPs reais em doze verificações passivas que usam esses grupos em sequência.

Verifique os campos você mesmo antes de construir

A lista de campos muda com o tempo, então o hábito mais seguro é contá-la você mesmo. Faça uma consulta e liste as chaves folha:

O filtro conta cada array como um campo, ignora os elementos dos arrays e soma country_names de volta como um campo. Ele imprimiu 103 para as sete respostas que salvamos. Se o seu número for diferente, compare as chaves com a referência da API e com este post. Se você testar sem chave, espace as chamadas: a 30ª requisição sem chave dentro de um minuto já retorna 429 e bloqueia o seu IP por duas horas.

Perguntas frequentes

Quais dados é possível obter de um endereço IP?

Muito mais do que uma localização. Uma consulta real na GeoIPHub em 22 de outubro de 2026 retornou 103 campos em 10 grupos: o próprio IP, a rede (ASN, ISP, tipo de conexão, RPKI), geolocalização aproximada, dados de registro WHOIS, evidências de rede e DNS reverso, detecção de VPN, proxy, Tor e relay com o nome do provedor quando ele está em uma lista, sinais de ameaça e de rastreador verificado, uma pontuação de risco explicável de 0 a 100 e metadados da requisição. Onze desses campos são placeholders que hoje retornam um valor vazio fixo.

Um endereço IP pode revelar o endereço exato da minha casa?

Não. A geolocalização de IP estima uma área aproximada (no máximo uma cidade ou região), nunca um endereço de rua nem uma pessoa específica. Resultados no nível de cidade são imprecisos, e conexões móveis, CGNAT e VPN os tornam ainda mais fracos. Quem promete precisão de endereço apenas a partir de um IP está exagerando.

O que é um ASN nos dados de IP?

Um Autonomous System Number (número de sistema autônomo) identifica a rede que anuncia um endereço IP para a internet. Por exemplo, 8.8.8.8 retorna AS15169, GOOGLE - Google LLC. O ASN e sua organização vêm da tabela de roteamento global, por isso estão entre os campos de dados de IP mais confiáveis, ao contrário de um palpite sobre a localização física.

O que é uma pontuação de fraude de IP e como ela é calculada?

Uma pontuação de fraude de IP é um único número de 0 a 100 que resume quão arriscado um endereço parece. A GeoIPHub combina 36 motivos ponderados, subtrai os que inocentam, como um rastreador verificado, e retorna os métodos exatos que dispararam, além de uma ação recomendada: allow até 25, review até 50, step_up até 75, block acima de 75. Uma saída Tor que consultamos em 22 de outubro de 2026 recebeu 100, com quatro métodos listados.

Qual é a diferença entre um IP residencial e um IP de datacenter?

Um IP residencial é atribuído por um ISP de consumo a uma conexão doméstica; um IP de datacenter (hospedagem) pertence a um provedor de nuvem ou de servidores. A distinção está nos campos asn.connection_type e asn.asn_type. Nas nossas sete consultas de outubro, o servidor de VPN da Mullvad, a saída Tor e o Googlebot voltaram todos com connection_type datacenter.

Todos os provedores de API de IP retornam os mesmos campos em todos os planos?

Não. A documentação da IPinfo diz que o plano Core inclui apenas os indicadores de privacidade is_anonymous e is_hosting, com campos de privacidade mais completos nos planos Plus, Max e em APIs personalizadas. A GeoIPHub retorna todos os campos em todos os planos, inclusive no plano gratuito de 1.500 consultas por dia.

O que significa raio de precisão na geolocalização de IP?

O raio de precisão é a distância, em quilômetros, ao redor das coordenadas retornadas dentro da qual a localização real provavelmente está. A MaxMind o documenta como location.accuracy_radius. A GeoIPHub não retorna um raio; ela retorna geo.geo_confidence, um valor de 0 a 1 que fica em 0 quando não há evidências suficientes para indicar uma cidade.