Identifique o provedor de VPN por trás de um IP pela própria lista de servidores dele
Identifique o provedor de VPN por trás de um IP comparando-o com a lista de servidores que o provedor publica. Em nenhum IP que consultamos o WHOIS mencionou uma VPN.

Baixamos a lista de relays da Mullvad às 05:22 UTC de 13 de outubro de 2026. Ela tinha 566 relays, 553 servidores WireGuard e 13 bridges, e a Mullvad marca apenas 124 deles como hardware próprio. Um dos próprios, 185.213.155.73 em Frankfurt, está registrado no WHOIS em nome de "31173 Services Germany", não tem DNS reverso e é anunciado pelo AS39351. Nada no registro de rede dele diz "Mullvad". Só a lista diz.
Esse é todo o truque por trás de qualquer ferramenta de "qual VPN é este IP", e quase nenhuma delas conta isso. A seguir listamos os endpoints onde os provedores publicam seus servidores, damos um script de correspondência em Python testado e mostramos o que a nossa API retornou para os servidores listados pelos provedores que consultamos, além de controles, incluindo os erros. No fim há uma tabela de políticas. Para o lado da detecção, ou seja, como uma VPN é pega em primeiro lugar, leia como a detecção de VPN funciona, sinal por sinal.

É possível saber a qual VPN um endereço IP pertence?
Sim, quando o IP está em uma lista que o provedor publica. Um app de VPN precisa saber onde estão os servidores antes de se conectar, então os provedores entregam essa lista aos apps, e a maioria dessas listas é pública. Se o endereço não está em nenhuma lista, em geral ainda dá para saber que é uma VPN por sondagens e sinais de hospedagem, mas não de quem.
Veja 185.213.155.73 rastreado de ponta a ponta. A lista da Mullvad, em api.mullvad.net/www/relays/all/, tem uma linha para ele com hostname "de-fra-wg-001", type "wireguard", city_name "Frankfurt", owned true e provider "31173". Esse último campo é a empresa de hospedagem, e aqui é a da própria Mullvad.
O registro conta outra história. O registro RDAP do RIPE, que abrimos às 05:28 UTC, chama a faixa de NET-31173-185-213-155-0-24 e o titular de "31173 Services Germany". O objeto de rota do whois do RIPE informa a origem AS39351. Rodamos dig -x 185.213.155.73 e não obtivemos resposta nenhuma.
Depois consultamos o IP na nossa API às 05:27 UTC. Esta é uma cópia resumida, com os valores sem edição:
{
"ip": "185.213.155.73",
"asn": {
"asn": 39351,
"org": "ESAB-AS - 31173 Services AB"
},
"whois": {
"org": "31173 Services AB infrastructure in Frankfurt, DE.",
"netname": "NET-31173-185-213-155-0-24",
"has_vpn_keywords": false
},
"detection": {
"is_vpn": true,
"vpn_provider": "Mullvad",
"vpn_confidence": 95
},
"scoring": {
"fraud_score": 100,
"recommended_action": "block",
"detection_methods": ["known_vpn_server", "wireguard_open", "datacenter_with_vpn_proxy", "no_ptr_datacenter"]
}
}
Observe whois.has_vpn_keywords. Ele é false, em um servidor da Mullvad, e foi false em todos os endereços que consultamos. O texto do WHOIS nunca menciona uma VPN. O nome "Mullvad" veio da correspondência com a lista, e vpn_confidence 95 é o valor que a nossa API atribui a esse caminho. O bloqueio veio das evidências: uma entrada na lista do provedor marcada como WireGuard, em um endereço de hospedagem.
Por que WHOIS, DNS reverso e ASN mostram o host, não a VPN
A maioria dos servidores de VPN roda em máquinas alugadas, então o registro de rede descreve o locador. Na nossa amostra, a M247 (AS9009) hospeda servidores listados da NordVPN, PIA, AirVPN, IVPN e FastestVPN. A Datacamp (AS212238) hospeda um servidor da Mullvad em Nova York e um servidor da IVPN em Buenos Aires. Uma regra que diz "M247 significa VPN" é um palpite sobre uma empresa de hospedagem. A lista do provedor é uma evidência sobre um servidor.
A Mullvad demonstra isso por nós. A lista dela marca cada relay com owned true ou false e informa o host em provider. Em 13 de outubro, 124 dos seus 566 relays eram owned: true, e os hosts mais comuns eram DataPacket (128 relays), Tzulo (127) e M247 (98). Consultamos dois relays alugados da Mullvad às 05:33 UTC:
| Relay da Mullvad, segundo a lista | Host na lista | Nosso asn.org | vpn_provider, vpn_confidence | Pontuação, ação |
|---|---|---|---|---|
| 149.22.83.2, ar-bue-wg-001, owned false | DataPacket | CDNEXT - Datacamp Limited | Mullvad, 95 | 99, block |
| 91.90.123.2, be-bru-wg-101, owned false | M247 | M247 - M247 Europe SRL | Mullvad, 95 | 100, block |
Uma verificação de ASN em qualquer um deles diz "empresa de hospedagem". A lista diz Mullvad. O relay de Nova York us-nyc-wg-301, 143.244.47.65, conta a mesma história na Datacamp.
O DNS reverso é ainda mais fraco. Rodamos dig -x em 20 dos endereços listados pelos provedores às 05:28 UTC. Onze não retornaram nada, e nenhum dos outros nove mencionava uma marca de VPN:
| IP | Listado por | O que dig -x retornou |
|---|---|---|
| 143.244.47.65 | Mullvad | unn-143-244-47-65.datapacket.com |
| 149.22.83.100 | IVPN | unn-149-22-83-100.datapacket.com |
| 198.44.137.44 | Windscribe | static-198-44-137-44.cust.tzulo.com |
| 204.13.164.252 | Riseup | leapgwv6.bitmask.net |
| 185.244.212.69 | IVPN | 185.244.212.69.adsl.inet-telecom.org |
| 185.213.155.73 | Mullvad | sem PTR |
O nome da Riseup sugere o software de VPN, LEAP e Bitmask, não uma marca. O nome da IVPN em Viena diz "adsl", o que parece uma conexão doméstica, em um servidor que a IVPN lista. Esse é o perigo de interpretar demais um PTR.
O ASN mostra a VPN apenas quando o provedor opera a própria rede, como a Mullvad faz com o AS39351 e a Riseup com o AS16652. Se quiser o contexto, veja o que é um ASN e quem ele identifica. Nossa API mantém uma pequena tabela de redes operadas por provedores de VPN, com o AS39351 da Mullvad nela, e essa tabela é um dos quatro caminhos de identificação descritos abaixo.
Onde os provedores de VPN publicam os IPs dos seus servidores
Estas são as listas que os próprios apps dos provedores leem. "Baixada hoje" significa que a nossa rede recebeu uma resposta 200 em 13 de outubro de 2026; "inacessível hoje" significa que a requisição falhou a partir da nossa rede após duas tentativas.
| Provedor | Lista que o app lê | Onde está o IP | Status em 13 de outubro de 2026 |
|---|---|---|---|
| Mullvad | api.mullvad.net/www/relays/all/ | ipv4_addr_in, ipv6_addr_in | Baixada hoje, 05:22 UTC: 566 relays, 124 próprios |
| AirVPN | airvpn.org/api/status/ | ip_v4_in1 a ip_v4_in4 | Baixada hoje, 05:22 UTC: 250 servidores |
| IVPN | api.ivpn.net/v5/servers.json | Entradas host de WireGuard e OpenVPN | Baixada hoje, 05:22 UTC: 89 hosts WireGuard em 59 locais |
| PrivadoVPN | privadovpn.com/apps/servers_export.json | ip | Baixada hoje, 05:22 UTC: 167 servidores |
| Riseup | api.black.riseup.net/3/config/eip-service.json, encontrada via riseup.net/provider.json | ip_address | Baixada hoje, 05:23 UTC: 21 gateways |
| NordVPN | api.nordvpn.com/v2/servers, segundo o atualizador da NordVPN do gluetun | station | Inacessível hoje (tempo esgotado) |
| Surfshark | api.surfshark.com/v4/server/clusters, segundo o atualizador da Surfshark do gluetun | Apenas hostnames | Inacessível hoje (erro de TLS, depois tempo esgotado) |
| Private Internet Access | serverlist.piaservers.net/vpninfo/servers/v6, segundo o próprio get_region.sh da PIA | IPs dos servidores por região | Inacessível hoje (erro de TLS) |
| Windscribe | assets.windscribe.com/serverlist/mob-v2/1/, segundo o atualizador da Windscribe do gluetun | ip, ip2, ip3 | Inacessível hoje (tempo esgotado) |
Os quatro que não conseguimos acessar são endpoints reais. Nós os conhecemos pelos clientes oficiais ou de código aberto dos provedores, e o código da NordVPN no gluetun inclusive comenta que o campo station "is, it seems, the entry IP address" ("parece ser o endereço IP de entrada"). As APIs deles bloqueiam requisições vindas de datacenters, que é onde o nosso scanner roda, e em 13 de outubro também não responderam à rede que usamos para este post.
Então a nossa API identifica VPNs a partir das listas de servidores dos próprios provedores mais uma lista pública de terceiros. Para NordVPN, PIA e Windscribe, nosso scanner recorre a cópias salvas das respostas das APIs deles, datadas de 4 de outubro de 2026. Não temos nenhuma cópia da Surfshark. A lista de terceiros é a gluetun-servers, os dados de servidores mantidos pela comunidade por trás do gluetun, um contêiner de cliente VPN de código aberto. Carregamos os arquivos dela para mais de 20 provedores, e ela é a nossa única fonte para a FastestVPN. Os quatro arquivos dela que baixamos hoje, de ExpressVPN, FastestVPN, NordVPN e PIA, trazem todos a data de 6 de agosto de 2026.
Identifique você mesmo um provedor de VPN pelo IP: Mullvad e NordVPN
Baixe a lista do provedor e procure uma correspondência exata do endereço. A Mullvad é o caso fácil, porque a lista dela respondeu todas as vezes que pedimos. Este é o script que rodamos às 05:29 UTC de 13 de outubro de 2026, em Python 3.9.6, apenas com a biblioteca padrão:
"""Check IPs against Mullvad's public relay list. Standard library only."""
import ipaddress, json, sys, urllib.request
URL = "https://api.mullvad.net/www/relays/all/"
def load_relays(url=URL):
with urllib.request.urlopen(url, timeout=30) as resp:
relays = json.load(resp)
index = {}
for r in relays:
for key in ("ipv4_addr_in", "ipv6_addr_in"):
if r.get(key):
index[ipaddress.ip_address(r[key])] = r
return relays, index
def match(index, ip):
try:
addr = ipaddress.ip_address(ip.strip())
except ValueError:
return None
if addr.version == 6 and addr.ipv4_mapped:
addr = addr.ipv4_mapped # ::ffff:141.98.252.67 becomes 141.98.252.67
return index.get(addr)
if __name__ == "__main__":
try:
relays, index = load_relays()
except Exception as e:
sys.exit(f"could not load Mullvad's list: {e}")
print(f"{len(relays)} relays, {len(index)} addresses")
ips = sys.argv[1:] or [line for line in sys.stdin if line.strip()]
for ip in ips:
r = match(index, ip)
if r:
result = f"{r['hostname']} {r['type']} {r['city_name']} owned={r['owned']} host={r['provider']}"
else:
result = "not on Mullvad's list"
print(f"{ip.strip():22} {result}")
Passamos sete entradas na linha de comando, e ele imprimiu:
566 relays, 1122 addresses
185.213.155.73 de-fra-wg-001 wireguard Frankfurt owned=True host=31173
143.244.47.65 us-nyc-wg-301 wireguard New York, NY owned=False host=DataPacket
45.83.220.68 se-mma-wg-101 wireguard Malmö owned=True host=31173
45.83.220.7 not on Mullvad's list
::ffff:141.98.252.67 gb-lon-wg-001 wireguard London owned=True host=31173
102.129.235.17 not on Mullvad's list
not-an-ip not on Mullvad's list
Também passamos três linhas com linhas em branco e espaços extras pelo stdin, do jeito que você alimentaria uma coluna de log, e ele associou 45.83.220.70 a se-mma-wg-103. Apontado para uma URL que retorna 404, ele imprimiu "could not load Mullvad's list: HTTP Error 404: Not Found" e saiu com status 1. Duas ressalvas: uma entrada inválida é reportada como fora da lista, e não como erro, e as 13 bridges também são associadas, então leia a coluna type.
Como detectar a NordVPN do mesmo jeito. A lista da NordVPN coloca o IP de cada servidor em um campo station, e a nossa cópia salva de 4 de outubro tem um por servidor. O endpoint ao vivo esgotou o tempo a partir da nossa rede em 13 de outubro, duas vezes, então não vamos publicar código da NordVPN que não conseguimos rodar. Rode a mesma lógica de correspondência exata a partir de uma rede que a NordVPN responda.
Para um endereço por vez, você pode verificar qualquer IP em busca de VPN e do seu provedor; a ferramenta retorna o nome em detection.vpn_provider. Em código, é uma requisição com o IP no caminho:
curl https://api.geoiphub.com/v1/lookup/185.213.155.73 \
-H "x-api-key: YOUR_API_KEY"
vpn_provider está no plano gratuito, que inclui todos os campos de dados com 1.500 consultas por dia. Se você basear alguma regra no nome, compare o início, não a string inteira: nossa API retornou "Mullvad" para servidores listados e "Mullvad (31173 Services)" para o caminho do ASN. Este é o trecho que rodamos às 05:34 UTC, sem chave:
import json, sys, urllib.request
def lookup(ip, key=None):
# A custom User-Agent: our API answered Python's default one with a 403.
headers = {"User-Agent": "vpn-provider-check/1.0"}
if key:
headers["x-api-key"] = key
req = urllib.request.Request(f"https://api.geoiphub.com/v1/lookup/{ip}", headers=headers)
with urllib.request.urlopen(req, timeout=10) as resp:
return json.load(resp)
for ip in sys.argv[1:]:
data = lookup(ip)
provider = data["detection"]["vpn_provider"]
named = provider != "none"
is_mullvad = provider.startswith("Mullvad") # "Mullvad" or "Mullvad (31173 Services)"
print(ip, repr(provider), "named" if named else "unnamed",
"mullvad" if is_mullvad else "-", "is_vpn" if data["detection"]["is_vpn"] else "not_vpn",
data["scoring"]["recommended_action"])
185.213.155.73 'Mullvad' named mullvad is_vpn block
45.83.220.7 'Mullvad (31173 Services)' named mullvad is_vpn review
102.129.235.17 'none' unnamed - is_vpn block
A terceira linha é a que deve orientar o seu design: sem nome, ainda é uma VPN, ainda é um bloqueio.
Se a sua pergunta é a outra, se a sua própria conexão aparece como NordVPN, abra veja o IP que a sua conexão mostra enquanto estiver conectado.
O que a nossa API retornou para IPs listados pelos provedores
Os servidores listados de todos os provedores da nossa amostra voltaram identificados, e vpn_confidence mostra qual dos quatro caminhos os identificou. Em uma linha identificada, o valor corresponde ao caminho:
| vpn_confidence | Caminho que identificou o IP |
|---|---|
| 95 | A própria lista de servidores do provedor |
| 90 | Um hostname de servidor dos arquivos do gluetun, resolvido por nós para este IP |
| 85 | Uma pequena tabela de redes operadas por um provedor de VPN |
| 80 | A lista pública de servidores do gluetun |
Fizemos estas consultas entre 05:27 e 05:28 UTC de 13 de outubro de 2026. A última coluna mostra apenas as sondagens de handshake de VPN que responderam; deixamos o restante de detection_methods fora da tabela.
| IP | Provedor e servidor, segundo a lista | Onde encontramos o IP | vpn_provider | vpn_confidence | Pontuação, ação | Sondagem que respondeu |
|---|---|---|---|---|---|---|
| 185.213.155.73 | Mullvad, de-fra-wg-001 | Mullvad, baixada hoje | Mullvad | 95 | 100, block | wireguard_open |
| 143.244.47.65 | Mullvad, us-nyc-wg-301, owned false | Mullvad, baixada hoje | Mullvad | 95 | 99, block | wireguard_open |
| 82.102.19.137 | NordVPN, be148 | Cópia da NordVPN de 4 de out.; também no gluetun | NordVPN | 80 | 99, block | wireguard_open |
| 173.239.247.129 | PIA, Vietnã | Cópia da PIA de 4 de out.; também no gluetun | PIA | 80 | 51, step_up | nenhuma |
| 198.44.137.44 | Windscribe, Dallas, us-central-117 | Cópia da Windscribe de 4 de out. | Windscribe | 95 | 100, block | ipsec_open, wireguard_open |
| 185.156.175.170 | AirVPN, Achernar, Zurique | AirVPN, baixada hoje | AirVPN | 95 | 99, block | wireguard_open |
| 149.22.83.100 | IVPN, ar1.wg, Buenos Aires | IVPN, baixada hoje | IVPN | 95 | 99, block | wireguard_open |
| 85.12.5.56 | PrivadoVPN, hkg-006 | PrivadoVPN, baixada hoje | PrivadoVPN | 90 | 36, review | nenhuma |
| 204.13.164.252 | Riseup, vpn01-sea | Riseup, baixada hoje | Riseup | 95 | 48, review | nenhuma |
| 31.171.152.205 | ExpressVPN, Albânia | Arquivo do gluetun de 6 de ago. | ExpressVPN | 80 | 51, step_up | nenhuma |
| 46.102.153.134 | FastestVPN, au-stream, Sydney | Arquivo do gluetun de 6 de ago. | FastestVPN | 90 | 99, block | wireguard_open |
| 45.83.220.7 | Fora da lista da Mullvad | Nenhum | Mullvad (31173 Services) | 85 | 46, review | nenhuma |
Três linhas merecem um comentário. Os servidores da NordVPN e da PIA estão nas nossas cópias salvas, mas voltaram com 80, o valor do gluetun, e ambos estão nos arquivos do gluetun. O servidor da PrivadoVPN está hoje na exportação da própria PrivadoVPN, mas voltou com 90, não 95: seu nome veio da resolução do hostname, hkg-006.vpn.privado.io, que o arquivo da PrivadoVPN no gluetun também traz. Leia o caminho em vpn_confidence, não na lista em que você encontrou o IP. A ExpressVPN não está entre os nove provedores cujas listas próprias baixamos. Um endereço da ExpressVPN listado no gluetun voltou identificado, o que mostra que o caminho funciona, não que cobrimos a ExpressVPN.
A última linha é o caminho do ASN. 45.83.220.7 não está na lista da Mullvad; a lista de hoje tem .68, .69 e .70 nesse /24, não .7. Ele é identificado porque a sua rede, o AS39351, pertence ao operador da Mullvad:
{
"ip": "45.83.220.7",
"asn": {
"asn": 39351,
"org": "ESAB-AS - 31173 Services AB"
},
"whois": {
"org": "31173 Services AB infrastructure in Malmo, SE.",
"netname": "NET-31173-45-83-220-0-24",
"has_vpn_keywords": false
},
"detection": {
"is_vpn": true,
"vpn_provider": "Mullvad (31173 Services)",
"vpn_confidence": 85
},
"scoring": {
"fraud_score": 46,
"recommended_action": "review",
"detection_methods": ["known_vpn_server", "datacenter_ip"]
}
}
Repare que known_vpn_server também é acionado aqui. O nome desse método não significa "está na lista de um provedor"; nesta linha ele vem da tabela de redes. Leia vpn_confidence para saber o caminho, e apenas nas linhas em que vpn_provider não é "none".
Por que alguns IPs de VPN voltam como "none"
"none" significa que o IP não está em nenhuma das listas que temos neste momento. Não significa que o IP não seja uma VPN, nem que um endereço vizinho do provedor esteja limpo.
O servidor pl128 da NordVPN, 194.99.105.99, está na resposta da NordVPN que salvamos em 4 de outubro, listado como online. Hoje ele retornou vpn_provider "none", mas is_vpn true, pontuação 98 e block, com ipsec_open entre os seus métodos. O handshake IPsec o denunciou; nada o identificou pelo nome. O servidor da PIA em Liechtenstein, 91.90.122.25, está na lista da PIA do mesmo dia. Hoje ele retornou is_vpn false e pontuação 64, step_up, apenas por sinais de blocklist e de hospedagem.
Nenhum desses dois endereços está nos arquivos do gluetun, enquanto as linhas identificadas da NordVPN e da PIA acima estão. Não conseguimos baixar de novo a API da NordVPN nem a da PIA hoje, então qualquer um dos servidores pode ter sido desativado ou mudado de endereço desde 4 de outubro. O que podemos afirmar é mais restrito e certo: um servidor só é identificado quando está em uma lista que temos no momento.
Também temos um erro em um provedor cuja lista baixamos hoje. 91.90.123.29 está no mesmo /24 que o relay listado da Mullvad 91.90.123.2, mas não está na lista da Mullvad. A página de provedores do IPinfo o mostrava como IP de exemplo da Mullvad em 13 de outubro. Nossa API retornou is_vpn false, vpn_provider "none", pontuação 12, allow. Pode ser uma saída ou um endereço não listado ao lado de um listado; isso é um indício, não uma prova. De qualquer forma, uma correspondência com a lista cobre o endereço listado e nada ao lado dele.
O controle documentado mostra o caso sem nome, mas detectado. 102.129.235.17, no AS834 IPXO, retornou is_vpn true, vpn_provider "none", pontuação 92, block, com known_vpn_server, openvpn_open e ipsec_open. Um servidor sem nome ainda é pego quando completa um handshake OpenVPN ou IPsec com o nosso scanner; o post principal citado acima explica as sondagens.
Motivos comuns para um IP de VPN continuar sem nome:
- Nenhuma lista pública. Alguns provedores não publicam nenhuma, e uma VPN auto-hospedada nunca aparece em uma.
- Lista inacessível. Quatro das nove listas que baixamos bloqueiam datacenters, então trabalhamos com cópias salvas quando as temos, e com o gluetun.
- Rotação. Um servidor pode sair da lista ou mudar de endereço depois da nossa última cópia.
- É um proxy, não uma VPN. Proxies não têm lista de provedor para comparar; veja proxies de datacenter, residenciais e móveis.
O iCloud Private Relay e o Cloudflare WARP não são provedores de VPN nesse sentido. Eles têm o próprio campo, relay_provider, e a própria política, explicados em iCloud Private Relay e Cloudflare WARP.
Uma VPN identificada não é uma VPN mais arriscada
O nome diz quem opera o servidor; a pontuação vem das evidências, como portas de handshake abertas, hospedagem e histórico de abuso. Algumas das pontuações mais baixas da nossa amostra foram para servidores identificados, e uma das mais altas foi para um sem nome.
| IP | vpn_provider | Pontuação, ação |
|---|---|---|
| 85.12.5.56 | PrivadoVPN | 36, review |
| 45.83.220.7 | Mullvad (31173 Services) | 46, review |
| 204.13.164.252 | Riseup | 48, review |
| 102.129.235.17 | none | 92, block |
Nossas faixas são allow até 25, review até 50, step_up até 75 e block acima de 75. O servidor da PrivadoVPN não respondeu a nenhuma sondagem de handshake nos nossos dados, então só known_vpn_server foi acionado e ele ficou em review. O servidor sem nome respondeu a duas. É assim que deve ser: uma regra deve pesar o que observamos, não de quem é o logotipo no servidor. Os pesos dos sinais estão na página como a pontuação é calculada.
IPs de entrada, servidores rotacionados e nomes desatualizados
Uma lista de provedor informa o endereço ao qual o app se conecta. Para a maioria dos servidores da nossa amostra, esse mesmo endereço respondeu às nossas sondagens, mas verificamos apenas que os endereços listados são identificados, não que todo endereço de saída usado por um provedor esteja em uma lista.
Os nomes dos campos dizem "in". A Mullvad usa ipv4_addr_in, e a AirVPN publica quatro endereços por servidor, de ip_v4_in1 a ip_v4_in4. A lista da Surfshark traz apenas hostnames, então alguém precisa resolver os nomes para IPs antes que qualquer coisa possa corresponder. Nosso caminho 90 faz isso para os hostnames de servidores nos arquivos do gluetun. Foi assim que o au-stream.jumptoserver.com da FastestVPN, 46.102.153.134, ganhou seu nome.
As listas também trazem estados que você deve ler. A lista da Mullvad de hoje marca 24 relays como active: false, incluindo se-mma-wg-101, 45.83.220.68, que a nossa API ainda identifica como "Mullvad" com 95. Um servidor listado é um fato sobre a frota do provedor, não uma prova de que o servidor transportou tráfego hoje. É também por isso que as contagens de IPs de VPN dos fornecedores divergem tanto. Elas contam coisas diferentes, como servidores, endereços de entrada listados, endereços de saída observados ou faixas inteiras, em datas diferentes. A lista da própria Mullvad é a única contagem que citamos. Não publicamos aqui um cronograma de atualização das listas de provedores; se você rodar o script de correspondência por conta própria, baixe a lista antes de cada lote.
O que fazer com o nome de um provedor
Use o nome para políticas e investigação, não como chave de bloqueio. Baseie as decisões em recommended_action e nas evidências por trás dele, e baseie exceções e relatórios no nome.
| O que você vê | Ação | Por quê |
|---|---|---|
VPN identificada (vpn_provider preenchido) | Siga recommended_action; use o nome para as allow-lists que você escolher, logs de licenciamento e agrupamento de abuso por operador | O nome é atribuição, não risco: a PrivadoVPN teve 36, review, e o servidor da Mullvad em Frankfurt 100, block |
VPN sem nome (is_vpn true, vpn_provider "none") | Trate exatamente como uma VPN identificada com a mesma pontuação | 102.129.235.17 teve 92 sem nome |
Relay (is_relay true) | Permita e pontue a sessão | Relays não são provedores de VPN; eles usam relay_provider |
Limpo (is_vpn false, sem relay) | Permita, a menos que outros sinais sejam acionados | Nenhuma evidência de anonimizador, embora um servidor listado possa sair da lista, como aconteceu com o 91.90.122.25 da PIA |
O erro mais comum é transformar a primeira linha em uma regra de bloqueio, o que transforma os clientes de um provedor em falsos positivos de detecção de VPN. Duas verificações para rodar nos seus próprios logs esta semana:
- Encontre regras baseadas no nome. Procure
vpn_providernas suas regras. Uma regra como "bloquear se um provedor for identificado" deixa passar o 92 sem nome e bloqueia o 36 identificado. Baseie as regras na ação e nas evidências e compare os nomes pelo prefixo. - Compare seus logs com uma lista. Passe os IPs de cadastro ou login dos últimos 30 dias pelo script de correspondência da Mullvad e conte as correspondências. Compare isso com quantas dessas requisições as suas regras recusaram e depois confira algumas por amostragem na ferramenta de consulta de IP.
Perguntas frequentes
É possível saber a qual VPN um endereço IP pertence?
Sim, quando o IP está em uma lista de servidores que o provedor de VPN publica para os próprios apps. Se ele não está em nenhuma lista, em geral ainda dá para saber que é uma VPN, mas não de quem.
Existe uma lista de endereços IP da NordVPN?
Os apps da NordVPN leem uma em api.nordvpn.com, que traz o IP de cada servidor em um campo station. Em 13 de outubro de 2026 ela não respondeu a requisições da nossa rede, então usamos uma cópia salva.
O WHOIS ou o DNS reverso mostram o provedor de VPN?
Raramente. A maioria dos servidores de VPN fica em redes de hospedagem alugadas, como a M247, então o WHOIS e o DNS reverso mostram o nome do host. Até a faixa própria da Mullvad em Frankfurt está registrada em nome da 31173 Services.
O que significa vpn_provider none?
O IP não está em nenhuma das listas de servidores que temos. Isso não significa que o IP não seja uma VPN: verifique is_vpn e scoring.detection_methods.
Uma VPN identificada recebe uma pontuação de fraude mais alta?
Não. Um servidor listado da PrivadoVPN teve pontuação 36, review, enquanto uma VPN sem nome teve 92, block. O nome diz quem opera o servidor; a pontuação vem das evidências.
Quais provedores de VPN publicam suas listas de servidores?
Mullvad, AirVPN, IVPN, PrivadoVPN e Riseup responderam a requisições públicas nossas em 13 de outubro de 2026. NordVPN, Surfshark, PIA e Windscribe publicam listas para seus apps, mas não responderam a partir da nossa rede.
A equipe por trás da API do GeoIPHub
Escrito pela equipe do GeoIPHub, as pessoas que constroem a API de inteligência de IP do GeoIPHub e seu scanner. Os rascunhos são preparados com auxílio de IA e editados pela equipe; os exemplos de API são consultas reais à API em produção, salvo quando indicados como ilustrativos.


