VPN プロバイダー自身のサーバーリストから IP の背後にいるプロバイダーを特定する
IP を VPN プロバイダーが公開するサーバーリストと照合すれば、その背後のプロバイダーを特定できます。私たちが調べたどの IP でも、WHOIS に VPN の記載はありませんでした。

私たちは 2026 年 10 月 13 日 05:22 UTC に Mullvad のリレーリストを取得しました。リレーは 566 台で、そのうち WireGuard サーバーが 553 台、ブリッジが 13 台でした。Mullvad が自社所有のハードウェアとしているのは 124 台だけです。その所有サーバーの 1 台、フランクフルトの 185.213.155.73 は、WHOIS 上の登録者が「31173 Services Germany」で、逆引き DNS はなく、AS39351 から経路広告されています。ネットワーク記録のどこにも「Mullvad」とは書かれていません。それを示しているのはリストだけです。
これが「この IP はどの VPN か」を調べるあらゆるツールの仕組みのすべてですが、それを明言しているツールはほとんどありません。以下では、プロバイダーがサーバーを公開しているエンドポイントを一覧にし、動作確認済みの Python 照合スクリプトを示し、私たちが調べたプロバイダー掲載サーバーと対照群について私たちの API が返した結果を、ヒットしなかった例も含めて紹介します。最後にポリシー表を載せています。検出の側面、つまりそもそも VPN をどうやって見つけるかについては、シグナルごとに見る VPN 検出の仕組みをお読みください。

IP アドレスがどの VPN のものか分かりますか?
はい。その IP がプロバイダーの公開リストに載っていれば分かります。VPN アプリは接続する前にサーバーの場所を知っている必要があるため、プロバイダーはそのリストをアプリに配信しており、その多くは公開されています。どのリストにも載っていないアドレスでも、プローブとホスティングのシグナルから VPN であることは通常判別できますが、どこの VPN かは分かりません。
185.213.155.73 を最初から最後まで追ってみます。api.mullvad.net/www/relays/all/ にある Mullvad のリストには、このアドレスの行があり、hostname は「de-fra-wg-001」、type は「wireguard」、city_name は「Frankfurt」、owned は true、provider は「31173」です。最後のフィールドはホスティング会社で、この場合は Mullvad 自身です。
レジストリの情報は違うことを示しています。05:28 UTC に開いた RIPE の RDAP レコードでは、レンジ名は NET-31173-185-213-155-0-24、登録者は「31173 Services Germany」です。RIPE の whois の route オブジェクトでは、オリジンは AS39351 です。dig -x 185.213.155.73 を実行したところ、応答はまったくありませんでした。
次に 05:27 UTC に私たちの API で照会しました。以下は値を編集せずに一部を抜粋したものです。
{
"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"]
}
}
whois.has_vpn_keywords に注目してください。Mullvad のサーバーなのに false で、私たちが調べたすべてのアドレスで false でした。WHOIS のテキストに VPN が出てくることは一度もありません。「Mullvad」という名前はリスト照合から得られたもので、vpn_confidence の 95 は私たちの API がその経路に付ける値です。block の判定は証拠から来ています。ホスティングのアドレス上にある、WireGuard とタグ付けされたプロバイダーリストのエントリーです。
WHOIS、逆引き DNS、ASN が VPN ではなくホストを示す理由
VPN サーバーの多くは賃貸マシン上で動いているため、ネットワーク記録が示すのは家主です。私たちのサンプルでは、M247(AS9009)が NordVPN、PIA、AirVPN、IVPN、FastestVPN の掲載サーバーをホストしていました。Datacamp(AS212238)は Mullvad のニューヨークのサーバーと IVPN のブエノスアイレスのサーバーをホストしています。「M247 なら VPN」というルールは、ホスティング会社についての推測にすぎません。プロバイダーのリストは、サーバーについての証拠です。
Mullvad がそれを裏付けてくれます。Mullvad のリストはすべてのリレーに owned の true または false を付け、provider でホストを示しています。10 月 13 日時点で、566 台のリレーのうち 124 台が owned: true で、最も多いホストは DataPacket(128 台)、Tzulo(127 台)、M247(98 台)でした。05:33 UTC に、賃貸の Mullvad リレー 2 台を照会しました。
| Mullvad のリレー(リストによる) | リスト上のホスト | 私たちの asn.org | vpn_provider、vpn_confidence | スコア、アクション |
|---|---|---|---|---|
| 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 |
どちらも ASN をチェックすれば「ホスティング会社」と出ます。リストは Mullvad だと示しています。ニューヨークのリレー us-nyc-wg-301(143.244.47.65)も、Datacamp 上で同じ状況です。
逆引き DNS はさらに頼りになりません。05:28 UTC に、プロバイダー掲載アドレスのうち 20 件に dig -x を実行しました。11 件は何も返さず、残り 9 件のどれも VPN ブランドを示していませんでした。
| IP | 掲載元 | dig -x の結果 |
|---|---|---|
| 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 | PTR なし |
Riseup の名前が示唆しているのはブランドではなく、VPN ソフトウェアの LEAP と Bitmask です。IVPN のウィーンの名前には「adsl」とあり、家庭用回線のように読めますが、IVPN が掲載しているサーバーです。PTR を深読みすることの危険がここにあります。
ASN が VPN を示すのは、プロバイダーが自前のネットワークを運営している場合だけです。Mullvad の AS39351 や Riseup の AS16652 がそうです。背景を知りたい方は、ASN とは何か、何を示すのかをご覧ください。私たちの API は VPN プロバイダーが運営するネットワークの短い一覧を持っており、Mullvad の AS39351 も含まれています。この一覧が、以下で説明する 4 つの命名経路の 1 つです。
VPN プロバイダーがサーバー IP を公開している場所
以下は、プロバイダー自身のアプリが読み込むリストです。「本日取得」は、2026 年 10 月 13 日に私たちのネットワークが 200 レスポンスを受け取ったことを意味します。「本日は到達不可」は、2 回試しても私たちのネットワークからのリクエストが失敗したことを意味します。
| プロバイダー | アプリが読み込むリスト | IP の場所 | 2026 年 10 月 13 日の状況 |
|---|---|---|---|
| Mullvad | api.mullvad.net/www/relays/all/ | ipv4_addr_in、ipv6_addr_in | 本日取得、05:22 UTC:リレー 566 台、所有 124 台 |
| AirVPN | airvpn.org/api/status/ | ip_v4_in1 〜 ip_v4_in4 | 本日取得、05:22 UTC:サーバー 250 台 |
| IVPN | api.ivpn.net/v5/servers.json | WireGuard と OpenVPN の host エントリー | 本日取得、05:22 UTC:59 拠点に WireGuard ホスト 89 台 |
| PrivadoVPN | privadovpn.com/apps/servers_export.json | ip | 本日取得、05:22 UTC:サーバー 167 台 |
| Riseup | api.black.riseup.net/3/config/eip-service.json(riseup.net/provider.json から発見) | ip_address | 本日取得、05:23 UTC:ゲートウェイ 21 台 |
| NordVPN | api.nordvpn.com/v2/servers(gluetun の NordVPN updater による) | station | 本日は到達不可(タイムアウト) |
| Surfshark | api.surfshark.com/v4/server/clusters(gluetun の Surfshark updater による) | ホスト名のみ | 本日は到達不可(TLS エラーの後、タイムアウト) |
| Private Internet Access | serverlist.piaservers.net/vpninfo/servers/v6(PIA 自身の get_region.sh による) | リージョンごとのサーバー IP | 本日は到達不可(TLS エラー) |
| Windscribe | assets.windscribe.com/serverlist/mob-v2/1/(gluetun の Windscribe updater による) | ip、ip2、ip3 | 本日は到達不可(タイムアウト) |
到達できなかった 4 つも実在するエンドポイントです。プロバイダーの公式クライアントやオープンソースのクライアントから把握しているもので、gluetun の NordVPN のコードには、station フィールドは「どうやら入口 IP アドレスのようだ(is, it seems, the entry IP address)」というコメントまであります。これらの API はデータセンターからのリクエストをブロックしており、私たちのスキャナーはデータセンターで動いています。10 月 13 日には、この記事のために使ったネットワークにも応答しませんでした。
そのため私たちの API は、プロバイダー自身のサーバーリストに加え、公開されているサードパーティのリストを使って VPN に名前を付けています。NordVPN、PIA、Windscribe については、スキャナーは 2026 年 10 月 4 日付で保存した API レスポンスのコピーを代わりに使います。Surfshark のコピーは持っていません。サードパーティのリストは gluetun-servers で、オープンソースの VPN クライアントコンテナー gluetun の背後にある、コミュニティが管理するサーバーデータです。私たちは 20 以上のプロバイダーについてそのファイルを読み込んでおり、FastestVPN については唯一の情報源です。本日取得した ExpressVPN、FastestVPN、NordVPN、PIA の 4 ファイルは、いずれもタイムスタンプが 2026 年 8 月 6 日でした。
IP から VPN プロバイダーを自分で特定する:Mullvad と NordVPN
プロバイダーのリストをダウンロードし、アドレスが完全一致するものを探します。Mullvad は、問い合わせるたびにリストが応答したので簡単なケースです。以下は 2026 年 10 月 13 日 05:29 UTC に、Python 3.9.6 で標準ライブラリのみを使って実行したスクリプトです。
"""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}")
コマンドラインで 7 つの入力を渡したところ、次のように出力されました。
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
ログの列を流し込むときのように、空行やパディングを含む 3 行を stdin からパイプで渡したところ、45.83.220.70 が se-mma-wg-103 に一致しました。404 を返す URL を指定すると、「could not load Mullvad's list: HTTP Error 404: Not Found」と出力してステータス 1 で終了しました。注意点が 2 つあります。無効な入力はエラーではなく「リストに載っていない」と報告されること、そして 13 台のブリッジも一致対象になるため type 列を確認する必要があることです。
同じ方法で NordVPN を検出するには。 NordVPN のリストは各サーバーの IP を station フィールドに入れており、10 月 4 日に保存したコピーにはサーバーごとに 1 つずつあります。ライブのエンドポイントは 10 月 13 日に私たちのネットワークから 2 回ともタイムアウトしたため、実行できなかった NordVPN 用のコードは公開しません。NordVPN が応答するネットワークから、同じ完全一致のロジックを実行してください。
1 件ずつ調べるなら、任意の IP の VPN とそのプロバイダーをチェックできます。このツールは detection.vpn_provider に名前を返します。コードでは、パスに IP を入れたリクエスト 1 回で済みます。
curl https://api.geoiphub.com/v1/lookup/185.213.155.73 \
-H "x-api-key: YOUR_API_KEY"
vpn_provider は無料プランで利用でき、無料プランには 1 日 1,500 回のルックアップですべてのデータフィールドが含まれます。名前をキーにして何かを判定する場合は、文字列全体ではなく先頭で照合してください。私たちの API は、掲載サーバーには「Mullvad」を、ASN 経路には「Mullvad (31173 Services)」を返しました。以下は 05:34 UTC にキーなしで実行したスニペットです。
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
設計の前提にすべきなのは 3 行目です。名前はなくても VPN であり、block になります。
逆の疑問、つまり自分の接続が NordVPN として表示されるかを知りたい場合は、接続した状態で接続に表示される IP を確認を開いてください。
プロバイダー掲載 IP に対して私たちの API が返した結果
サンプルを取ったすべてのプロバイダーで、掲載サーバーには名前が付いて返ってきました。どの 4 つの経路で名前が付いたかは vpn_confidence で分かります。名前が付いた行では、値と経路が次のように対応します。
| vpn_confidence | IP に名前を付けた経路 |
|---|---|
| 95 | プロバイダー自身のサーバーリスト |
| 90 | gluetun のファイルにあるサーバーのホスト名を、私たちがこの IP に解決したもの |
| 85 | VPN プロバイダーが運営するネットワークの短い一覧 |
| 80 | 公開されている gluetun のサーバーリスト |
これらのルックアップは 2026 年 10 月 13 日 05:27 から 05:28 UTC の間に実行しました。最後の列には応答のあった VPN ハンドシェイクのプローブだけを示し、detection_methods の残りは表から省いています。
| IP | プロバイダーとサーバー(リストによる) | IP を見つけた場所 | vpn_provider | vpn_confidence | スコア、アクション | 応答したプローブ |
|---|---|---|---|---|---|---|
| 185.213.155.73 | Mullvad、de-fra-wg-001 | Mullvad、本日取得 | Mullvad | 95 | 100、block | wireguard_open |
| 143.244.47.65 | Mullvad、us-nyc-wg-301、owned false | Mullvad、本日取得 | Mullvad | 95 | 99、block | wireguard_open |
| 82.102.19.137 | NordVPN、be148 | 10 月 4 日の NordVPN コピー、gluetun にも掲載 | NordVPN | 80 | 99、block | wireguard_open |
| 173.239.247.129 | PIA、ベトナム | 10 月 4 日の PIA コピー、gluetun にも掲載 | PIA | 80 | 51、step_up | なし |
| 198.44.137.44 | Windscribe、ダラス、us-central-117 | 10 月 4 日の Windscribe コピー | Windscribe | 95 | 100、block | ipsec_open、wireguard_open |
| 185.156.175.170 | AirVPN、Achernar、チューリッヒ | AirVPN、本日取得 | AirVPN | 95 | 99、block | wireguard_open |
| 149.22.83.100 | IVPN、ar1.wg、ブエノスアイレス | IVPN、本日取得 | IVPN | 95 | 99、block | wireguard_open |
| 85.12.5.56 | PrivadoVPN、hkg-006 | PrivadoVPN、本日取得 | PrivadoVPN | 90 | 36、review | なし |
| 204.13.164.252 | Riseup、vpn01-sea | Riseup、本日取得 | Riseup | 95 | 48、review | なし |
| 31.171.152.205 | ExpressVPN、アルバニア | 8 月 6 日の gluetun ファイル | ExpressVPN | 80 | 51、step_up | なし |
| 46.102.153.134 | FastestVPN、au-stream、シドニー | 8 月 6 日の gluetun ファイル | FastestVPN | 90 | 99、block | wireguard_open |
| 45.83.220.7 | Mullvad のリストには掲載なし | なし | Mullvad (31173 Services) | 85 | 46、review | なし |
3 つの行には説明が必要です。NordVPN と PIA のサーバーは私たちの保存コピーに載っていますが、gluetun の値である 80 で返ってきました。どちらも gluetun のファイルに載っています。PrivadoVPN のサーバーは本日の PrivadoVPN 自身のエクスポートに載っていますが、95 ではなく 90 で返ってきました。その名前は、ホスト名 hkg-006.vpn.privado.io を解決して得られたもので、このホスト名は gluetun の PrivadoVPN ファイルにも載っています。経路は、IP を見つけたリストからではなく vpn_confidence から読み取ってください。ExpressVPN は、私たちが自社リストを取得している 9 つのプロバイダーには含まれていません。gluetun に掲載された ExpressVPN のアドレス 1 件に名前が付いて返ってきたのは、経路が機能することを示しているのであって、ExpressVPN をカバーしていることを示すものではありません。
最後の行は ASN 経路です。45.83.220.7 は Mullvad のリストに載っていません。本日のリストでは、その /24 にあるのは .68、.69、.70 で、.7 はありません。名前が付いたのは、そのネットワーク AS39351 が 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"]
}
}
ここでも known_vpn_server が発火している点に注意してください。このメソッド名は「プロバイダーのリストに掲載」という意味ではありません。この行では、ネットワークの一覧から来ています。経路は vpn_confidence から読み取り、それも vpn_provider が「none」でない行に限ってください。
一部の VPN IP が「none」で返ってくる理由
「none」は、その IP が現時点で私たちの保持するどのリストにも載っていないという意味です。その IP が VPN ではないという意味でも、プロバイダーの隣接アドレスがクリーンだという意味でもありません。
NordVPN のサーバー pl128(194.99.105.99)は、10 月 4 日に保存した NordVPN のレスポンスにオンラインとして載っています。本日は vpn_provider が「none」でしたが、is_vpn は true、スコアは 98 で block、メソッドには ipsec_open が含まれていました。IPsec ハンドシェイクで検出されましたが、名前は付きませんでした。PIA のリヒテンシュタインのサーバー 91.90.122.25 は、同日の PIA のリストに載っています。本日は is_vpn が false で、ブロックリストとホスティングのシグナルだけからスコア 64(step_up)でした。
この 2 つのアドレスはどちらも gluetun のファイルに載っていません。一方、上の表で名前が付いた NordVPN と PIA の行は、どちらも載っています。本日は NordVPN と PIA の API を再取得できなかったため、どちらのサーバーも 10 月 4 日以降に廃止されたか、アドレスが変わった可能性があります。私たちが言えるのはもっと狭く、確かなことです。サーバーに名前が付くのは、私たちが現在保持しているリストに載っている場合だけです。
本日リストを取得できたプロバイダーでも、ヒットしなかった例があります。91.90.123.29 は掲載済みの Mullvad リレー 91.90.123.2 と同じ /24 にありますが、Mullvad のリストには載っていません。10 月 13 日に、IPinfo のプロバイダーページはこれを Mullvad の例示 IP として表示していました。私たちの API は is_vpn false、vpn_provider「none」、スコア 12、allow を返しました。出口アドレスか、掲載アドレスの隣にある未掲載アドレスかもしれませんが、それは示唆であって証拠ではありません。いずれにせよ、リスト照合がカバーするのは掲載アドレスだけで、その隣は対象外です。
文書化された対照例は、名前はないが検出されるケースを示しています。AS834 IPXO 上の 102.129.235.17 は、is_vpn true、vpn_provider「none」、スコア 92、block を返し、known_vpn_server、openvpn_open、ipsec_open が付いていました。名前のないサーバーでも、私たちのスキャナーと OpenVPN または IPsec のハンドシェイクを完了すれば検出されます。プローブについては、上でリンクしたハブ記事で説明しています。
VPN の IP に名前が付かない主な理由は次のとおりです。
- 公開リストがない。 何も公開していないプロバイダーもあり、自前でホストした VPN がリストに載ることはありません。
- リストに到達できない。 私たちが取得している 9 つのリストのうち 4 つはデータセンターをブロックしているため、保存コピーがあればそれを使い、加えて gluetun を使っています。
- ローテーション。 私たちが最後にコピーした後に、サーバーがリストから外れたりアドレスが変わったりすることがあります。
- VPN ではなくプロキシである。 プロキシには照合できるプロバイダーリストがありません。データセンター、レジデンシャル、モバイルのプロキシをご覧ください。
iCloud Private Relay と Cloudflare WARP は、この意味での VPN プロバイダーではありません。これらには専用のフィールド relay_provider と専用のポリシーがあり、iCloud Private Relay と Cloudflare WARP で解説しています。
名前の付いた VPN がよりリスクの高い VPN というわけではない
名前はサーバーの運営者を示すだけで、スコアは開いているハンドシェイクのポート、ホスティング、不正利用の履歴といった証拠から算出されます。私たちのサンプルで最も低いスコアの一部は名前の付いたサーバーに付き、最も高いスコアの 1 つは名前のないサーバーに付きました。
| IP | vpn_provider | スコア、アクション |
|---|---|---|
| 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 |
私たちの区分は、25 までが allow、50 までが review、75 までが step_up、75 超が block です。PrivadoVPN のサーバーは私たちのデータでハンドシェイクのプローブに 1 つも応答しなかったため、発火したのは known_vpn_server だけで、review にとどまりました。名前のないサーバーは 2 つに応答しました。これが正しい順序です。ルールは、サーバーにどのロゴが付いているかではなく、私たちが観測したものを重視すべきです。シグナルの重みはスコアの算出方法のページに掲載しています。
入口 IP、ローテーションされたサーバー、古くなった名前
プロバイダーのリストが教えてくれるのは、アプリが接続するアドレスです。サンプルの大半のサーバーでは、同じアドレスが私たちのプローブに応答しましたが、私たちが検証したのは掲載アドレスに名前が付くことだけで、プロバイダーが使うすべての出口アドレスがリストに載っていることではありません。
フィールド名には「in」と付いています。Mullvad は ipv4_addr_in を使い、AirVPN はサーバーごとに 4 つのアドレスを ip_v4_in1 〜 ip_v4_in4 として公開しています。Surfshark のリストにはホスト名しかないため、照合する前に誰かが名前を IP に解決する必要があります。私たちの 90 の経路は、gluetun のファイルにあるサーバーのホスト名に対してそれを行います。FastestVPN の au-stream.jumptoserver.com(46.102.153.134)は、こうして名前が付きました。
リストには、読み取るべき状態情報も含まれています。本日の Mullvad のリストでは 24 台のリレーが active: false になっており、その中には se-mma-wg-101(45.83.220.68)も含まれますが、私たちの API は今も 95 で「Mullvad」と名付けています。掲載サーバーはプロバイダーのフリートについての事実であって、そのサーバーが今日トラフィックを運んだ証拠ではありません。ベンダーごとに VPN の IP 数が大きく食い違うのもこのためです。サーバー、掲載された入口アドレス、観測された出口アドレス、レンジ全体など、それぞれ異なるものを異なる日付で数えています。私たちが引用する数は Mullvad 自身のリストだけです。プロバイダーリストの更新スケジュールはここでは公開しません。照合スクリプトを自分で実行する場合は、バッチごとにリストを取得してください。
プロバイダー名をどう使うか
名前はポリシーと調査に使い、ブロックのスイッチとしては使わないでください。判定は recommended_action とその背後にある証拠をキーにし、例外とレポートは名前をキーにします。
| 見えているもの | アクション | 理由 |
|---|---|---|
名前の付いた VPN(vpn_provider が設定されている) | recommended_action に従う。名前は、自分で選ぶ許可リスト、ライセンスのログ、運営者ごとの不正利用のグルーピングに使う | 名前は帰属であってリスクではない。PrivadoVPN は 36(review)、Mullvad のフランクフルトのサーバーは 100(block)だった |
名前のない VPN(is_vpn true、vpn_provider「none」) | 同じスコアの名前付き VPN とまったく同じように扱う | 102.129.235.17 は名前なしで 92 だった |
リレー(is_relay true) | 許可し、セッションをスコアリングする | リレーは VPN プロバイダーではなく、relay_provider を使う |
クリーン(is_vpn false、リレーなし) | 他のシグナルが発火しない限り許可する | 匿名化の証拠はない。ただし PIA の 91.90.122.25 のように、掲載サーバーが外れることもある |
よくある間違いは、1 行目をブロックルールにしてしまうことです。そうするとプロバイダーの顧客が VPN 検出の誤検知になります。今週、自社のログで実行すべきチェックが 2 つあります。
- 名前をキーにしたルールを探す。 ルールの中から
vpn_providerを検索してください。「プロバイダー名が付いていれば block」のようなルールは、名前のない 92 を通し、名前の付いた 36 をブロックします。代わりにアクションと証拠をキーにし、名前はプレフィックスで照合してください。 - ログを 1 つのリストと照合する。 過去 30 日間のサインアップまたはログインの IP を Mullvad の照合スクリプトに流し込み、一致した数を数えてください。それを、それらのリクエストのうち自社のルールが拒否した数と比べ、いくつかを IP ルックアップツールで抜き取り確認してください。
よくある質問
IP アドレスがどの VPN のものか分かりますか?
はい。その IP が、VPN プロバイダーが自社アプリ向けに公開しているサーバーリストに載っていれば分かります。どのリストにも載っていない場合でも、VPN であることは通常判別できますが、どこの VPN かまでは分かりません。
NordVPN の IP アドレス一覧はありますか?
NordVPN のアプリは api.nordvpn.com から一覧を読み込みます。各サーバーの IP は station フィールドに入っています。2026 年 10 月 13 日には私たちのネットワークからのリクエストに応答しなかったため、保存済みのコピーを使いました。
WHOIS や逆引き DNS で VPN プロバイダーが分かりますか?
ほとんど分かりません。VPN サーバーの多くは M247 のような賃貸ホスティングネットワーク上にあるため、WHOIS と逆引き DNS はホスト事業者を示します。Mullvad 自身のフランクフルトのレンジでさえ、登録者は 31173 Services です。
vpn_provider が none とはどういう意味ですか?
その IP が、私たちが保持しているどのサーバーリストにも載っていないという意味です。VPN ではないという意味ではありません。is_vpn と scoring.detection_methods を確認してください。
名前の付いた VPN は不正スコアが高くなりますか?
いいえ。リストに載っている PrivadoVPN のサーバーは 36(review)でしたが、名前のない VPN は 92(block)でした。名前はサーバーの運営者を示すだけで、スコアは証拠から算出されます。
サーバーリストを公開している VPN プロバイダーはどこですか?
Mullvad、AirVPN、IVPN、PrivadoVPN、Riseup は 2026 年 10 月 13 日に私たちの公開リクエストに応答しました。NordVPN、Surfshark、PIA、Windscribe もアプリ向けにリストを公開していますが、私たちのネットワークからは応答がありませんでした。
GeoIPHub API を支えるチーム
GeoIPHub IP インテリジェンス API とそのスキャナーを開発している GeoIPHub チームが執筆しています。下書きは AI の支援を受けて作成し、チームが編集しています。API の例は、「説明用」と明記したものを除き、本番 API に対する実際のルックアップです。


