【WordPressの管理画面が403になる】プラグインを消す前にWAFで確認する3つのこと
WordPress管理画面で保存時に403が出たとき、最初にプラグインを削除したり、WordPressを入れ直したりしません。どの画面で、どんな入力を保存したときに起きたかを残し、レンタルサーバーのWAFがその通信を止めていないかを確認します。特に広告タグや埋め込みコードのように<script>を含む入力は、WAFに止められる場合があります。
この記事は、ログイン自体はできるのに、投稿・設定・広告タグなどの保存時だけ403になる人向けです。403の原因はWAFだけではありません。WAFを一時的に操作する場合も、作業後に有効へ戻すことを前提にし、設定変更は一つずつ行います。
1. 403になった操作を、そのまま記録する
最初に、403が出た操作を短く記録します。たとえば「記事本文だけは保存できるが、広告タグを入れたカスタムHTMLブロックで保存できない」「テーマ設定で特定の入力を保存したときだけ出る」といった差が重要です。
次を残すと切り分けやすくなります。
- 保存した画面と時刻
- 入力にHTML・JavaScript・外部URLが含まれていたか
- 同じ内容を外したら保存できるか
- 画面に出た403以外のエラー文
この記録がないままプラグインを無効化すると、入力内容による問題か、プラグインによる問題か、サーバー側の防御による問題かを判別しづらくなります。
2. サーバーのWAF設定と反映時間を確認する
WAFは、疑わしい通信を防ぐためのサーバー側の機能です。保存したい内容が攻撃に見えると、WordPressやプラグインが壊れていなくても403が返ることがあります。契約しているサーバーの管理画面で、WAFが有効か、除外設定があるか、変更の反映に時間がかかるかを公式マニュアルで確認します。
ナラビカのロリポップ運用では、<script>を含む広告タグの保存が403で止まったことがあります。作業中だけWAFを無効にして保存し、直後に有効へ戻す運用をしています。これはこのサイトで確認した体験であり、すべてのWordPress環境や入力で同じ結果になるという意味ではありません。
設定の反映には時間差があります。ナラビカの運用では、WAFの設定を変更してから反映されるまでに5〜10分程度かかり、その間は同じ操作をしても403になったり通ったりすることがありました。サーバーが複数のノードで動いている場合、設定が行き渡るタイミングにずれが出るためと考えられます。設定を変えた直後に一度成功・失敗しただけで判断せず、数分置いてからもう一度試すと、原因の切り分けがしやすくなります。
エックスサーバーでは、公式マニュアルでWAFの設定変更が反映されるまで最大30分程度かかると案内されています。設定を変えた直後に一度失敗しただけで、別の原因と決めないようにします。サーバーにより操作場所や反映時間が違うため、他社の手順をそのまま使いません。
なお、<script>タグを含む入力以外にも同様の403が起きるパターンがあるかどうかは、ナラビカの運用では確認できていません。他の記号や書き方で同じ現象が起きるかどうかは、契約しているサーバーの公式マニュアルやサポートへの確認をおすすめします。
3. 保存できたあとに、表示とキャッシュを分けて確認する
保存が通ったあとに画面へ反映されない場合は、403とは別にキャッシュが残っている可能性があります。編集画面で保存できたか、公開ページをシークレットウィンドウなどで見たときにも反映されているか、キャッシュプラグイン・サーバーキャッシュのパージが必要かを順に確認します。
ナラビカの運用では、キャッシュプラグイン(LiteSpeed Cache)のキャッシュ保持期間を7日に設定しています。保存や設定変更をした直後にキャッシュのパージを忘れると、「広告が反映されない」など、直したはずなのに画面に出ない状態が2度起きました。これは403とは別の原因なので、まず保存自体が成功しているかを確認し、そのうえで表示側の問題であればキャッシュのパージを試すという順番が有効です。契約しているキャッシュプラグイン・サーバーキャッシュの保持期間は、それぞれの管理画面や公式マニュアルで確認できます。
WAFを下げたまま「表示されない原因」を調べ始めないことも大切です。保存後はWAFを戻し、表示の問題はキャッシュやテンプレートとして別に切り分けます。セキュリティ機能を止めた時間を短くすると、作業を再現しやすくなります。
サーバーを契約する前の比較が必要な場合は、エックスサーバーとロリポップのWAF比較で、公式に確認できる初期状態・反映時間と、ナラビカ運用で起きたことを分けて確認してください。
WordPress側の403とサーバー側の403を見分ける
403にも、WordPress自身が出しているものと、サーバー側のWAFが手前で止めているものの2種類があります。次の点を見ると、どちらに近いかの見当がつきます。
- 画面の見た目: WordPress側のエラー(権限不足や入力チェックなど)は、管理画面のメニューやアドミンバーが表示されたまま、画面内にエラーメッセージが出ることが多くなります。一方、サーバー側のWAFで止められた場合は、管理画面のデザインごと消え、簡素な「403 Forbidden」のページに切り替わることが多くなります。
- レスポンスの中身: ブラウザの開発者ツールでNetworkタブを開いたまま保存操作を行うと、保存リクエストのレスポンスを確認できます。WordPress側のエラーであれば、レスポンスの中にWordPress自身が組み立てたHTML(管理画面の一部)が含まれます。WAFで止められた場合は、WordPressのコードが実行される前に通信自体が止まっているため、サーバーソフトウェア(Apache・nginx・LiteSpeedなど)が返す簡素なエラーページが返ってくることが多く、WordPressらしい要素がほとんど含まれません。
- 再現性: 保存する内容の一部(たとえば
<script>タグ)を外して同じ操作をしたときに保存できるなら、内容そのものが引っかかっている可能性が高くなります。内容を変えても直らない、あるいは同じ内容でも成功したり失敗したりするなら、前の項目で触れた「設定反映中の混在」も候補に入ります。
いずれも100%当てはまるわけではなく、見分ける手がかりです。契約しているサーバーの公式マニュアルにWAFのログ機能があれば、そちらで403の理由を直接確認できる場合もあります。
WAFを無効にする以外にできること
WAFを一時的に無効化すれば保存自体は通ることが多いですが、その間はサイト全体が防御の外に出るため、常用する対処ではありません。無効化する前に、次を確認する価値があります。
- 保存する内容そのものを変えられないか(外部サービスが発行するタグに、
<script>を含まない形式が用意されている場合があります) - 契約しているサーバーに、特定のURLやIPだけWAFの対象から外せる除外設定があるか
- サーバーのサポート窓口に、該当の通信がWAFのどのルールで止められたかを問い合わせられるか
これらを確認したうえで難しい場合に、必要な時間だけ無効化し、作業後は速やかに有効へ戻すという順番が安全です。
まとめ
保存時の403は、最初に入力内容と時刻を残し、WordPress側のエラーかサーバー側のWAFかを見分けたうえで、WAFの状態を確認します。広告タグなど特定の入力だけで起きるなら、WordPressを壊れたものとして扱う前に、サーバー側の防御機能を疑う価値があります。
一時的にWAFを操作する場合は、保存後に有効へ戻し、反映しない問題はキャッシュとして別に確認します。設定の反映には数分から数十分の幅があることも踏まえておくと、この順番なら、設定を大きく壊さず原因を追えます。