なぜ不正アクセス対策に「キャッシュ」が有効なのか？

DDoS攻撃やBotによる大量のスパムアクセス（不正アクセス）が発生した際、最も避けるべきは「サーバー側でデータベース検索やプログラム実行（PHP等）が大量に走り、サーバーがダウンすること」です。

不正アクセスと判断したリクエストに対して、動的な処理を行わずに「キャッシュされた軽量なデータ」や「静的なエラーレスポンス」を即座に返すことで、オリジンサーバーのCPUやメモリの消費をほぼゼロに抑えることができます。

処理方法	サーバー負荷	特徴
動的処理でエラー応答（WordPress等でブロック）	高い	PHPやDBが起動するため、大量アクセスに耐えきれずダウンするリスクがある
Webサーバー / CDNでキャッシュ応答（429/403）	極めて低い	重い処理をスキップし、あらかじめ用意した静的ファイルやメモリキャッシュを返すため高耐久

不正アクセス時に負荷をかけず対処する3つのアプローチ

1. CDN（エッジサーバー）でオリジン到達前に遮断・キャッシュ応答する

最も効果的なのは、自社のオリジンサーバーにアクセスが届く手前のCDN（Cloudflare、AWS CloudFrontなど）で防御する方法です。

• Rate Limiting（レート制限）： 同一IPからの一定時間内のリクエスト数が閾値を超えた場合、自動的に「429 Too Many Requests」をCDN側で返答します。
• WAFルールの適用： 不正なBotや悪意あるアクセスパターンを検知し、チャレンジ（CAPTCHA）表示やブロック画面をCDNのエッジから返します。
• Staleキャッシュの活用： 万が一オリジンサーバーが高負荷状態になった場合でも、古いキャッシュ（Stale Cache）を自動で返し続けてWebサイトの完全ダウンを防ぎます。

2. Webサーバー（Nginx等）レベルで静的レスポンスを返す

CDNを導入していない場合やWebサーバー側で直接防ぐ場合は、Nginxのレート制限機能（limit_req）などを活用します。アプリケーション（PHP）に処理を渡す前に、Webサーバー層で即座に拒否・応答します。

以下は、Nginxで一定のリクエスト数を超えたアクセスに対し、即座に静的なエラーページ（429）を返してサーバー負荷を抑える設定例です。

# httpブロック内に記述（IPごとのリクエストレート制限ゾーンを定義）
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;

server {
    listen 80;
    server_name example.com;

    location / {
        # 制限を超えた場合は即座に429エラーを返す
        limit_req zone=mylimit burst=10 nodelay;
        limit_req_status 429;

        proxy_pass http://backend;
    }

    # 429エラー時はPHPを通さず、軽量な静的HTMLファイルを返す設定
    error_page 429 /custom_429.html;
    location = /custom_429.html {
        root /var/www/html/errors;
        internal;
    }
}

3. 静的ページ化（Static Cache）による完全キャッシュ運用

不正アクセスが猛烈で特定IPの遮断が追いつかない場合、一時的にページ全体を静的キャッシュ化（FastCGI CacheやNginx Proxy Cache）し、すべてのユーザーに対してキャッシュ済みの静的ファイルだけを返す状態にします。

データベース接続が発生しないため、通常時の数千倍のリクエストにも耐えうる強靭な状態を作ることができます。

不正アクセス対策時の注意点と運用ポイント

• キャッシュのTTL（生存期間）の調整： 不正アクセス検出時のエラー応答画面（429等）に適切なキャッシュヘッダーを付与し、正規ユーザーにまでエラー画面が固定化・キャッシュされないよう注意する。
• 正規ユーザーの巻き込み防止： 企業のプロキシサーバーやスマホキャリアのIPなど、共有IPからの正常アクセスを誤って恒久ブロックしないよう、判定基準（閾値）を慎重に設定する。
• ログのメモリ出力・集約： アクセスログをディスク（HDD/SSD）にリアルタイムで大量書き込みするとI/O負荷でサーバーが遅延します。攻撃時はログレベルを下げるか、メモリ上（syslog等）に流す構成を検討します。

💡 ワンポイントアドバイス
「WordPressのセキュリティプラグインでブロックする」のも手軽で有効ですが、超大量のアクセスに対しては「プラグインが起動する＝PHPやDBが動く」ため、結局サーバーがダウンしてしまいます。大規模な不正アクセスには「CDN」や「Webサーバーレベル」でのキャッシュ・応答処理が鉄則です。

まとめ：多層防御とキャッシュ活用で安全な運用を

不正アクセスと判断したアクセスに対しては、「できるだけ手前のレイヤー（CDN ＞ Webサーバー ＞ アプリケーション）で」「処理負荷の最も低いキャッシュや静的レスポンスを返す」ことがサーバーを守る鍵となります。

平常時からCDNの導入やWebサーバーのレート制限を設定しておき、万が一の攻撃時にもサーバーダウンを起こさない堅牢な環境を作っておきましょう。