WP Umbrellaが管理画面で403になる原因と解決法
WP Umbrellaが管理画面へ送る内部リクエストが一部のレンタルサーバーで403エラーになるのは、Refererヘッダーが欠けているためだ。mu-pluginでヘッダーを付与すると一時的に解決でき、修正版への更新で恒久的に直る。
WP Umbrellaの403エラーはリクエストヘッダー不足が原因
WP Umbrellaは監視・管理のため、WordPressのadmin-ajax.phpへ内部リクエストを送っている。このバックグラウンド通信にはUser-Agentとして「WPUmbrella」が使われ、CookieもRefererも含まれない。多くのホスティングはこのリクエストを許可するが、セキュリティ規則が厳しい環境では「403 Forbidden（アクセス拒否）」を返す。
ホスト側のWAFやmod_securityは、CookieやRefererのないPOSTリクエストを不正アクセスと判断することがある。特に/wp-admin/配下への直接POSTは警戒されやすい。結果としてWP Umbrellaのダッシュボードにプラグインの更新情報が一部表示されない、サイトの監視データが欠けるといった影響が出る。
ヘッダーにRefererなし、Cookieなし。WAFがブロックする。
Refererヘッダーを追加するとサーバーが受け付ける。
上のデモは、WP Umbrellaの内部リクエストがRefererの有無でどう変わるかを示している。403はサイトの表示を壊さないが、管理画面側で更新データの取得漏れが起きる。
mu-pluginでRefererヘッダーを追加する手順
プラグインの修正版が配布されるまでの間は、mu-plugin（マスタードロップイン）でWP UmbrellaのリクエストにRefererヘッダーを自動付与するのが確実だ。mu-pluginは/wp-content/mu-plugins/に置くPHPファイルで、管理画面から無効化できない代わりに毎回確実に読み込まれる。
ファイル名は任意でよいが、add-referer-for-wp-umbrella.phpのように役割が分かる名前が管理しやすい。
<?php
/**
* WP Umbrella の内部リクエストに Referer ヘッダーを付与する
*/
add_filter( 'http_request_args', function ( $args, $url ) {
if ( 'WPUmbrella' === ( $args['user-agent'] ?? '' )
&& 0 === strpos( $url, admin_url() )
&& empty( $args['headers']['Referer'] ) ) {
$args['headers'] = (array) ( $args['headers'] ?? array() );
$args['headers']['Referer'] = admin_url();
}
return $args;
}, 10, 2 );このコードが何をしているのか
http_request_argsフィルタは、WordPressがHTTPリクエストを送る直前に引数を書き換えられるフックだ。ここではUser-Agentが「WPUmbrella」であること、リクエスト先が管理画面のURLであること、Refererが未設定であることの3条件が揃った場合だけ、管理画面URLをRefererとして追加している。
条件を限定しているため、WP Umbrella以外の通信には影響しない。WP Umbrella側のリクエスト検証にも変更はない。修正版に更新した後はこのmu-pluginを削除して問題ない。
プラグインのアップデートで恒久的に解決する
この問題はWP Umbrellaの開発チームが把握しており、次期リリースで内部リクエストのUser-AgentとRefererが修正されることが発表されている。具体的には、User-Agentが「WordPress/」で始まる文字列になり、Refererに管理画面URLが付与される。
WordPress管理画面の「プラグイン」→「インストール済みプラグイン」でWP Umbrellaの更新通知が表示されたら、通常どおり更新する。更新後は403になる頻度がなくなり、mu-pluginの応急処置は不要になる。更新が配布されていない間は、mu-pluginを置いたまま運用してかまわない。
同じ403が別のプラグインでも出た場合の切り分け
Refererヘッダー不足による403は、WP Umbrella以外の監視・バックアップ・API連携系プラグインでも起こり得る。原因を切り分けるには、まず該当プラグインが管理画面のadmin-ajax.phpへPOSTを送っているかをエラーログやプラグインの仕様で確認する。
特定のプラグインだけが403になる場合は、ホスティングのWAF設定を緩める前に、mu-pluginで当該プラグインのリクエストだけにRefererを追加できないか検討する。WAF全体を無効化するとサイトの防御力が下がるため、最終手段として扱う。
原因がプラグインの実装にある場合は、開発元にフォーラムやサポートから報告すると、今回のようにプラグイン本体で修正される可能性が高い。
よくある質問
403エラーが出てもサイト表示には影響あるか
このケースではサイトの表示や一般ユーザーの操作には影響しない。WP Umbrellaのバックグラウンド通信だけが拒否されるため、ダッシュボード上の更新情報取得や監視データの一部が欠ける形になる。
mu-pluginフォルダが見つからない場合はどうするか
/wp-content/の直下にmu-pluginsフォルダがない場合は、自分で新規作成すればよい。フォルダ名は必ずmu-pluginsにする。その中にPHPファイルを直接置くとWordPressが自動で読み込む。
このmu-pluginはWP Umbrella以外に影響を与えるか
影響しない。コード内でUser-Agentとリクエスト先を限定しているため、WP Umbrellaの管理画面への内部通信だけにRefererを追加する。他のプラグインのHTTP通信には触れない。
プラグイン更新後にmu-pluginは削除すべきか
修正版WP Umbrellaに更新したらmu-pluginは不要になるので、削除してよい。残していても通常は害がないが、意図しない通信パラメータの重複を避けるため削除するのが綺麗だ。
403の原因がWP Umbrella以外だった場合の確認ポイントは何か
全プラグインを無効化して1つずつ再有効化し、どのプラグインで403が再発するかを確認する。テーマを標準テーマに切り替える方法も有効だ。サーバーのWAFログやPHPエラーログも手がかりになる。
この記事のポイント
- WP Umbrellaの内部リクエストがReferer不足で403になる
- mu-pluginでRefererを付与すると応急処置できる
- 開発元が修正した次期リリースで恒久解決する
- サイト表示への影響はなく、管理データの取得漏れが起きる
- 同様の403は他プラグインでもWAF設定の見直しで対処する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている