WordPressを駆除したのにリダイレクトが残る？CDN・キャッシュ・Service Workerの確認

「WordPressのマルウェアを駆除したはずなのに、特定の端末だけ知らないサイトへ飛ぶ」「サーバー上の不正コードは消えたのに、転送が止まらない」と困っていませんか？

駆除後に残るリダイレクトは、再感染とは限りません。
CDN、サーバーキャッシュ、ブラウザキャッシュ、Service Workerが、以前の転送レスポンスや不正な応答を保持している場合があります。

ただし「キャッシュのせい」と決めつけるのも危険です。
まず発生場所を切り分け、配信元に不正処理が残っていないと確認してから、外側のキャッシュを順番に消す必要があります。

よこやま良平

WordPressの復旧を多数手がけてきたよこやま良平です。わたしの現場経験をもとに、駆除後も残るリダイレクトを、配信元・CDN・ブラウザ・Service Workerの順で安全に確認する方法を解説します。

結論から言うと、駆除後のリダイレクトは「配信元の応答」「サーバー・WordPress」「CDN」「ブラウザ・Service Worker」の順で調べます。
内側から外側へ確認すれば、原因を隠さず、必要な範囲だけを安全に更新できます。

全キャッシュ削除や設定変更を先に行わず、まず転送の発生条件とHTTP応答を記録しましょう。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

WordPress駆除後のリダイレクトは発生する層を切り分ける

WordPressを駆除した後もリダイレクトが残る時は、最初に「どの層が転送を返しているか」を切り分けることが重要です。

同じURLでも、訪問者へ届くまでにはWordPress、Webサーバー、サーバーキャッシュ、CDN、ブラウザ、Service Workerという複数の経路があります。
一つの層だけ直しても、別の層が古い応答を返せば症状は続きます。

別端末・別回線・未ログイン状態で再現条件を記録する

まず、パソコンとスマートフォン、通常ウィンドウとシークレットウィンドウ、Wi-Fiとモバイル回線で同じURLを開きます。
Google検索から開いた時だけ、初回だけ、特定ページだけなど、条件ごとの差を記録してください。

一つのブラウザプロファイルだけで発生し、別端末では正常なら、ブラウザキャッシュやService Workerの可能性が上がります。
反対に、新しい端末と別回線でも同じ転送が起きるなら、配信元、CDN、DNS周辺を優先して調べます。

HTTPの転送応答とJavaScript転送を分けて確認する

HTTPの301・302・307・308で転送される場合は、応答ヘッダーのLocationに転送先が出ます。
一方、最初のHTMLは200でも、その後にJavaScriptやService Workerが別ページへ移動させる場合があります。

ブラウザの開発者ツールでNetworkを開き、Preserve logを有効にしてから再読み込みすると、最初の応答から転送先まで追いやすくなります。
Disable cacheは開発者ツールを開いている間の比較に使い、通常状態の記録も先に残してください。

curl -sS -D - -o /dev/null https://example.com/
curl -sS -L -D - -o /dev/null https://example.com/

1行目は最初の応答を確認し、2行目は転送を追跡します。
ただし、端末・Cookie・参照元・User-Agentで条件分岐する攻撃は、単純なcurlでは再現しないことがあります。

キャッシュ削除の前に応答ヘッダーとログを保存する

キャッシュを消す前に、応答ヘッダー、転送先、CDNのキャッシュ状態、アクセスログを保存してください。
先に全消去すると「どこが古い応答を返したのか」という手がかりまで失います。

Age、Cache-Control、Via、X-Cache、CDN固有のキャッシュヘッダーは判断材料になります。
ただしヘッダー名や意味はサービスごとに異なるため、値だけで感染・安全を断定してはいけません。

クイックレスキュー

リダイレクトハッキング対策5ステップ｜原因・確認・復旧方法

WordPress駆除後のCDNキャッシュとエッジ設定を確認する

配信元が正常なのに外部アクセスだけ転送される場合は、CDNのキャッシュ、リダイレクトルール、エッジ処理を確認します。

CDNは画像やCSSだけでなく、設定によってHTMLや転送応答を保持することがあります。
また、ページルール、リダイレクトルール、エッジ関数、Workers相当の処理が、WordPressへ到達する前に転送を返す構成もあります。

CDN経由とオリジンサーバーの応答を比較する

確認の要点は、CDN経由の応答とオリジンサーバーの応答を同じ条件で比較することです。
オリジンが200でCDN経由だけ3xxなら、CDNキャッシュまたはエッジルールが疑われます。

ただし、オリジンへ直接アクセスする方法を誤ると、SSL証明書、Hostヘッダー、仮想ホストの違いで別サイトを見てしまいます。
サーバー会社やCDNが案内するプレビュー機能、検証用ホスト名、正しいHostを保つ方法を使ってください。

CDNは対象URLから消し、全消去は必要性を判断する

原因となるURLが限定できるなら、最初は対象URL単位でパージするのが安全です。
全キャッシュ消去は広範囲へ反映しますが、一時的にオリジンサーバーへのアクセスが集中し、表示速度や負荷へ影響することがあります。

不正な転送ルールやエッジ処理が残っている場合、キャッシュだけ消しても次のアクセスで同じ応答が再生成されます。
ルールの作成者、変更日時、対象パターンを記録し、正規設定と確認してから停止・修正してください。

わたしの実務では、パージ時刻と次に不正転送が出た時刻を並べると、古いキャッシュか再生成かを判断しやすくなります。

CDNアカウントの侵害と設定の戻りも確認する

WordPressを駆除しても、CDNアカウントやDNS管理アカウントが侵害されたままなら、外側から転送を再設定される可能性があります。
不要なユーザー、APIトークン、連携アプリを確認し、管理者の認証情報と二要素認証を見直してください。

設定を変更する前には、現在のルールと監査ログを保存します。
正規の運用担当者や制作会社が使う自動設定もあるため、不明なルールを名前だけで削除しないことが大切です。

クイックレスキュー

WordPressが乗っ取られた時に最初にやること｜被害拡大を防ぐ初動対応

WordPressとサーバーキャッシュに残るリダイレクトを確認する

CDNを消す前後でオリジンも転送を返すなら、WordPress、Webサーバー、サーバーキャッシュの順で原因を確認します。

WordPressのキャッシュプラグインだけでなく、レンタルサーバーの高速化機能、NginxやVarnishなどのリバースプロキシ、PHPのOPcacheが関係する場合があります。
名称が「キャッシュ」でなくても、HTMLを静的保存する機能は調査対象です。

WordPressキャッシュプラグインの保存先と除外設定を見る

キャッシュプラグインでは、対象URLのページキャッシュ、モバイル別キャッシュ、ログイン状態別キャッシュを確認します。
削除ボタンを押す前に、使用中のプラグイン名、設定画面、保存先、除外URLを記録してください。

プラグインを停止しただけでは、生成済みの静的HTMLやドロップインが残る製品もあります。
wp-content/cache、advanced-cache.php、object-cache.phpなどは正規プラグインでも使うため、由来を確認せず削除してはいけません。

サーバー側キャッシュとリダイレクト設定を分ける

サーバー管理画面にページキャッシュやアクセラレータがある場合は、対象ドメイン、対象URL、TTL、除外条件を確認します。
同時に、.htaccess、Nginx設定、ホスティング側の転送設定に意図しないルールが残っていないか調べます。

キャッシュは「過去の応答を返す仕組み」であり、リダイレクト設定は「新しい転送を生成する仕組み」です。
前者だけ消しても後者が残れば再発するため、必ず分けて確認してください。

データベースとファイルの再検査を省略しない

キャッシュを消して一時的に直っても、WordPress内部が安全とは限りません。
テーマ、プラグイン、mu-plugins、uploads内の実行ファイル、データベースのURLやJavaScript、不審ユーザー、Cronを再確認します。

クリーンな公式ファイルや信頼できるバックアップと比較し、駆除後に更新された場所を確認してください。
スキャン結果だけで完了とせず、転送を生成した経路が説明できる状態を目指します。

クイックレスキュー

WordPressマルウェア駆除の完全手順｜感染確認から復旧・再発防止まで【2026年版】

クイックレスキュー

バックドアは動作してなくても消すべき？放置リスクを解説

WordPress駆除後のブラウザキャッシュとService Workerを確認する

サーバーとCDNが正常で、一部のブラウザだけリダイレクトする場合は、ブラウザキャッシュ、サイトデータ、Service Workerを確認します。

Service Workerは、Webページとは別にブラウザ内で動き、ネットワークリクエストを処理できる仕組みです。
正規のPWAやオフライン表示にも使われるため、登録があるだけでマルウェアと断定してはいけません。

新しいブラウザプロファイルで端末固有かを確かめる

同じ端末でも、新しいブラウザプロファイルやゲストモードで正常なら、通常プロファイル内の保存状態が関係している可能性があります。
シークレットモードでも拡張機能やポリシーの影響が残る場合があるため、一つの結果だけで決めつけません。

別端末、別ブラウザ、新規プロファイル、通常プロファイルを表にして比較すると、影響範囲が見えます。
会社管理の端末では、ブラウザポリシーやセキュリティソフトが設定を配布していることも確認してください。

Service Workerの登録範囲と更新元を確認する

Chrome系ブラウザでは開発者ツールのApplicationからService Workersを確認できます。
スクリプトURL、Scope、状態、更新時刻を記録し、現在のサイト構成で必要な登録かを確認してください。

登録解除の前にスクリプトURLと内容を保存します。
Service Workerを解除しても、そのページを開いたままでは古い制御が残ることがあるため、タブを閉じて再度開き、登録状態を確認します。

Service Workerの解除は登録解除の要求です。現在実行中の処理が直ちに消えるとは限らないため、再読み込みと登録の再確認を行います。

Cache Storageとサイトデータを影響を理解して消す

ApplicationのCache Storageには、Service Workerが保存したレスポンスが残る場合があります。
対象オリジンを確認し、不審な転送や古いHTMLを保持しているキャッシュ名とURLを記録してから削除します。

「サイトデータを消去」は、キャッシュだけでなくCookie、Local Storage、IndexedDBなども対象にすることがあります。
ログアウト、入力途中データの消失、オフライン機能の初期化が起きるため、利用者へ影響を説明してから実行してください。

WordPressのリダイレクトを安全な順番で停止する

駆除後のリダイレクトを安全に止めるには、証拠保全から始め、内側から外側へ一層ずつ修正します。

順番を飛ばしてブラウザやCDNを全消去すると、一時的に直っても原因が分からず、再発時に同じ調査を繰り返すことになります。
変更時刻と確認結果を一つの記録へまとめてください。

一工程ごとに正常化した場所を記録する

サーバーキャッシュを消した時、CDNをパージした時、Service Workerを解除した時に、それぞれ同じテストを行います。
どの操作で変化したかが分かれば、原因層と再発防止策を結び付けられます。

確認では、ステータスコード、Location、キャッシュ関連ヘッダー、画面の転送先、ログ時刻を記録します。
「直ったように見える」ではなく、以前の不正応答が返らないことを証拠で確認してください。

キャッシュ削除だけで復旧完了にしない

キャッシュ削除は古い応答を捨てる操作であり、侵入口やバックドアを除去する操作ではありません。
不正リダイレクトがあったサイトでは、管理者、サーバー、SFTP、CDN、DNS、メールの認証情報も見直します。

WordPress本体・テーマ・プラグインを更新し、不要なアカウントとAPIトークンを整理します。
同一サーバー内に古いWordPressや別CMSがある場合は、そこから再侵入されないかも確認してください。

クイックレスキュー

WordPressが改ざんされたか確認する方法｜乗っ取り被害を見分けるチェック項目

WordPressのリダイレクト停止後は複数条件で再検証する

リダイレクトが一度止まっても、複数の端末・流入元・時間帯で再検証してから復旧完了と判断します。

条件付き攻撃や長いTTLのキャッシュは、直後の一回だけでは見逃すことがあります。
少なくともPCとスマートフォン、ログイン・未ログイン、直接アクセス・検索経由、初回・再訪を確認してください。

レスポンスと表示をセットで確認する

HTTP応答が200でも、ブラウザ上でJavaScript転送が起きる場合があります。
反対に、正規のHTTPS統一やURL変更で3xxが必要なページもあるため、ステータスコードだけで良否を決めません。

意図した最終URL、正規の転送回数、キャッシュヘッダー、画面表示、主要機能を一組で確認します。
問い合わせフォーム、決済、予約、管理画面、画像アップロードなど、事業に必要な操作も試してください。

パージ後の再発時刻と変更履歴を照合する

数時間後や翌日に再発した場合は、その時刻付近のアクセスログ、ファイル更新、データベース変更、CDN監査ログを照合します。
同じURL・同じルールが戻っていれば、単なる残存キャッシュではなく再投入を疑う材料になります。

監視中は、不正転送が再現しないことに加え、新しい管理者、Cron、APIトークン、ファイル変更がないかも確認します。
再発が見つかったら、キャッシュ削除を繰り返す前に証拠を保存し、侵入経路の調査へ戻ってください。

クイックレスキュー

WordPressマルウェア駆除後にやることは？再感染を防ぐ設定と見直しポイント

WordPress駆除後のリダイレクトに関するよくある質問

駆除後に転送が残った時、判断に迷いやすい点を整理します。

CDNの全キャッシュを消せばリダイレクトは止まりますか？

古い転送応答だけが原因なら止まる可能性があります。ただし、オリジンやエッジルールが不正な転送を生成していれば再びキャッシュされます。先に応答とルールを記録し、対象URLからパージしてください。

Service Workerが登録されていたら感染ですか？

登録だけでは感染と断定できません。PWA、プッシュ通知、オフライン表示など正規機能でも使われます。スクリプトURL、Scope、内容、導入履歴を確認し、サイト運用上の必要性を判断してください。

ブラウザの履歴削除とサイトデータ削除は同じですか？

同じではありません。閲覧履歴だけを消しても、Cache Storage、Cookie、Local Storage、IndexedDB、Service Workerが残る場合があります。削除対象とログアウトなどの影響を確認して実行してください。

キャッシュ削除で直ればマルウェア駆除は完了ですか？

完了とは限りません。キャッシュ削除は保存済み応答を消すだけです。ファイル、データベース、ユーザー、Cron、認証情報、CDN・DNS設定を再確認し、不正な処理が再生成されないことまで確認してください。

WordPress駆除後のリダイレクトは内側から外側へ確認する

WordPressを駆除したのにリダイレクトが残る時は、すぐに再感染と決めつけず、配信元、サーバーキャッシュ、CDN、ブラウザ、Service Workerの順で切り分けます。

一方で、キャッシュのせいと決めつけてはいけません。
パージ後に同じ転送が生成される、不審ファイルや設定が戻る、別端末でも再現する場合は、侵入口や再投入元の調査が必要です。

証拠を残し、一工程ごとに同じ条件で確認し、どの操作で正常化したかを記録してください。
この手順なら、原因を隠さずに転送を止め、再発防止へつなげられます。

駆除後も残るリダイレクトを自分で解決できない時は

WordPress内部を駆除しても不正リダイレクトが止まらない、CDNとブラウザのどこに原因があるか分からない場合は、
クイックレスキューが配信経路を切り分けて復旧します。

キャッシュ削除を繰り返す前に、現在の転送条件と応答をお知らせください。
原因層の特定から駆除後の再検証まで対応します。