よこやま良平
DDoS攻撃被害なのか、通常のサーバー障害なのかは、エラー画面だけでは見分けられません。正解は、外部からのリクエスト量と種類、サーバー資源、事業者の障害情報、復旧までの変化を同じ時刻軸で照合することです。
503や504が出たという理由だけで攻撃と決めつけると、故障したデータベースや更新ミスを見落とします。反対に、障害だと思って再起動を繰り返せば、攻撃の証拠を失い、復旧が遅れるおそれがあります。
20年以上ITエンジニアとしてWordPressの制作・保守・復旧に携わっている、よこやま良平です。現場では、推測よりも複数の観測事実を時刻でつなぐことが、誤診を防ぐ最短ルートになります。
DDoSと通常障害の違い／5分で集める証拠／ログ・負荷グラフの読み方／503・504が出た時の切り分け／攻撃と判断する条件／事業者へ伝える内容が分かります。
この記事は、攻撃を断定する記事ではありません。自社で確認できる範囲を整理し、ホスティング会社やCDN事業者が調査できる材料を残すための診断手順です。上から順に実施し、確認時刻と結果をメモしてください。
こんなお悩みはありませんか？
- ある朝、サイトを開いたら真っ白画面になっていた
- 管理画面にログインできなくなって手が止まった
- 身に覚えのない記事やページが勝手に増えていた
- プラグインを更新したらサイト全体が崩れてしまった
- 以前バックアップを取ったか自分でも覚えていない
累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。
セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。
DDoS攻撃被害と通常障害の決定的な違い
DDoS攻撃被害と通常障害の決定的な違いでは、単独の症状ではなく複数の観測結果を時刻で照合することが結論です。
違いは「外から増えた通信」と「内側の故障」
DDoSでは、多数の送信元や大量の要求が外部から到達し、回線、CDN、Webサーバー、PHPなどの処理枠を使い切ります。通常障害では、通信量が平常でも、更新失敗、設定ミス、ディスク不足、データベース停止など内部要因で処理できなくなります。
ただし、人気記事への自然なアクセス集中も外部通信の増加です。アクセス数だけで攻撃と決めず、要求先、送信元の分散、同じ操作の反復、ブラウザらしさ、負荷との時間一致を確認します。
症状だけでは判定できない
DDoSでも通常障害でも、表示遅延、接続タイムアウト、502、503、504、管理画面へ入れない症状が出ます。HTTPコードは結果を示すものであり、原因の証明ではありません。
「503だから攻撃」「CPUが高いから攻撃」という単独判断は禁止です。少なくともトラフィック、サーバー資源、外部障害情報の3系統を照合します。
比較する時刻をそろえる
アクセス数は1分単位、CPUは5分平均、監視通知はJST、CDNログはUTCというように、画面ごとに集計幅とタイムゾーンが違います。時刻をそろえない比較は、無関係な山を同じ原因と誤認します。
発生時刻の前後30分を同じタイムゾーンへ変換し、最初の異常が通信、CPU、データベース、エラー率のどこに出たかを並べてください。
通信量・要求内容・サーバー資源・外部障害情報・直前変更・措置後の変化を、同じ時刻軸で比較します。
DDoS攻撃被害を5分で切り分ける確認順序
DDoS攻撃被害を5分で切り分ける確認順序では、単独の症状ではなく複数の観測結果を時刻で照合することが結論です。
最初に外部から1回だけ確認する
社内Wi-Fiとスマートフォン回線など、異なる2回線からトップページと軽い静的ページを1回ずつ確認します。片方だけ失敗するなら、社内DNS、回線、IP制限など局所的な問題を先に疑います。
何十回も再読み込みすると自分の通信が負荷を増やし、ログを汚します。確認したURL、回線、時刻、コード、表示秒数を記録すれば十分です。
公式障害情報と直前変更を確認する
サーバー、CDN、DNS、決済、外部APIの障害情報を確認します。同時に、直前のWordPress更新、PHP変更、DNS変更、バックアップ、インポート、キャンペーン開始の有無を一覧にします。
障害情報があっても自社の症状と対象リージョンが一致するとは限りません。反対に公式発表がまだなくても障害は起きます。観測事実の1つとして扱います。
三つのグラフを同時に見る
最低限、リクエスト数または帯域、CPUまたはPHPワーカー、5xxエラー率を同じ時間帯で比較します。通信増加が先に起き、直後に処理枠と5xxが上がれば外部負荷の疑いが強まります。
通信量が平常なのにデータベース接続エラーだけ増えた場合は内部障害が有力です。CPUが低いまま帯域上限へ達するなら、アプリより前の回線層で詰まっている可能性があります。
DDoS攻撃被害を示すログとグラフの読み方
DDoS攻撃被害を示すログとグラフの読み方では、単独の症状ではなく複数の観測結果を時刻で照合することが結論です。
送信元の数より要求の特徴を見る
送信元IPが多いだけではDDoSの証拠になりません。CDNや携帯回線では多数の利用者が同じIPを共有し、正規アクセスも世界中から届きます。短時間に同じURLへ不自然な反復があるか、存在しないURLや重い検索へ集中しているかを確認します。
User-Agentが空、同じ間隔、Cookieを保持しない、静的ファイルを読まず特定APIだけ叩く、といった特徴は材料になります。ただし偽装できるため、一つの特徴で断定しません。
帯域型とアプリケーション型を分ける
帯域型では受信量が契約上限へ近づき、WordPressへ届く前にタイムアウトすることがあります。アプリケーション型では帯域が極端でなくても、ログイン、検索、XML-RPC、REST APIなど処理の重いURLへ要求が集中し、PHPワーカーやデータベースが枯渇します。
どの資源が先に上限へ達したかで、相談先と緩和策が変わります。帯域なら上流事業者、特定URLならCDN・WAFのレート制限も重要です。
ログを消さず原本を保全する
アクセスログ、WAFイベント、CDN分析、CPU、メモリ、帯域、ディスクI/Oの画面を保存します。CSVやログを取得できるなら、対象期間を含めて原本のまま保管し、加工版と分けます。
IPアドレスやCookieを含むログをSNSへ公開してはいけません。共有先は契約上の窓口に限定し、ファイル名へ対象、開始・終了時刻、タイムゾーンを入れます。
DDoS攻撃被害と間違えやすい通常障害
DDoS攻撃被害と間違えやすい通常障害では、単独の症状ではなく複数の観測結果を時刻で照合することが結論です。
WordPress更新とPHPエラー
プラグインやテーマ更新直後に全ページで500系が出た場合、DDoSより互換性エラーを先に疑います。アクセスが少なくても同じURLで必ず再現し、PHPエラーログへ同時刻のFatal errorが残るなら内部障害の可能性が高いです。
ただし攻撃中に自動更新が重なった例もあります。更新を戻しても通信増加が続くなら、二つの事象を分けて調査します。
データベース・ディスク・証明書
データベース停止では「データベース接続確立エラー」、ディスク満杯ではログやセッションを書けない症状、証明書では特定日時からTLSエラーが出やすくなります。これらは平常トラフィックでも発生します。
容量、接続数、期限、サーバー時刻を確認し、アプリ層の異常とネットワーク負荷を混同しないでください。
自然なアクセス集中とクローラー
テレビ紹介、SNS拡散、メール配信、広告開始、検索クローラーでもアクセスは急増します。正規アクセスは複数ページを読み、画像やCSSも取得し、地域や参照元が施策と整合する傾向があります。
正規利用者を攻撃と誤認して遮断すれば機会損失になります。参照元、閲覧遷移、コンバージョン、キャッシュヒット率を見て、悪性通信と分離します。
DDoS攻撃被害か判断する実務フロー
DDoS攻撃被害か判断する実務フローでは、単独の症状ではなく複数の観測結果を時刻で照合することが結論です。
三つ以上の根拠がそろうまで「疑い」と表現する
攻撃と判断するには、異常な通信増加、悪性と考えられる要求パターン、資源枯渇との時間一致、事業者の観測など複数の根拠が必要です。根拠が不足する段階では「DDoSの疑い」と記録します。
社内や顧客へ未確認の断定をすると、後で訂正が必要になり信用を損ねます。技術判断と対外発表は分け、確認済みの影響だけを伝えます。
止血と原因調査を並行する
判定が終わるまで何もしないのも危険です。CDNや事業者へ調査を依頼しながら、ログ保全、告知手段の準備、重要機能の影響確認を進めます。変更は目的、時刻、元の値、戻し方を記録します。
DNS変更、再インストール、ログ削除、無計画な再起動は避けます。原因を隠し、通常障害を新たに作る可能性があります。
再現条件で判定を更新する
特定IPを一時遮断すると改善する、CDNの攻撃対策モードでオリジン負荷が下がる、データベース再起動だけで安定するなど、措置後の変化も重要な証拠です。
一度の改善だけで結論にせず、解除すると再発するか、平常値へ戻るかを観測します。攻撃と通常障害が同時発生する可能性も残してください。
DDoS攻撃被害を事業者へ正確に伝える方法
DDoS攻撃被害を事業者へ正確に伝える方法では、単独の症状ではなく複数の観測結果を時刻で照合することが結論です。
問い合わせ文は事実と推測を分ける
対象ドメイン、契約ID、発生時刻、影響URL、エラーコード、別回線での再現、平常比の通信量、負荷、直前変更をまとめます。そのうえで「DDoSを疑うが断定していない」と書き、上流ログの確認を依頼します。
「サイトが落ちた」だけでは調査範囲が広すぎます。最初の異常時刻と、現在も継続しているかを明記すると担当者がログを絞れます。
確認したい質問を具体化する
異常トラフィックを観測しているか、どの層で詰まっているか、送信元や要求先に偏りがあるか、DDoS緩和が適用されたか、正規通信への影響、解除条件を質問します。
自社で見えない回線層の情報は事業者しか確認できません。推測で設定を変える前に、観測結果と推奨措置を求めます。
復旧後も判定記録を残す
最終原因、根拠、実施措置、改善時刻、誤検知、費用、次回の連絡先を1つの報告書にします。通常障害だった場合も、なぜDDoSを疑ったかを残せば次回の診断が速くなります。
平常時のリクエスト数、帯域、CPU、5xx率を保存しておくと比較基準になります。基準がなければ「多い」「遅い」という感覚だけになり、判断がぶれます。
DDoS攻撃被害の判定を深める症状別ケース
DDoS攻撃被害の判定は、実際に起きた症状を層ごとに分けると精度が上がります。ここでは現場で混同しやすい代表例を、観測する順番とともに整理します。
トップページだけが遅い場合
トップページに重いスライダー、外部API、未キャッシュの一覧があると、通常障害でもそこだけ遅くなります。静的な画像や軽い下層ページが速いなら、回線全体の飽和よりページ固有処理を先に調べます。
一方、トップページだけへ短時間に大量要求が集中し、CDNを通過してPHP実行数が跳ねているならアプリケーション層攻撃を疑います。キャッシュヒット率とオリジンへの到達数を分けて確認してください。
管理画面だけが遅い場合
公開ページがキャッシュで正常でも、管理画面はPHPとデータベースを使うため遅くなることがあります。バックアップ、集計、予約処理、プラグイン更新が同時に動いていないかを確認します。
ログインURLへの大量試行があれば攻撃の可能性もあります。ただし不正ログインとDDoSは同義ではありません。認証失敗数、送信元、応答時間、PHPワーカー枯渇が同時刻かを確認します。
特定地域だけ見られない場合
特定地域や通信会社だけの不具合は、経路障害、DNSキャッシュ、CDN拠点障害、地域制限でも起きます。地域別監視と複数DNSリゾルバーで確認し、全世界の停止と混同しないことが重要です。
攻撃対策で国別制限や誤検知が有効になった可能性もあります。WAFの適用履歴とブロック理由を調べ、正規利用者を巻き込んでいないかを確認してください。
数分ごとに復旧と停止を繰り返す場合
自動復旧するプロセス、負荷監視による再起動、データベース接続枠の回復、キャッシュ再生成でも周期的な停止が起きます。周期がジョブ実行時刻と一致するなら内部処理が有力です。
攻撃側が波状に通信を送る場合もあります。リクエストの波と停止時刻が一致し、要求元や対象URLも同じ傾向なら、事業者へ周期を含めて伝えると調査しやすくなります。
画像は見えるがページが開かない場合
画像がCDNキャッシュから返り、HTMLだけオリジンで生成されている構成では、PHPやデータベース障害時にこの差が出ます。静的配信が生きているため、回線全体が落ちたとは限りません。
HTML生成URLへ悪性要求が集中するアプリケーション層攻撃でも同じ状態になります。CDN配信数とオリジン要求数、PHP処理時間を照合し、内部故障か外部負荷かを分けます。
監視は正常なのに利用者から苦情が来る場合
監視が一つの地域からトップページだけを確認していると、DNS、IPv6、ログイン、フォーム、決済の障害を見逃します。監視正常という一件だけで利用者側の問題と決めつけてはいけません。
攻撃対策が特定の通信会社やブラウザを誤遮断しているケースもあります。利用者の個人情報を求めすぎず、時刻、回線、URL、表示内容を集め、WAFイベントと照合します。
CPUは低いのにタイムアウトする場合
回線帯域、接続数、ロードバランサー、DNS、TLS、CDNといったWordPressより前の層で止まると、オリジンCPUは低いままです。CPUが低いから攻撃ではない、とは言えません。
反対に、上流サービスの障害なら攻撃通信がなくても同じ結果になります。帯域、接続数、オリジン到達数、事業者の経路情報を確認し、自社サーバーのグラフだけで結論を出さないでください。
CPUは高いがアクセス数が少ない場合
バックアップ圧縮、マルウェアスキャン、画像生成、データベース最適化、暴走した定期処理など、少数の内部処理でもCPUは上がります。プロセス一覧とジョブログを先に確認します。
少数に見えても、集計画面がCDNで遮断済みの通信を除外している場合があります。どの地点のアクセス数かを確認し、WAF前、WAF後、オリジン到達後の数値を混ぜないことが大切です。
エラーコードが途中で変わる場合
最初は504、その後503、最後はデータベース接続エラーという変化は、負荷が複数の資源へ波及した可能性があります。画面を上書きせず、コードが変わった時刻をすべて記録します。
設定変更や再起動によってコードが変わった場合は、その操作自体が原因分析の材料です。変更前後の値を残し、改善したように見えても最低30分は負荷とエラー率を観測します。
夜間だけ障害が起きる場合
夜間バックアップ、集計、予約投稿、セキュリティ処理、サーバーメンテナンスは、毎日ほぼ同じ時刻に負荷を作ります。再現時刻が固定なら、まずスケジュール処理を一覧化します。
攻撃も利用者が少ない時間を狙うことがあります。開始時刻が固定か、要求元とURLが反復するか、ジョブ停止で改善するかを数日分比較し、偶然の一致を避けます。
判定表へ残す項目
判定表には、観測時刻、確認者、回線、URL、HTTPコード、応答時間、リクエスト数、帯域、CPU、メモリ、PHPワーカー、データベース接続、WAFブロック、直前変更を横並びで記録します。数値を取れない項目は空欄にせず「権限不足」「画面へ接続不能」と理由を書きます。
スクリーンショットだけでは集計条件が分からなくなるため、期間、タイムゾーン、フィルターも一緒に保存します。平常日の同じ曜日・時間帯と比較すれば、季節変動や広告による正規アクセス増加を攻撃と誤認しにくくなります。
最終欄には、現時点の仮説、反証になる事実、次に確認する項目を書きます。攻撃説だけを補強する材料を集めるのではなく、通常障害なら説明できる事実も並べることで、思い込みを減らせます。
一つの画面、一つのコード、一つのグラフだけで決めず、「どの層で」「何が先に」「措置後どう変わったか」を必ず記録します。担当交代時にも同じ基準で判断できるよう、口頭説明だけで終わらせず、確認できなかった項目を含めて時系列表へ残してください。
DDoS攻撃被害の見分け方でよくある質問
判定時に迷いやすい点を、実際の現場で確認する順番に沿って短く整理します。
いいえ。更新失敗、PHPワーカー不足、データベース障害でも出ます。通信量、資源、ログを照合してください。
断定できません。正規利用者やクローラーも海外から接続します。要求先、頻度、挙動を合わせて判断します。
重い処理、バックアップ、検索、更新でも上がります。通信増加が先か、内部処理が先かを時刻で比較します。
ログを消さず、発生時刻と各グラフを保存し、ホスティング会社やCDNへ上流の観測確認を依頼してください。
DDoS攻撃被害と通常障害の見分け方まとめ
DDoSと通常障害は、503やタイムアウトなど表面の症状が似ています。外部通信、要求の特徴、資源、外部障害情報、直前変更を同じ時刻軸で比較し、三つ以上の根拠がそろうまでは「疑い」と扱うのが安全です。
ログを消さず、変更を一つずつ記録し、自社で見えない回線層は事業者へ確認してください。よこやま良平が現場で重視するのは、早い断定ではなく、後から検証できる判断です。
別回線で確認／公式障害情報を確認／通信・資源・5xxを比較／ログ原本を保存／事実と推測を分けて連絡、の順番を守ります。
DDoS攻撃被害か通常障害か判断できない時は
ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。
WordPressが真っ白画面／WordPressがログインできない／ホームページのマルウェアや乗っ取り／サイトの表示くずれ／エラーが表示されている
これらでお悩みなら最短30分ですぐに解決します！
いまなら期間限定で
・万一改善されない場合は全額返金保証で安心!
・30日間動作保証で安心!
・初期費・調査料 0円で安心!