99%で見破られる — 最高峰の住宅プロキシすら暴く「50ミリ秒」の綻び

私たちは hellworld.io のフルラインナップ（住宅プロキシ14ブランド、モバイルプール3種、Static ISP、そして無制限プラン2階層）を取り扱うリセラーです。ですから住宅プロキシの検出について書くからには、立場をはっきりさせておくのがフェアでしょう。住宅出口に頼っている当社のお客様は、誰もがこの論文に切実な利害関係を持っています。それを取り繕うつもりはありません。本記事の狙いは、住宅プロキシから皆さんを遠ざけて怖がらせることではありません。静かに、しかし高い精度で機能するサーバー側の特定の検出手法を解説し、それが2026年におけるこれらのツールの使われ方にとって何を意味し、何を意味しないのかを明らかにすることです。

スクレイパー、スニーカーボット、広告検証、価格インテリジェンスを運用する多くのチームにとって、住宅プロキシは最も安全な選択肢に感じられます。送信元 IP は、ごく普通の ISP に契約している、ごく普通の家庭用ブロードバンド回線の利用者のように見えます。データセンターでもなければ、既知のプロキシ事業者でもない。だからこそ大半の IP レピュテーションリストをすり抜けられるのです。

——それが通用しなくなるまでは。2022年の学術論文 BADPASS: Bots Taking ADvantage of Proxy as a Service（ISPEC 2022、EURECOM・KAUST・Amadeus の研究者らによる）は、たった一つの仕掛けで住宅プロキシ接続を 99.01%の精度 で特定できることを示しました。その仕掛けとは、同一の HTTPS 接続における TCP RTT と TLS RTT を、ハンドシェイクの最中にサーバー側で比較する、というものです。

JavaScript は不要。IP レピュテーションのデータベースも不要。フィンガープリント用ライブラリも不要。サーバーがすでに手にしている2つのタイミングの数値だけで成立します。

スクレイピングの標的になっている高価値サイトを運営しているなら、これは公表されている中でも最もクリーンな検出手法の一つです。スクレイパーを運用しているなら、今あなたが信頼している事業者のほぼ全てがこの問題を抱えている可能性が高いので、理解しておく価値があります。

なぜ住宅プロキシはこれほどブロックしづらくなったのか

データセンタープロキシのフィルタリングは簡単です。AWS、GCP、Azure、DigitalOcean——ASN、IP ブロック、ホスト名のパターン、TLS スタックのシグネチャ、過去の不正利用データ、いずれもよく知られています。商用のボット検出サービスの大半は、これらのレンジからのトラフィックを自動的にフラグ付けします。

住宅プロキシはまったくの別物です。出口 IP は、実在する家庭用ブロードバンド回線であったり、モバイル端末であったり、プロキシ事業者のプールに組み込まれた消費者向けハードウェアであったりします（無料アプリに同梱された SDK 経由で取り込まれているケースもあります）。宛先サーバーから見れば、オハイオや東京、サンパウロにいる普通の有料ユーザーと区別がつきません。

これこそ、EC、チケッティング、旅行、航空会社のプラットフォームがスクレイパー相手のイタチごっこで負け続けている理由です。そして偶然ではなく、この論文の著者の一人は、グローバルな旅行 IT インフラの巨人 Amadeus に勤務しています。彼らは「もしボットがプロキシを使ったら」と空理空論をこねる象牙の塔の研究者ではありません。何年ものあいだ、まさにその攻撃に痛めつけられてきた当事者なのです。

従来のアンチボット検出は、IP レピュテーション、リクエストレート、デバイスフィンガープリント、行動の痕跡に大きく依存しています。住宅プロキシは、この IP レピュテーションのシグナルをほぼ完全に曖昧にしてしまいます。そこで自然に浮かぶ問いはこうです。サーバーは IP を一切見ることなく、接続そのものだけからプロキシだと見抜けるのか？

論文の答えはこうです。イエス、2つの RTT を測ることで、と。

核心的な洞察：住宅プロキシは TCP を分断するが、TLS は分断しない

ここが論文の最もクリーンな部分です。

ユーザーが Web サイトに直接接続するとき、構図はシンプルです。ブラウザはサーバーに対してまっすぐ TCP 接続を張り、その TCP 接続の上で TLS をネゴシエートします。TCP の3ウェイハンドシェイクも TLS ハンドシェイクも、同じ2つのエンドポイント間で行われます。サーバーが測定する TCP ラウンドトリップ時間と TLS ラウンドトリップ時間は、ほぼ同一になるはずです。どちらも同じ経路を測っているからです。

住宅プロキシはそうは動きません。 大半は「バックコネクト（backconnect）」アーキテクチャで動作します。クライアントは事業者のスーパープロキシに接続し、スーパープロキシが住宅ゲートウェイをスケジューリングし、そのゲートウェイが宛先サーバーに対して TCP 接続を張ります。サーバーから見れば、TCP の相手はゲートウェイであって、元のクライアントではありません。

ところが HTTPS プロキシは通常、TLS セッションを終端して張り直すのではなく、不透明なトンネルとしてそのまま転送します。つまり TLS セッションは依然として、元のクライアントと宛先サーバーのあいだで エンドツーエンド にネゴシエートされているのです。ゲートウェイは暗号化されたバイト列を右から左へ受け流しているだけです。

これが構造的なミスマッチを生みます。

• TCP RTT は ゲートウェイ からサーバーまでの距離を測ります。
• TLS RTT は 本物のクライアント からスーパープロキシ・ゲートウェイを経てサーバーに至るまでの距離を測ります。

直接接続なら、この2つの数値は一致します。住宅プロキシ接続では、TLS RTT はほぼ常に TCP RTT より明確に大きくなります。TLS ハンドシェイクのパケットはプロキシチェーン全体を旅するのに対し、TCP ハンドシェイクはそうではないからです。

一文でまとめるなら——住宅プロキシはトランスポート層を2つに分断するが、TLS は依然としてエンドツーエンドのフリをし続ける。そしてその「嘘」には、測定可能なレイテンシのコストが伴う。

なぜこの検出手法はとりわけ厄介なのか

サーバー側のタイミング計測には、プロキシ利用者にとって非常に都合の悪い4つの性質があります。

1. 完全にサーバー側で動く。 クライアントの協力も、同意ダイアログも、JavaScript の実行も不要です。ロードバランサーやオリジンでパケットのタイミングを取得できるなら、実装できます。

2. JavaScript のブロックは効かない。 多くのボット検出は、ブラウザ側のプローブ（WebRTC、localhost への接続試行、Performance API の癖など）を仕込みます。高度なボットは JavaScript を無効化したり、ヘッドレスで動かしたり、こうしたプローブを除去したりします。この手法はそれらをすべて回避します。なぜなら、関連するシグナルは HTML が配信される前に取得されるからです。

3. IP レピュテーションを気にしない。 住宅 IP は絶えずローテーションします。新しい IP が日々現れます。特定の IP を「悪い」とラベリングするタイプの検出は、永遠に負け続けるレースを走っています。この手法は IP を完全に無視し、接続の構造だけを見ます。

4. 検出はレスポンスより前に起こる。 RTT のギャップは TLS ハンドシェイクの最中に現れます。HTML の最初の1バイトを返す前に、接続を拒否するか、わざと遅延させるか、レート制限をかけるかを決められるのです。防御側の視点から見れば、これは非常に大きい。判断を下しているあいだ、スクレイパーに何かを抜き取らせることがないからです。

実験の内部

著者らは理論だけで満足しませんでした。ギャップが本物で、かつ一貫していることを証明するために、グローバルなテストベッドを構築したのです。

• 4つの商用住宅プロキシ事業者 を購入：Bright Data（旧 Luminati）、Oxylabs、ProxyRack、Smartproxy。各事業者あたり月40〜50 GB の帯域。
• 22台のサーバー を Amazon Lightsail（16台）と Azure（6台）で世界中に分散配置。設置場所にはインド、オーストラリア、日本、ドイツ、アイルランド、カナダ、米国東部／西部、南アフリカ、UAE、ブラジルが含まれます。
• 各サーバーはクライアントとサーバーの両方として振る舞いました。すべてのサーバーから他のすべてのサーバーへ HTTPS GET を送信——直接で1回、そして4つのプロキシ事業者それぞれを経由して各1回、ペアごとに合計5経路です。
• キャンペーンは 110日間 実施されました（2022年1月12日〜5月1日）。サーバー側の TLS バージョンは日替わりで TLS 1.2 と TLS 1.3 を交互に切り替えたため、データセットは両バージョンをカバーしています。

壊れたキャプチャ、スキャナーのノイズ、短時間のダウンタイムを除外したあと、92,712,461件の完全な接続レコード が残りました——試行された約9,800万件の接続のうち、約95%にあたります。これは相当に本格的なデータセットです。

2つの RTT はどう測定されるのか

TCP RTT は単純明快です。サーバーが SYN-ACK を送り、クライアントからの最後の ACK を待ちます。この2つのあいだの時間が、サーバーから見た TCP RTT です。直接接続ならクライアント→サーバー、住宅プロキシ接続ならゲートウェイ→サーバーの値になります。

TLS RTT は少しだけ厄介です。著者らは、サーバーが何かを送信し、先に進む前にクライアントの応答を待たなければならない、そんな TLS ハンドシェイクレコードのペアを選びます。TLS 1.2 ならおおよそ ServerHelloDone → ClientKeyExchange、TLS 1.3 なら ServerHello と暗号化されたハンドシェイクメッセージの後 → クライアントの change_cipher_spec ／2回目のフライト、といった具合です。具体的にどのレコードかが本質ではありません。原則は「サーバーが送信し、続行する前に返答を待たなければならない地点を見つける」ことです。

TLS のバージョンに関わらず、このラウンドトリップは TLS 経路の全体を旅します。すなわちクライアント → スーパープロキシ → ゲートウェイ → サーバーです。直接接続なら、これは単にクライアント → サーバーになります。

そして、たった一つの数値を計算します。TLS RTT − TCP RTT です。小さければ直接接続。一貫して大きければ、TCP 層には見えない余分なホップが存在する、というわけです。

結果は容赦ない

論文の結果は、直接接続とプロキシ接続それぞれにおける TLS RTT − TCP RTT の分布を示しており、この2つの母集団はほとんど重なりません。

• 直接接続の97% は、差が 20 ms 以下 に収まります。
• 同じ軸でプロキシ接続を描くには、横幅を100倍——0〜2000 ms——に広げなければなりません。プロキシ経由のギャップは日常的に数百ミリ秒に達するからです。

一部の接続では差が負（TCP RTT のほうが TLS RTT より大きい）になります。これは SYN-ACK や最後の ACK がたまたまジッターで遅延し、後続の TLS パケットは遅延しなかった場合に起こります。稀なケースです。

• 直接接続：2.9%が負
• Bright Data：0.9%
• Oxylabs：1.8%
• ProxyRack：0.2%
• Smartproxy：1.4%

ジッターは存在します。しかし、それが分離可能性を壊すことはありません。

50 ms：99%を捕まえる閾値

著者らは実用的な閾値として 50 ms に行き着きました。彼らは、接続ごとの RTT が本来どれだけ自然にジッターするかを別途分析してこれを選んでいます。接続全体の53%において、単一接続内での RTT の最大値マイナス最小値の振れ幅は 50 ms 以下でした。つまり 50 ms は、通常のジッターを許容しつつ、典型的なプロキシのギャップよりは十分に小さい、というわけです。

このルール——「TLS RTT − TCP RTT > 50 ms なら住宅プロキシとしてフラグ付けする」——を適用した結果は以下のとおりです。

指標	値
偽陽性率	0.04%
偽陰性率	1.93%
全体精度	99.01%

偽陽性率0.04%は、正当なユーザーがこの網にかかることはほぼないことを意味します。これは決定的に重要です。実在する顧客を誤判定するコストは、数体のスクレイパーを取り逃がすコストよりはるかに高くつくからです。偽陰性率1.93%は、プロキシ経由のトラフィックがすり抜けることもほぼないことを意味します。

最悪のケースでさえ92.78%

疑い深い研究者ならこう反論するでしょう。もし最初の TCP RTT 測定が、たまたまその接続における最大値だったら？ そうなれば TCP RTT が水増しされ、ギャップが縮み、一部のプロキシトラフィックを通してしまうのではないか、と。

著者らはその最悪ケースをストレステストにかけました。約29%の接続では、最初の TCP RTT がその接続の最大値と一致します。これらすべてが運悪く偏っていると仮定すれば、想定しうる最悪の検出性能が出るはずです。同じ 50 ms の閾値で：

• 偽陽性：0.01%
• 偽陰性：9.68%
• 精度：92.78%

悲観的なジッター仮定のもとでさえ、これは依然として非常に強力な分類器です。実際の本番デプロイで最悪ケースが至るところで起こることはなく、現実は92%よりずっと99%に近いところに位置します。

「ゲートウェイがサーバーの近くにあったら？」

プロキシ事業者にとって自然な対抗策は、ゲートウェイを宛先のできるだけ近くにルーティングし、ゲートウェイ→サーバー間の TCP RTT を縮めることです。そのホップが極小なら、ギャップは潰れてしまうのではないか？

著者らは、まさにこれが最も効きそうなシナリオを検証しました。Bright Data については、ARIN／RIPE 地域に多数のゲートウェイがあることから、Virginia ↔ Virginia の接続を切り出しました。Oxylabs と Smartproxy については、LACNIC のプレゼンスが大きいことから、ブラジル国内の経路を見ました。ProxyRack については、AFRINIC のプールが相当規模あることから、南アフリカ国内を使いました。

結果は揺るぎませんでした。50 ms の閾値で、こうした「回避の最大のチャンス」を集めたサブセットの一部では、偽陰性率はむしろ約 0.78% にまで下がりました。なぜなら、たとえゲートウェイがローカルにあっても、クライアントとスーパープロキシはそうではなく、TLS 経路は依然としてチェーン全体にまたがるからです。

理論上、クライアント・スーパープロキシ・ゲートウェイ・サーバーを すべて同一の都市圏内 に制御できる攻撃者なら、ギャップを潰せるでしょう。しかし商用の住宅プロキシのスケジューリングはそのようには動きません。ローテーションのロジックは、ターゲットとの地理的な親和性など気にかけないのです。

重要：この手法は VPN や NAT は捕まえない

ここは論文を注意深く読むことが大切です。検出対象は具体的に、TCP 層をエンドツーエンドで断ち切りつつ、TLS 層はエンドツーエンドのまま保つ接続 です。バックコネクト型の住宅プロキシはこのパターンに当てはまります。一部の SSH 形式のフォワーディングも同様です。

標準的な NAT、IPsec VPN、WireGuard、それに類する VPN 技術は、通常 TCP 接続を終端しません。IP を書き換え、パケットをカプセル化し、トンネル経由でルーティングはしますが、TCP セッションは依然として元のクライアントとサーバーのあいだでエンドツーエンドです。その結果、TCP RTT と TLS RTT は、直接接続と同じように揃います。

「このユーザーはトンネルの背後にいるのか」という一般的な判定をしようとしているなら、この手法は適切なツールではありません。VPN や NAT の検出には、MTU 解析、IP レピュテーション、レイテンシのベースライン化、プロトコルフィンガープリントが必要です。

しかし、商用の住宅プロキシ市場という特定の対象——クレデンシャルスタッフィング、転売目的の買い占め、大規模スクレイピングに不釣り合いなほど深く関与している、まさにあの市場——に対しては、この手法は危険なほど効果的です。

知っておく価値のある注意点

この論文は USENIX／CCS／NDSS／IMC のようなトップティアの発表ではありません。ISPEC は立派ではありますがセカンドティアのセキュリティ会場です。実験は著者ら自身のクライアントとサーバーのインフラを使っており、実在の防御者による本番 Web サイトのトラフィックではありません。検出対象は狭く——TCP を分断し、TLS をパススルーする住宅プロキシに限られます。そして、もし事業者がアーキテクチャを設計し直せば（たとえばゲートウェイで TLS を終端するなど）、検出シグナルは縮みうるでしょう。

これらの注意点のどれも、結果を無効にするものではありません。ただ、この手法があらゆる種類のプロキシトラフィックに効く銀の弾丸ではない——最も普及している1種類にしか効かない——ことを教えてくれるだけです。

サイトを防御している側にとっての意味

ターゲットサイトを運営しているなら、これは追加できる検出手法の中でも最も費用対効果が高い部類に入ります。実装は概ね、SYN-ACK ／ACK と、選んだ TLS ハンドシェイクレコードの上でタイムスタンプを取得し、ギャップを計算し、50 ms で閾値処理し、それを既存のリスクスコアに流し込む——それだけです。

これ単体で行動を起こす必要はありません。レート制限、デバイスフィンガープリント、行動シグナルと組み合わせれば、偽陽性をさらに減らせます。しかし複数あるシグナルの一つとして見れば、「TLS RTT マイナス TCP RTT が 50 ms を超える」は、シグナルとして強力で、クライアント層ではほぼ偽装不可能で、しかもすべての TLS 接続で観測できます。

それ以外の検出レイヤーが2026年にどんな姿をしているかについては、当社の Anti-Bot Landscape 2026 フィールドガイドが、あなたが到達しようとしているどのターゲットの前にも立ちはだかっている可能性が最も高い6社のアンチボットベンダーを解説しています。

住宅プロキシを使っている側にとっての意味

居心地の悪い真実です。標準的な「バックコネクト＋TLS パススルー」アーキテクチャに従うすべての商用住宅プロキシ事業者は、この手法で検出可能です。これにはテストされた4社を含め、ほぼすべてのプレミアム事業者が当てはまります。

緩和策の道は限られています。

• 事業者側でのアーキテクチャ変更。 事業者はゲートウェイで TLS を終端し、ターゲットに対して張り直すことで、構造的な非対称性を取り除けます。しかしこれはプロキシが中間者（man-in-the-middle）として振る舞うことを要求し、証明書の検証を壊すため、本気のユーザーが受け入れるものではありません。
• チェーン全体を同一拠点に集約する。 クライアント・スーパープロキシ・ゲートウェイ・サーバーが同じ都市圏にあれば、ギャップは縮みます。しかし商用のプールベースのスケジューリングではこれは不可能です。
• この手法に見えない接続タイプを使う。 VPN や NAT ベースの出口は影響を受けません。ただしトレードオフがあります。それらにはそれら独自の検出ベクトルがあるのです。
• 接続タイプを多様化し、一定のトラフィックがフラグ付けされることを受け入れる。 これが多くのチームにとって現実的な答えです。すべてのリクエストに住宅出口が必要なわけではありません。Static ISP、モバイル、住宅を戦略的に使い分け、接続ごとのリクエストレートを下げ、フラグ付けされたトラフィックが永久ブロックではなくリトライ1回で済むようにワークフローを設計するのです。

これは「住宅プロキシはもう終わりだ」という記事ではありません。住宅プロキシは今も機能します。今も大半の本番防御をすり抜けます。なぜなら、大半の本番防御はまだ RTT ベースの検出を実装していないからです。要点はこうです。住宅プロキシの 構造的な優位性——本物のユーザーと寸分違わず見える、という点——には、測定可能で根本的な綻びがあり、防御に本気な者なら誰でもそれを突けるということです。

住宅が理にかなう場面と、モバイル・ISP・無制限が理にかなう場面について、より深く考えたいなら、Proxy Tier Decision Tree がユースケース別にトレードオフを順を追って解説しています。また、事業者横断の生のパフォーマンス数値については、14 Brands Tested が当社が公開している中で最も新しいベンチマークです。

2026年以降、本気でアンチスクレイプのインフラを構築する者は、誰もがこの手口を学ぶことになるでしょう。それを織り込んで計画してください。

---

参考文献: Casino, F., Patsakis, C., Lecharlier, B., & Ricci, V. (2022). BADPASS: Bots Taking ADvantage of Proxy as a Service. ISPEC 2022.