事例研究: Cloudflare 403と実際のダウンタイム

サポートチームは、監視チェックから403応答を受け取った後、「サイトダウン」と報告しました。エンドユーザーはブラウザでホームページを読み込めていました。この事例では、その矛盾をどう解釈するかを説明します。

観察された症状

• 自動チェックがHTTP 403を返した。
• ブラウザユーザーは時々チャレンジページを見た後、成功した。
• オリジンサーバーのクラッシュや5xxエラーの証拠はない。

使用した診断手順

1. URLを ウェブサイトチェッカー で実行し、ステータステキストとメモを記録する。
2. 応答にボット保護のパターン（Cloudflareチャレンジのヒント）が含まれるか確認する。
3. ブラウザからテストし、サーバー側チェックの挙動と比較する。
4. エッジ設定のWAF/レート制限ポリシーのしきい値を確認する。

根本原因

サイトはオンラインでしたが、WAF設定が非ブラウザトラフィックを疑わしいと判断しました。合成チェックは完全なページコンテンツに到達する前にエッジでブロックされました。

修正と検証

• 想定される監視動作に合わせてボット/WAFルールを調整した。
• 診断用エンドポイントの過度に厳しいレート制限設定を緩和した。
• 再テスト: チェッカーはblocked/limitedから安定したオンライン応答に変わった。

要点

• 403は必ずしもダウンタイムを意味しない。
• リクエストの種類によって結果が異なることがある。
• 障害を宣言する前に、チェッカーのステータスとエッジセキュリティログを照合する。

関連記事: 5xxトラブルシューティングガイド および チェッカー方法論。