Cloudflareの誤検知でサイトが見られないときの原因と対処法

Cloudflareの導入後に、正規の利用者から「サイトを見られない」「フォームを送信できない」と連絡を受けることがあります。原因として考えられるのは、WAFやBot対策、レート制限による誤検知だけではありません。

配信元サーバーとの接続障害でも、サイトは表示されなくなります。サイト運営者は、表示されたエラーだけで原因を決めつけず、Cloudflareがリクエストを遮断したのか、配信元へ接続できなかったのかを切り分ける必要があります。

Cloudflare導入後にサイトが見られなくなる主な原因

WAFルールが正規のアクセスを攻撃と判定している

CloudflareのWAFは、Webサイトへ届くリクエストを検査し、設定した条件やマネージドルールに該当した通信へブロックやチャレンジなどの処理を行います。その過程で、正規の入力や操作を攻撃と判定する誤検知が起こる場合があります。

管理画面への投稿、検索フォーム、ファイルのアップロードなど、通常より複雑なデータを送信する操作は影響を受ける可能性があります。発生したページ、操作、日時、利用環境を確認し、問題が起きないアクセスとの差を整理することが必要です。

Bot対策やレート制限が正規の操作を遮断している

短時間に同じ操作を繰り返した利用者や、共通のネットワークを利用している組織からのアクセスが、Botや過剰なリクエストと判定されることがあります。ログイン、予約、購入、フォーム送信などにレート制限を設定している場合は、しきい値にも注意が必要です。

外部の監視サービスやAPI、Cloudflare Workersからのサブリクエストがルールの対象になるケースもあります。遮断されたという結果だけでWAFの誤検知と決めつけず、どのセキュリティ機能が処理を実行したのかを確認することが大切です。

502などの接続エラーと誤検知を混同しない

HTTP 502や504は、Cloudflareが配信元Webサーバーと正常に通信できない場合などに表示されるエラーです。配信元の過負荷、停止、ネットワーク障害、タイムアウト、圧縮データの不整合などが原因として考えられます。

そのため、502が表示されたからといって、WAFの誤検知とは限りません。発生日時とタイムゾーン、対象URL、エラー画面の内容を記録し、Cloudflareの情報だけでなく配信元サーバーの稼働状況やログも調査します。

Cloudflareの誤検知が発生したときの対処法

Security Eventsで遮断したルールとリクエストを特定する

Security Eventsでは、Cloudflareのセキュリティ機能が処理したリクエストを確認できます。発生日時、ホスト名、URLのパス、接続元、実行されたアクションなどで絞り込み、利用者が操作した時刻と一致するイベントを探します。

対象イベントを開いたら、どのサービスやルールがブロックまたはチャレンジを実行したのかを特定します。ただし、表示されるログの範囲や保存期間は契約プランによって異なり、データがサンプリングされる場合もあるため、問題の発生後は早めに確認しましょう。

ルール全体を無効にせず例外条件を限定する

誤検知を急いで解消しようとして、WAFのルールセット全体やBot対策を停止すると、正常なアクセスだけでなく攻撃も通過しやすくなります。問題を起こしたルールと対象リクエストを特定し、必要な範囲に限って調整する方法が適切です。

WAFのマネージドルールでは、条件に一致する通信について特定のルールやルールセットをスキップする例外を設定できます。対象URL、HTTPメソッド、利用者やシステムを識別できる条件などを組み合わせ、例外の適用範囲を必要最小限にすることが重要です。

Cloudflare WAFを調整する際は、対象ルールと適用条件を確認し、正常な操作をテストする順序で進めます。原因が分からないまま複数の設定を同時に変更すると、何が影響したのか判断しにくくなります。

変更後の動作確認と切り戻し手順を用意する

例外設定を追加した後は、問題の操作が正常に完了することを確認します。同時に、関係のないページや通信まで例外の対象になっていないか、従来の防御機能が引き続き動作しているかも確かめる必要があります。

想定外の影響が発生した場合に備え、変更前の設定と元に戻す手順を記録します。作業日時、変更者、承認者、変更理由、確認結果まで残しておけば、同様の問題が再発した際にも対応しやすくなります。

誤検知対応を運用代行会社へ依頼する際の確認点

障害発生時の受付時間と初動対応の範囲

24時間365日対応と案内されていても、その内容が問い合わせの受付だけなのか、ログ調査や設定変更まで含むのかは会社によって異なります。受付時間、初回応答までの目安、技術担当者が対応を開始する条件を確認しておきたいところです。

緊急時に顧客の承認を待つのか、事前に定めた条件で運用代行会社が例外設定や切り戻しを実施できるのかも重要です。対応時間だけでなく、誰が状況を判断し、どの範囲まで変更できる契約なのかを明確にします。

継続的なルール調整と作業報告に対応できるか

誤検知は、Cloudflare導入直後だけに発生するとは限りません。Webサイトの更新や新機能の追加、フォーム仕様の変更、WAFルールの更新などにより、これまで問題のなかった通信が影響を受ける可能性があります。

運用代行会社を選ぶ際は、セキュリティイベントの定期確認、ルールの調整、例外設定の棚卸しまで依頼できるかを確認します。月次レポートや作業報告に、検知件数だけでなく変更理由と対応結果が記載されるかも判断材料になります。

WordPressの投稿やログインで問題が起きる場合は、WAFに加え、WordPress側のプラグインやキャッシュ設定も調べます。すべての表示不具合が誤検知によるものとは限りません。

自社・制作会社・運用代行会社の役割を決める

サイトを見られない原因が、Cloudflareの設定ではなく配信元サーバーやアプリケーションにある場合、運用代行会社だけでは解決できません。自社担当者、制作会社、サーバー会社などへ調査を引き継ぐ手順が必要です。

Cloudflareのログ確認、配信元の調査、利用者への案内、設定変更の承認を誰が担当するのか、契約前に整理します。原因がCloudflare以外にあった場合も、必要な情報をまとめて関係事業者へ連携できる会社であれば、復旧までの対応を進めやすくなります。月額保守に含まれる調査・設定変更・他社への連絡を見積書に記載してもらうと、依頼できる作業と自社で担う作業を区別しやすくなります。