WordPressにログインできない！LiteSpeed Web Server「404 Not Found」が表示されたら確認すること

ステージング環境をクライアントを見せたときに起きた404エラー。WordPressで制作したホームページを管理していて、初めて出くわしたので備忘録を残しておきます。

• 管理画面にログインできない
• 自分だけはなぜか見れる
• セキュリティプラグインを導入している

上記の方は同じ方法で直る可能性が高いです。

解決策：セキュリティプラグインの設定を更新

まず結論。

セキュリティプラグインの設定を更新しましょう。

具体的には

1. 管理画面にログインしたことがない接続元を拒否していないか
2. ログインページのURLを変更していないか
3. ログイン失敗を繰り返す接続元を一定期間ロックしていないか
4. 必ず一度ログインが失敗する設定になっていないか

WordPressのセキュリティプラグインで有名なSiteGuardを例に挙げますと

1. 管理ページアクセス制限
2. ログインページ変更
3. ログインロック
4. フェールワンス

上記の設定の見直し・更新をしてください。

ここで特に重要なのはセキュリティプラグインの「設定を更新すること」です。

セキュリティプラグインでは.htaccessファイルにルールを書き込みます。

ユーザーがWebサイトにアクセスした際、Webサーバーはまずこのルールをもとにリクエストを処理します。つまりWordPressの処理が始まる前の段階でアクセスを許可するかどうかが決まります。

セキュリティプラグインの設定をオフにしているのに症状が改善されない場合、.htaccessへの書き込みが残っている可能性があります。（今回のケースがまさにこれでした）

設定を一度「有効」→「無効」と更新することで.htaccessに新たな書き込みが行われ、意図せず残ってしまった設定をキレイにできます。

※すでに設定が有効になっている場合は「無効」にしてから「有効」に戻してください

今回の事例：ログインしたことがない接続元のwp-adminアクセス拒否

ステージング環境ということもあり、ログインしやすい環境にしていました。具体的にはBasic認証を設定した上でwp-adminでログインできる状態です。

このように疑問を感じる方もいらっしゃると思いますが、Basic認証でサイトの閲覧はもちろん、ログイン画面へのアクセスを防いでくれているので、セキュリティプラグインでログインURLを変える必要がないと判断しています。

今回の事例ではログインURLの変更はしていないのにログインしたことがない接続元ではwp-adminへアクセスできない状態になっていました。つまりは自社のインターネット環境でしかアクセスできません。（IPアドレス制限）

しかも、セキュリティプラグインの管理画面上では接続元の拒否設定をしていない扱い（無効状態）になっていたため、解決までに想定以上の時間がかかってしまいました。

「ログインできない」問題が起きたときの切り分け方法

自社の環境ではログイン画面が表示されるのに、クライアントの環境ではログイン画面が表示されない。

まずは状況確認を急ぎました。スクリーンショットを撮っていただき、どの状態でログインできないのか確認します。

Basic認証での“あるある”は、アプリ内ブラウザで開けない問題。

アプリ内ブラウザとはその名の通りアプリ内で開かれるブラウザ。アプリを移動しなくてもその場で確認できること、アプリからの離脱を防ぐための2つの意味があります。

LINEやSNSのDMでURLを押すと、まずアプリ内ブラウザで開かれます。アプリ内ブラウザはセキュリティが厳しく、Basic認証をかけたサイトを開こうとするとエラー画面が表示されるのです。

当社ではLINEでのやりとりが増えてきたため、クライアントにはGoogle ChromeやSafariなどの外部ブラウザで開いてもらうようにお願いをしなければいけません。（自分がパソコン派なので忘れてしまうことが多々あります…）

クライアントからの回答を待つ間に

• 管理者パスワードの変更がないか
• ログインを実行した形跡があるか（ログイン履歴）

さっと確認します。

Basic認証後に404エラーが表示される

クライアントの共有でBasic認証は突破できていることがわかったので原因の切り分けを行いました。

• IPアドレス制限
• セキュリティプラグインの設定
• サーバー側のキャッシュ設定
• キャッシュプラグインの設定

真っ先に疑ったのはIPアドレス制限。Wi-Fi環境を切ってスマホでアクセスしたところ同様の404エラー画面が表示されたからです。

.htaccessを手動で更新した記憶があったのでファイルの中身を見てみます。このときに自分が追記した部分しか確認していなかったため、プラグイン側の記述に気が付きませんでした。

先述通り、セキュリティプラグインの管理画面上では接続元の拒否設定をしていない扱い（無効状態）になっていたため、サーバー側のキャッシュ設定を確認したり、競合が起きやすそうなキャッシュプラグインの設定を見直したり右往左往していました。

最終的に「やはり疑わしきは.htaccess！」ということで、プラグインの記述まで確認したところIPアドレス制限が見つかりました。

落ち着いて作業しよう

何か問題が発生したときに「すぐ直さなきゃ」「どうにかしなきゃ」と焦りますが、焦って良いことはないと実感します。今回の事例も.htaccessを最初から最後まで見ていれば解決できた問題で、状況を複雑にしていたのは自身の焦りでした。

また、初動の状況把握は鉄則です。

問題解決のための入口が間違っていると、どう頑張っても正しい答えにはたどり着きません。

これはプログラミングだけに関わらず、プロジェクト全体、ましてや経営の話にもつながります。

解決したい問題があったら、現在の状況を整理→原因の切り分け→対策検討→実行と進めていきましょう。