モバイルトラフィックからのコンバージョンが突然減少し、実際の顧客が登録や支払いフォームで403エラーを受け取っている場合、原因はハッカーではなく、あなたのWAFの可能性が高いです。ファイアウォールは、モバイル通信事業者の1つのIPアドレスからの数千のリクエストを見て、これをDDoSまたはブルートフォース攻撃と見なします。実際には、このIPの背後には数百または数千の普通の人々がいるのです — これがCGNAT技術です。これを発見し修正する方法を見ていきましょう。実際の攻撃に対して穴を開けることなく。
CGNATとは何か、なぜ問題を引き起こすのか
CGNAT(キャリアグレードNAT)は、モバイル通信事業者がIPv4アドレスの不足から使用する技術です。各加入者にユニークなパブリックIPを割り当てる代わりに、事業者は数千のユーザーを1つまたは複数の共有アドレスの背後に「隠します」。ウェブサイトにとっては、1つのIPから数百の異なる人々からのトラフィックが同時に来るように見えます — 異なるデバイス、異なるブラウザ、異なる行動ですが、同じ外部アドレスです。
通常のウェブサーバーにとっては問題ありません — リクエストを処理するだけです。しかし、1つのIPからのリクエストを時間単位でカウントするセキュリティシステムにとっては、これは異常に見えます。想像してみてください:1分間に1つのアドレスから200のログインページへのリクエストが来ます。WAFにとっては、これは典型的なブルートフォースまたはスクレイピングのパターンです。しかし実際には、これはあなたの地域の1つのモバイル通信事業者の150人の実際の顧客が、広告キャンペーンやソーシャルメディアの投稿の後に同時にウェブサイトを開いた結果かもしれません。
特にモバイルインターネットの密度が高い国では、この問題が顕著に現れます — 事業者は少数の外部IPの背後に膨大な数の加入者をまとめます。したがって、ウェブサイトの動作を通常のデータセンターのIPではなく、実際に事業者のCGNATインフラストラクチャを通過するモバイルプロキシからテストする必要があります — これにより、WAFが実際のユーザーに見えるのと同じ状況を再現できます。
なぜWAFはCGNATを脅威と見なすのか
大多数のWAFソリューション — Cloudflare、AWS WAF、Imperva、Nginx/ModSecurityの組み込みモジュール — は、ボットやDDoSからの基本的な保護メカニズムとしてIPアドレスによるレート制限を使用します。論理は簡単です:1つのIPからT秒間にNを超えるリクエストがあれば — ブロックするか、キャプチャを表示します。このルールは、1つのデバイスからの従来の攻撃にはうまく機能しますが、CGNATトラフィックでは完全に崩壊します。
これが発生する典型的なシナリオはいくつかあります:
- IPによるレート制限。 「1つのIPからの1分間に100リクエスト」という制限は、データセンターのトラフィックには正常ですが、1つのアドレスの背後に100万人の加入者がいるモバイル地域には壊滅的です。
- 行動スコアリング。 システムがリクエストの履歴に基づいてIPの「評判」を蓄積する場合、CGNATの背後にいる1人の「悪い」ユーザーが、後続の数千人の正直な顧客のためにアドレスの評判を悪化させる可能性があります。
- 地理的ヒューリスティック。 WAFは、通常のユーザーには特有でない急激な活動の変動を観察すると、IPを疑わしいとマークすることがあります — CGNATアドレスの行動はまさにそれです:オーディエンスの活動時間にピーク負荷がかかります。
- 事業者のASNによるブロック。 一部のWAFルールは、以前に攻撃があった場合、モバイル通信事業者のASNの範囲全体をブロックします — その結果、国のすべての事業者の顧客が影響を受けます。
結論:WAFが「箱から出して」厳しく設定されているほど、ボットではなく実際のモバイルオーディエンスをブロックする可能性が高くなります — 特にビジネスが発展したモバイルインターネットと高いCGNATトラフィックの割合を持つ国に焦点を当てている場合。
ビジネスにどのような影響があるのか:失われた顧客とお金
CGNATブロックの問題は、標準的な分析ではほとんど見えません。Google AnalyticsやYandex.Metricaは、WAFレベルで403エラーを受け取った人々を記録しません — そのような訪問はしばしばカウンターに到達しません。その結果、マーケティング担当者はコンバージョンの減少を見ますが、その原因を理解せず、クリエイティブやランディングページを最適化し始めますが、問題はインフラストラクチャにあります。
ビジネスのさまざまなセグメントに対する実際の影響:
- 電子商取引。 モバイルインターネットの購入者が注文を完了できない — 支払いフォームがエラーを返し、カートが失われます。特にTikTok AdsやFacebook Adsで広告を開始した後に目立つ直接的な収益の損失があります。
- SaaSと登録。 ユーザーが登録または個人アカウントにログインしようとすると、各ステップでキャプチャが表示されたりブロックされたりし、競合他社に移ります。
- コンテンツと広告。 モバイルデバイスからの広告トラフィックがランディングページで大量に「切断」され、広告予算が消費され、コンバージョンがありません — 広告プラットフォームのアルゴリズムはこれを低品質のオーディエンスとして解釈し、クリック単価を引き上げます。
- サポートサービス。 「あなたのサイトが開かない」、「登録できない」という問い合わせが増加します — しかし、テクニカルサポートは問題を見えず、オフィスのWi-Fiを介してデスクトップからCGNATなしでアクセスしています。
最も厄介なのは、このようなブロックを事後に診断するのが難しいことです。なぜなら、WAFのログは1つの「疑わしい」IPを大量のリクエストと共に示し、管理者はこれをブロックの正当性の証拠と見なすからです。
問題を見つけるためのモバイルIPからの6つのチェック
あなたのWAFが正直なモバイル顧客をブロックしているかどうかを理解するためには、CGNATの実際の条件を再現する必要があります — つまり、異なる事業者と地域の本物のモバイルIPからウェブサイトをテストする必要があります。以下は6つのチェックの実践的なチェックリストです。
チェック1:1つのモバイルIPからの大量アクセス
同じモバイルIPを介していくつかの並行セッションを設定し(これはCGNAT事業者のプロキシにとって自然です)、50〜100の通常のアクションを実行します — ページのオープン、カートへの追加、セクション間の移動など。特定の閾値を超えた後にキャプチャや403が表示され始める場合、これは問題の最初の兆候です。
チェック2:1つのIPでのUser-Agentの変更
1つのCGNATアドレスは異なるデバイスをサポートします — iPhone、Android、異なるブラウザ。異なるUser-Agent文字列を使用して1つのIPからリクエストを実行し、WAFルール「1つのアドレスからのデバイスの疑わしい変動」が発動しないか確認します。
チェック3:重要なフォームでのテスト
モバイルIPを介して顧客の完全なプロセスを通過します — 登録、認証、注文、支払い。WAFは、データ入力(ログイン、支払い)のあるフォームに対して特に攻撃的に設定されていることが多く、ここが実際の顧客が失われる最初の場所です。
チェック4:異なる事業者や地域でのチェック
CGNATの動作は、異なる事業者や国によって異なります — どこでは1つのIPの背後に50人の加入者が隠れているかもしれませんし、どこでは5000人かもしれません。ビジネスにとって重要な地域の複数の事業者のモバイルIPからウェブサイトをテストし、地域特有のブロックがあるかどうかを確認します。
チェック5:サーバーの応答のコードとヘッダーの分析
ブロックの事実だけでなく、正確なHTTPコードと応答ヘッダー(例えば、cf-mitigated: challenge Cloudflareで)を記録します。これにより、どの保護メカニズムが作動したのか — レート制限、ボット検出、または地理的ルールを理解するのに役立ちます。
チェック6:IPの評判の長期監視
同じモバイルIPからのテストを数日間繰り返します。時間が経つにつれてアクセスが悪化し、あなたの側に明らかな理由がない場合 — システムの蓄積スコアリングが他の加入者の活動のためにアドレスの評判を「悪化させている」ことを意味し、これはシステム的な問題であり、単発の問題ではありません。
重要な理解:
このようなテストには、データセンターや通常のレジデンシャルアドレスではなく、実際のモバイルIPが必要です — 事業者のインフラストラクチャを通過したトラフィックのみが、あなたのWAFが実際のユーザーに見えるCGNATパターンを正確に再現します。
正直な顧客をブロックしないようにWAFを設定する方法
診断の後、セキュリティルールを調整して、セキュリティレベルを失うことなく、実際のモバイルユーザーをブロックしないようにする必要があります。以下は主なアプローチです。
| 問題 | WAFでの解決策 |
|---|---|
| 厳しいIPによるレート制限 | 知られているモバイル通信事業者のASNに対して制限を引き上げるか、純粋なIPの代わりにセッション/クッキーによる制限に切り替える |
| IPの評判の蓄積スコアリング | CGNATの範囲に対する「評判の記憶」の時間を短縮し、知られている事業者のASNに対してホワイトリストを追加する |
| 地理/ASN全体によるブロック | 完全なブロックを403の代わりにソフトなチャレンジ(JSチェック)に置き換える |
| ログインフォームでの厳しいキャプチャ | 実際のブルートフォースの兆候(1つのアカウントからの複数の失敗した試行)がある場合にのみ、キャプチャを適応的に表示する |
良い実践は、あなたの重要な地域における知られているモバイル通信事業者の範囲のリストを維持し、通常のインターネットトラフィックに比べてそれらに対してより柔軟なルールを提供することです。これには設定に時間がかかりますが、誤ったブロックの数を大幅に減少させます。
モバイルプロキシを使用したテストツール
ウェブサイトの保護を定期的に監査するためには、アンチデテクトブラウザとモバイルプロキシの組み合わせを使用するのが便利です。アンチデテクトブラウザ(Dolphin Anty、AdsPower、Multilogin、GoLogin、Octo Browser)は、異なるデバイスのフィンガープリンティングを持つ隔離されたプロファイルを作成することを可能にし、モバイルプロキシは事業者からの実際のCGNATトラフィックを提供します。
テストへのステップバイステップアプローチ:
- 異なるデバイスのパラメータ(異なるUser-Agent、画面解像度、タイムゾーン)を持つアンチデテクトブラウザでいくつかのプロファイルを作成します。
- 各プロファイルに必要な地域と事業者のモバイルプロキシを接続します — これによりCGNATの実際の動作が得られます。
- 主要なユーザースクリプトを通過します:登録、ログイン、カートへの追加、支払い。
- すべてのキャプチャ、403、およびその他のブロックのケースを記録し、WAFの設定と照合します。
- 比較のためにレジデンシャルプロキシでテストを繰り返します — これにより、問題がモバイルトラフィックに特有であるかどうかを理解するのに役立ちます。
異なる地域での並行テストには、レジデンシャルプロキシも便利です — これにより、WAFが通常の家庭のトラフィックとモバイルCGNATに対してどれほど同じように攻撃的であるかを評価できます。事業者に依存しないサーバーインフラストラクチャからの負荷テストを計画している場合、CGNAT効果なしのコントロールチェックのためにデータセンターのプロキシを接続することができます — これにより、モバイルネットワーク特有の歪みのないクリーンなベースラインが得られます。
この包括的なアプローチ — モバイル、レジデンシャル、データセンターのIPを1つのテストで使用すること — は完全な画像を提供します:どこで保護が作動し、どのタイプのトラフィックに対して作動しているのかを正確に把握でき、ログの間接的な兆候に基づいて推測することはありません。
よくある質問
CGNAT範囲をWAFのルールから完全に除外できますか?
推奨されません — これは、モバイルネットワークを介しても実際の攻撃からの保護を低下させます。より適切なのは、しきい値を緩和し、厳しいブロックの代わりにソフトなチャレンジに切り替えることです。
このようなチェックはどれくらいの頻度で行うべきですか?
最低でも月に1回、WAFのルールを変更した後やモバイルオーディエンス向けの新しい広告キャンペーンを開始した後に必ず行うべきです。
これはSEOに影響しますか?
はい — 検索ボットや実際のモバイルデバイスのユーザーが403を受け取ると、離脱率が増加し、ランキングの行動メトリクスに悪影響を及ぼす可能性があります。
結論
CGNATは脅威ではなく、モバイルインターネットの特性であり、モバイルオーディエンスを持つほぼすべてのビジネスが直面するものです。問題は技術そのものではなく、標準のWAF設定がその特性を考慮しておらず、正直なユーザーを通常のモバイルネットワークに特有の行動で罰していることです。この記事の6つのチェックは、誤ったブロックによって顧客を失っているかどうかを迅速に診断するのに役立ち、WAFルールのポイント設定は、保護レベルを低下させることなくコンバージョンを回復します。
ウェブサイトと広告ファネルの動作を実際のモバイル顧客が見るように定期的にテストする予定がある場合は、モバイルプロキシを使用することをお勧めします — これにより、事業者の実際のCGNATトラフィックが得られ、顧客が見つける前に誤ったブロックを特定できます。