IPアドレスがプロキシかどうかを調べる方法（ステップ別ガイド）

2026年10月21日プロキシ検知ネットワークセキュリティIPインテリジェンスシステム管理

rDNS、ASN検索、ポート確認、IPインテリジェンスAPIなどを使って、IPアドレスがプロキシかどうかを確認する実践的な方法を解説します。

プロキシ検知で押さえておきたい前提

不正利用の調査、認証エンドポイントの保護、不自然なネットワークトラフィックの切り分けでは、「その接続元がプロキシ経由かどうか」を見極める作業がよく発生します。ひと口にプロキシといっても、オープンな HTTP/SOCKS フォワーダー、商用 VPN サーバー、データセンター上のスクレイピング中継サーバー、Tor 出口ノード、住宅回線プロキシネットワークなど、形態はさまざまです。

それぞれの仕組みは、IP ルーティング層やトランスポートプロトコルとの関わり方が異なります。そのため、単一のコマンドだけで「はい／いいえ」を確定するのは現実的ではありません。複数の独立したネットワークシグナルを突き合わせて判断する必要があります。本稿では、IP を手作業で調査する具体的な手順と、大規模に検知する場合の考え方を順を追って紹介します。

Step 1: 逆引き DNS（rDNS）と PTR レコードを確認する

逆引き DNS は、IP アドレスから設定済みのドメイン名を引く仕組みです。ホスティング事業者、ブロードバンド ISP、モバイルキャリアの多くは PTR レコードに一定の命名規則を使っており、そこからその IP がどのような用途で使われていそうかを推測できます。

PTR レコードは dig で確認できます。

bash dig -x 198.51.100.42 +short

このシグナルから分かること

住宅回線またはブロードバンド ISP: ホスト名に pool、cable、fiber、dhcp といった文字列が含まれていたり、198-51-100-42.dyn.exampleisp.net のように動的 IP らしいオクテット形式になっていたりする場合、一般的な消費者向け回線であることが多いです。
データセンターまたは VPS: vps、server、compute、hosted-by、linode、ovh といったパターンや、ec2-198-51-100-42.compute-1.amazonaws.com のようなクラウド事業者の生のホスト名が見える場合は、データセンター基盤を示唆します。一般ユーザーが正当なブラウザアクセスを VPS から直接行うケースはまれで、自己ホスト型 VPN やプロキシを経由している可能性があります。
PTR がない、または汎用的すぎる: 安価な VPS 上で動くプロキシ運用者の中には、正引きと逆引きの整合性が取れた DNS、いわゆる FCrDNS を設定していないケースも少なくありません。

限界

住宅回線プロキシネットワークを使う攻撃者は、侵害された、あるいは貸し出された一般家庭向け機器を経由して通信します。この場合、PTR レコード上は普通の住宅向け ISP に見えるため、rDNS の確認だけではすり抜けられてしまいます。

Step 2: Autonomous System Number（ASN）とルーティング情報を調べる

すべての IP アドレスはいずれかの Autonomous System（AS）に属しています。AS の登録情報を見ると、その IP ブロックを所有し、BGP で広報している主体が分かります。一般的な住宅ユーザーの IP は通信事業者のコンシューマー向け ASN 配下にありますが、商用プロキシや VPN サーバーは、ほぼ例外なくホスティング、クラウド、コロケーション事業者の ASN に置かれています。

ASN の詳細は、Team Cymru の DNS または WHOIS サービスで確認できます。

bash whois -h whois.cymru.com " -v 198.51.100.42"

あるいは、地域インターネットレジストリ（ARIN、RIPE、APNIC）に直接問い合わせる方法もあります。

bash whois 198.51.100.42 | grep -iE "origin|org-name|descr|nettype"

ASN シグナルの見方

対象 IP が DigitalOcean、Hetzner、OVH、AWS、M247 などに属している一方で、ユーザーが通常のインタラクティブな Web 訪問者として振る舞っているなら、VPN、商用フォワーダー、自動化スクリプトなど、何らかの中継を経由していると考えるのが自然です。
NetType や割り当て情報も確認します。プロキシ集約業者に関連する再割り当てブロックやポータブルアドレスでは、基盤となる通信事業者とは別の会社名が登録情報に現れることがあります。

限界

ASN レベルの確認では、基盤となるキャリアが AT&T、Comcast、あるいは各国のモバイル事業者のままになっている住宅回線プロキシは検知できません。

Step 3: 既知の Tor 出口ノードと脅威リストを確認する

Tor ネットワークは、現在稼働している出口ノード IP アドレスの信頼できる動的リストを公開しています。Tor の出口リレーは公開情報であるため、このリストと照合すれば高い確度で判定できます。

稼働中の出口ノード一覧は、次のように直接取得できます。

bash curl -s https://check.torproject.org/torbulkexitlist | grep -x "198.51.100.42"

Tor Project の DNSBL を使って DNS ベースで確認することもできます。

bash # Reverse the target IP octets and query the dnsel zone dig 42.100.51.198.ip-port.exitlist.torproject.org A +short

この問い合わせが 127.0.0.2 を返す場合、その IP はアクティブな Tor 出口ノードです。

限界

Tor は匿名化ツールの一カテゴリにすぎません。一般的なオープンプロキシの公開ブロックリストは変動が非常に激しく、数分でオフラインになるようなオープンプロキシを収集していることも多いため、IP レンジが再割り当てされた際に誤検知が起きやすくなります。

Step 4: パッシブ／アクティブなポート分析を行う

プロキシは、標準的なポートや補助的なプロキシ用ポートで待ち受けるソフトウェアとして動いていることがあります。とはいえ、すべてのクライアント接続に対して侵襲的なポートスキャンを行うのは、負荷が高く、時間もかかり、法的にも問題になり得ます。一方で、インシデント調査における手動トリアージであれば、代表的なポートを確認する価値がある場面もあります。

bash nc -zv -w 2 198.51.100.42 8080 3128 1080 8888 80

Port 1080: SOCKS プロキシの標準的なポートです。
Port 3128: Squid HTTP プロキシのデフォルトポートです。
Ports 8080, 8888: HTTP フォワーダーでよく使われる代替ポートです。

これらのポートに接続した際に、Proxy-Agent、Via: 1.1 squid のような HTTP ヘッダーが返ってきたり、予期しない SOCKS ハンドシェイクに対して接続が閉じられたりする場合、そのホストはプロキシサーバーである可能性が高いといえます。

限界

本番運用されている商用 VPN、リバースプロキシ、住宅回線プロキシのデーモンは、クライアント側インターフェースで公開待ち受けをしないのが一般的です。これらはオーケストレーションノードに対してアウトバウンドのリバーストンネルを張るため、外部から見えるリスニングポートは存在しません。

手動チェックと現実のギャップ

Step 5: 実行時に自動化された IP インテリジェンスを使う

手動調査は、インシデント発生後のトリアージには有効です。しかし、認証、決済、サインアップのようなインタラクティブなアプリケーションでは、サブ秒単位で判定する必要があります。このレイヤーで特に難しいのが住宅回線プロキシの検知です。つまり、本物の消費者向け ISP に属する IP が、実は backconnect 型のプロキシトンネルとして使われているケースを見抜かなければなりません。

これを解くには、BGP アナウンス、アクティブプローブのテレメトリ、ハニーポット、接続時の行動パターンを集約し、ひとつのルックアップにまとめる必要があります。Guarda のような IP インテリジェンスサービスは、こうしたシグナルを統合し、JSON レスポンスとして返します。

bash curl -s "https://api.guarda.net/v1/ip/198.51.100.42" \ -H "Authorization: Bearer YOUR_API_KEY"

典型的なレスポンスでは、個別の真偽値による分類と、総合的なリスクスコアが返されます。

{ "ip": "198.51.100.42", "is_proxy": true, "is_vpn": false, "is_tor": false, "is_datacenter": true, "asn": { "number": 16276, "org": "OVH SAS" }, "risk_score": 88 }

このように構造化されたフィールドを使えば、ファイアウォールやアプリケーションコード側で、より細かなポリシーを適用できます。たとえば、登録時はデータセンター IP を拒否しつつ企業 VPN は許可する、あるいは is_proxy が true の場合や全体の risk_score が定義済みのしきい値を超えた場合だけ追加認証を求める、といった制御が可能です。

スクリプトを用意せずにすぐ IP を確認したい場合は、guarda.net のホームページから無料の IP チェックを実行できます。同サービスでは、これまでに 594,400 件以上のルックアップが処理されています。