タグアーカイブ MultiViews

SiteGuard WP Pluginでwp-loginが表示される原因とMultiViewsの無効化手順

なぜ /wp-login/ でログイン画面が表示されてしまうのか

この現象は SiteGuard WP Plugin の仕様ではなく、サーバー環境に由来する問題だ。Apache の MultiViews 機能が有効になっていると、/wp-login/ へのアクセスが内部的に /wp-login.php にマッチしてしまい、ログイン画面が表示される。

MultiViews は Apache のコンテンツネゴシエーション機能の一部で、リクエストされたパスに拡張子がない場合に、サーバー側で適切なファイルを探し出して提供する仕組みだ。/wp-login（もしくは末尾スラッシュ付きの /wp-login/）を要求すると、Apache は wp-login.php という実ファイルを見つけて実行してしまう。これが根本の原因であり、ログインページ変更機能で隠しパラメータを追加しても、このフィルタをすり抜けてしまうケースが生まれていた。

実際に WordPress.org フォーラムで報告され、プラグイン開発者によってバージョン 1.8.4 で対策が施された。しかし /wp-login/任意の文字列（例：/wp-login/test）に対しては、引き続き MultiViews の影響でログイン画面が表示される可能性が残っている。完全に防ぐには、Apache 側で MultiViews を無効化する必要がある。

このデモは MultiViews の有無によるアクセス結果の変化を示している。

SiteGuard WP Plugin 側の対策と残る課題

バージョン 1.8.4 で /wp-login/ はブロック対象に

SiteGuard WP Plugin 1.8.4 では、内部的に /wp-login/ へのアクセスを捕捉し、ログインページ変更機能で指定した独自 URL 以外からのアクセスをブロックする処理が追加された。これにより、多くの環境で「/wp-login/」を直接叩かれてもログイン画面が表示されなくなった。

/wp-login/任意の文字列 は依然としてすり抜ける

しかし URL の末尾にさらにパスを付け足した /wp-login/something のようなアクセスは、プラグイン側の正規表現やルールでは補足しきれず、Apache の MultiViews がマッチする限りログインページを返してしまう。これはプラグインのバグというより、Web サーバーのモジュールが優先してしまう構造的な問題だ。

Apache で MultiViews を無効化する手順

最も確実な対策は、Apache の設定で MultiViews を無効にすることだ。レンタルサーバーを利用している場合でも、.htaccess ファイルで制御できるケースが多い。

この手順により、Apache が MultiViews を使ったファイルの自動解決を行わなくなり、/wp-login/ や /wp-login/何らかのパス へのアクセスでログイン画面が表示されることはなくなる。

.htaccess の記述例

WordPress の標準的な .htaccess に組み込む場合は、以下のような形になる。Options -MultiViews はリライトルールよりも手前に書くのがセオリーだ。

# BEGIN WordPress
Options -MultiViews

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

MultiViews 無効化ができない場合の代替策

レンタルサーバーの制限で Options -MultiViews が許可されていない環境もまれにある。その場合は、より直接的なリダイレクトルールを追加して、/wp-login/ へのアクセスを 404 ページやトップページに飛ばす方法がある。

RewriteRule ^wp-login/ - [R=404,L]

このルールを .htaccess の RewriteEngine On の直後に追記すれば、/wp-login/ というパスで始まるリクエストすべてを 404 で返す。ただしリライトの優先順位によっては、他のルールと競合しないか必ずテストすること。

404 ページをブラウザ標準から WordPress テーマのものに切り替える

質問の中で「ブラウザ標準の 404 ページではなく、WordPress テーマ側の 404 ページに遷移させたい」という要望があった。SiteGuard WP Plugin 1.7.x 系では、ログインページ変更機能が動作すると WordPress の 404 テンプレートを表示する挙動だった。これが 1.8.x 系で Apache の標準エラー応答に変わったのは、プラグインの内部ロジックがより低レイヤーでリクエストを遮断するように再設計されたためだ。

WordPress テーマの 404 ページを表示させたい場合は、プラグイン任せにせず、Apache の ErrorDocument ディレクティブを利用する方法がある。ただし完全に同一の外観を保つのは難しく、セキュリティ上の観点からも、404 ページの表示にこだわるよりも「不正なアクセスをいかに早く遮断するか」に注力したほうが実用的だ。

よくある質問

SiteGuard WP Plugin のログインページ変更だけでは不十分なのか

ログインページ変更機能は、ボットによる辞書攻撃や自動スキャンの大半を防ぐ効果がある。しかしサーバー側の MultiViews のような特殊な設定が残っていると、その穴を突かれる可能性がゼロではない。基本はプラグイン任せ、より強固にしたい場合は MultiViews の無効化を組み合わせるのが現実的な落としどころだ。

MultiViews を無効にすると他の機能に影響はあるか

WordPress は基本、PHP ファイルを直接呼び出すスタイルで動作しているため、通常の運用で MultiViews が必須になることはほぼない。静的ファイルの MIME タイプや言語ネゴシエーションを使っている特殊なカスタマイズがなければ、影響は出ないと考えてよい。

Nginx 環境でも同じことは起きるのか

Nginx には Apache の MultiViews に相当する機能は標準で存在しないため、この問題は発生しない。Nginx の場合は try_files ディレクティブの設定ミスによって似た現象が起こることがあるが、原因はまったく異なる。

プラグインを最新にしたのに管理画面が 404 になることがある

SiteGuard WP Plugin の「管理ページアクセス制限」を有効にしていると、未ログイン状態で /wp-admin/ にアクセスするとサイトトップにリダイレクトされる。また「管理者ページからログインページへリダイレクトしない」設定を ON にしている場合のリダイレクト先も確認しておくと混乱が少ない。

この記事のポイント

• /wp-login/ からのログイン画面表示は MultiViews が原因
• SiteGuard WP Plugin 1.8.4 で基本対策は完了している
• 根本解決には Apache の MultiViews 無効化が必要
• .htaccess に Options -MultiViews を追加するだけで対処可能
• 404 表示にこだわるより、アクセス遮断の仕組みを優先する

佐々木 太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている