はじめに
このブログはAWS LightsailのWordPress（bitnami）で動かしているのですが、先日SiteGuardを導入してログインURL変更を有効にしたところ、管理画面にアクセスできなくなってしまいました。
原因を調べていくと「Apacheの設定ファイルの優先順位」という、知らないとかなりハマるポイントでした。 同じ環境で詰まっている方の参考になればと思い、切り分けの流れと解決方法をまとめておきます。
発生した事象
状況はこんな感じ。
- SiteGuardでログインURL変更をON
- 変更後のURLにアクセスすると「404」
- 元の
/wp-login.phpにアクセスしても「404」 - フロントサイトは正常に表示されている
管理画面が完全に詰まった状態です。
切り分けの流れ
① プラグイン無効化で復旧を試みる
まずプラグインフォルダをリネームして全プラグインを無効化します。
bash
mv wp-content/plugins wp-content/plugins_backup→ 管理画面に入れるようになった。プラグイン起因と確定。
② mod_rewriteの確認
.htaccess の RewriteRule が動かない可能性があるので、まずモジュールが有効かを確認します。
bash
/opt/bitnami/apache2/bin/apachectl -M | grep rewrite→ rewrite_module が表示されたのでモジュール自体はOK。
③ AllowOverrideの確認
httpd.conf や bitnami.conf を見ると AllowOverride All になっていた。 なので .htaccess は有効なはず……
④ .htaccessのRewriteRuleを確認
SiteGuardが書いた .htaccess を確認すると、
RewriteRule ^login-xxxx$ wp-login.php [L]ルール自体は存在している。なのになぜ動かない？
⑤ RewriteRuleが本当に動いているかをテストする
本当に .htaccess が効いているかを確認するために、わかりやすいリダイレクトルールを追記してテストしました。
RewriteRule ^abc$ https://google.com [R=302,L]/abc にアクセスしてもGoogleに飛ばない。
👉 ここで .htaccess が完全に無視されていることが判明。
⑥ Apacheの設定ファイルを確認する
実際にApacheがどの設定ファイルを読んでいるかを確認します。
bash
/opt/bitnami/apache2/bin/apachectl -Sここで出てきた設定ファイルを見ていくと、原因が分かりました。
原因
最終的な原因はこれでした。
VirtualHost設定（vhosts）が優先されており、その中で
.htaccessが無効化されていた
具体的には以下のファイルが使われていました：
/opt/bitnami/apache/conf/vhosts/wordpress-vhost.conf/opt/bitnami/apache/conf/vhosts/wordpress-https-vhost.conf
この中に AllowOverride None が設定されており、.htaccess のRewriteRuleが一切動いていませんでした。 httpd.conf や bitnami.conf を直しても意味がない状態だったわけです。
解決方法
vhostの設定ファイルを修正します。
bash
sudo vi /opt/bitnami/apache/conf/vhosts/wordpress-vhost.conf
sudo vi /opt/bitnami/apache/conf/vhosts/wordpress-https-vhost.conf以下のように変更：
apache
DocumentRoot "/opt/bitnami/wordpress"
<Directory "/opt/bitnami/wordpress">
AllowOverride All
Require all granted
</Directory>その後Apacheを再起動：
bash
sudo /opt/bitnami/ctlscript.sh restart apache動作確認
.htaccess に先ほどのテスト用ルールを追加して確認します。
RewriteRule ^abc$ https://google.com [R=302,L]/abc にアクセスしてGoogleへリダイレクトされればOK。
なぜこういう構造になっているのか
bitnami環境ではApacheの設定が複数ファイルに分散されており、以下のような構造になっています。
httpd.conf（親）
├ bitnami.conf
└ vhosts/
├ wordpress-vhost.conf ← ★今回の本丸
└ wordpress-https-vhost.conf ← ★今回の本丸VirtualHostの設定が最終的に優先して適用されます。 なので bitnami.conf や httpd.conf をどれだけ修正しても、vhostで上書きされてしまうケースがあります。
apachectl -S で実際に読み込まれている設定を確認するのが一番の近道でした。
まとめ
今回のポイントはこの3つ。
.htaccessが効かない場合は「Apacheが実際に見ているファイル」を疑うapachectl -Sで読み込まれている設定を確認するのが最重要- bitnami環境では vhost設定が最優先
おまけ：再発防止のために
- SiteGuardのログインURL変更は、環境をちゃんと把握してから有効にする
- 設定変更の前にSSHでサーバーに戻れる状態を確保しておく
- bitnamiのApache設定構造はあらかじめ把握しておくと後々ラク
終わりに
「設定ファイルは正しいのに動かない」系のトラブルは、原因にたどり着くまでに時間がかかって地味に消耗します。
今回のケースは “どの設定が最終的に適用されているか” を確認することで解決できました。 同じところでハマっている方の役に立てれば幸いです。
コメント