XServerのDDoS攻撃でサイトにつながらない時はどうする？対象サーバーと障害情報の確認手順

XServerでサイトにつながらない時は、まず自分のサーバー番号と公式障害情報を照合します。サービス全体の障害だと決めつけず、同じsv番号と発生時刻が載っているかを見るのが出発点です。

XServerのDDoS攻撃が対象サーバーと一致したら、WordPress、DNS、SSLの設定変更を重ねる前に証跡を残してください。
エラー画面、時刻、確認URL、別回線での結果をそろえると、XServer側の障害と自社サイト固有の不具合を切り分けやすくなります。

XServerのDDoS攻撃は対象サーバー番号で判断する

XServerのDDoS攻撃は、公式の障害情報に載った対象サーバー番号と時間で判断します。「レンタルサーバーで障害」という情報だけで、すべての契約サーバーが止まったとは言えません。

2026年8月末に公式掲載された主な対象

掲載日	対象	公式の記録
8月30日	sv202	17:28〜17:39
8月29日	sv2105	2:49〜2:57
8月27日	sv8345	9:47〜10:24
8月25日	sv8803	18:07〜18:22

これは2026年8月25日〜30日に確認できた主な掲載例であり、期間内の全件一覧ではありません。対象と時間は更新されるため、実際の確認では公式一覧を開き、自分のsv番号と発生時刻を照合してください。

出典: XServer「障害・メンテナンス情報」

「復旧」と「アクセスフィルタリング解除」は分けて読む

障害情報では、Webサーバーの復旧とアクセスフィルタリングの状態が別々に更新される場合があります。フィルタリングとは、攻撃を減らすために特定の通信を制限する措置であり、サイトが開くようになっても一部の通信へ影響が残ることがあります。

sv8345の公式詳細では、2026年8月27日10:27頃から一部環境のアクセスフィルタリングが案内されました。この記事の取得情報だけで8月31日時点の継続・解除を断定せず、詳細ページの最終更新を見て判断します。

また、同社の別の障害対応では、フィルタリングにより認証局からの通信が遮られ、無料独自SSLの有効化や有償SSLの取得・更新・再発行に失敗する場合があると案内されました。フィルタリング中にSSL操作を急がず、先に対象サーバーの最新案内を確認してください。

出典: XServer「sv8345サーバーのDDoS攻撃によるアクセス障害」、XServer「sv16202サーバーのアクセスフィルタリング」

XServerで自分のサーバー番号を確認する方法

対象判定に必要なのは、ドメイン名ではなく契約中のサーバー番号またはホスト名です。複数契約がある場合は、障害が起きたドメインを収容している契約を選びます。

• XServerアカウントへログインし、「契約情報」でサーバー番号を見る
• サーバーパネルへログインし、「アカウント > サーバー情報」を開く
• ホスト名がsv***.xserver.jpの形で表示されているか確認する
• 障害情報の対象番号と一字ずつ照合する
• 番号、確認日時、対象ドメインを運用台帳へ保存する

ログインできない場合でも、過去の契約メールや保守会社の台帳に番号が残っていることがあります。ただし、メールに書かれたリンクからログインせず、ブックマークや公式サイトからアカウント画面を開いてください。

公式を装う連絡か判断しにくい場合は、フィッシングメールの見分け方も確認すると、障害対応中の焦りによる誤操作を減らせます。

出典: XServerよくある質問「新サーバーの移行メンテナンス」内「利用しているサーバーの番号はどのように確認すればいいですか?」

XServerのDDoS攻撃でサイトにつながらない時の15分初動

XServerのDDoS攻撃が疑われる最初の15分は、復旧作業より事実を保存して対象を切り分ける時間にします。原因がまだ分からない段階で設定を変えると、事業者側の復旧後にも自社変更の影響が残りかねません。

• エラー画面、発生時刻、確認URLを保存する
• シークレットウィンドウと別端末で同じ症状か確認する
• Wi-Fiとモバイル回線を切り替え、アクセス元による差を確認する
• sv番号と公式障害情報の対象・時間を照合する
• 対象が一致したら設定変更を止め、責任者と保守担当へ共有する
• 問い合わせ、予約、注文に影響するなら別系統の窓口を案内する

Wi-Fiでは開けずモバイル回線では開けるなら、一部環境のフィルタリング、回線、DNSの差が手掛かりになります。一つの端末だけで「復旧していない」「完全に直った」と判定しないことが肝心です。

問い合わせフォームが止まっている場合は、SNS、電話、外部フォームなど、サイトと別系統の連絡先を告知します。サイト内だけへ障害案内を置いても閲覧できないため、代替窓口は平時から決めておく必要があります。

障害中にやらない方がよい変更

対象sv番号と時間が一致した障害では、WordPressプラグイン、DNS、SSLを一度に変更しないでください。変更点が増えるほど、復旧後に残った不具合の原因を追いにくくなります。

DDoSは大量の通信でサービスを利用しづらくする攻撃であり、それだけでサイト内データが盗まれた、WordPressが改ざんされたとは判断できません。
ただし、不審な管理者ユーザー、身に覚えのないファイル、改ざん表示が別に見つかった場合は、今回の可用性障害と分けて侵入調査を行います。

WordPress側の不審な変更を確認する観点は、WordPress脆弱性wp2shellの確認手順も参考になります。障害情報だけを根拠に侵入と決めつけず、別の兆候があるかを確認してください。

アカウント保護を見直す場合も、障害対応と同時に多くの設定を変えず、復旧確認後に順序立てて進めます。SMS認証の設定と注意点を確認し、ログイン情報を他人へ送らずに済む運用へ整えてください。

XServerのDDoS攻撃から復旧した後の確認順

公式障害情報が「復旧」になっても、トップページが開いた時点で作業を終えないようにします。サイトの目的に沿って、表示、送信、予約・注文、通知まで確認して初めて業務上の復旧と判断できます。

• 表示: トップページ、主要下層ページ、画像、CSS、管理画面を確認する
• フォーム: テスト送信し、受付画面と受信メールまで確認する
• 予約・注文: カート、決済直前、予約枠、完了通知を確認する
• メール: 送信と受信を別アドレスで確認する
• SSL: 警告の有無と、有効化・更新操作が必要かを確認する

メールソフトで再認証や設定確認が必要になった場合は、メールパスワード変更後に確認する設定も利用できます。表示復旧とメール復旧を同じものとして扱わないことがポイントです。

確認結果は「発生時刻、公式の対象、復旧時刻、顧客影響、代替対応、復旧後テスト」に分けて残します。次回の初動を早くするには、復旧した事実より、どこで判断に迷ったかまで書くと役立ちます。

XServerのDDoS攻撃に平時から備える

DDoS攻撃に備えるなら、障害が起きてから製品を探すより、監視、連絡、代替、技術対策の役割を平時に分ける方が実務的です。共有サーバー上流の通信制御はホスティング事業者側の領域ですが、自社には顧客対応と復旧確認の役割があります。

• sv番号、契約名、保守担当をドメインごとに台帳化する
• 外部監視の通知先を複数人に設定する
• エラー画面、ログ、時刻を保存する場所を決める
• サイト外の告知手段と代替窓口を用意する
• CDN、WAF、専用対策サービスの適否を構成変更前に検討する
• 対応手順と緊急連絡先を定期的に見直す

内閣サイバーセキュリティセンターはDDoS対策として、通信制御、CDN、WAF、専用対策サービス、設定見直し、ソフトウェア更新などを挙げています。ただし、一つの対策だけであらゆる攻撃を防げるわけではありません。

出典: 内閣サイバーセキュリティセンター「DDoS攻撃への対策について(注意喚起)」(2025年2月4日・現在は国家サイバー統括室サイトで公開)

CDNやWAFの導入は、DNS、キャッシュ、管理責任、費用、正常な通信への影響を含めて設計します。障害発生中に初めて切り替えるのではなく、平時に試験と戻し方を決めるのが安全です。

保守会社へ依頼する範囲を曖昧にしないため、ホームページ保守に含める作業と緊急対応の範囲を参考に、監視、一次連絡、復旧確認、顧客案内の担当を決めておきましょう。

出典: JPCERT/CC「Webサイトへのサイバー攻撃に備えて」

復旧後も原因の切り分けや再発準備を自社だけで整理しにくい場合は、ノーサイドへご相談ください。ログイン情報は送らず、対象ドメイン、sv番号、発生時刻、エラー画面、公式URL、業務影響をそろえると確認を始めやすくなります。

よくある質問

対応手順のまとめ

XServerのDDoS攻撃でサイトにつながらない時は、自分のsv番号、公式の対象、発生時刻を最初に照合します。一致したら原因と無関係な設定変更を止め、公式更新、代替窓口、復旧後テストへ進んでください。