WordPressサイトを運営する上で、エラーとの遭遇は特に避けたいことの1つ。例えばHTTP 407エラーは、訪問者がコンテンツにアクセスできなくなることで、売上やコンバージョンに悪影響を与える可能性も。

幸い、このエラーはすぐに解決可能で、サイトのデバッグに役立つツールもあります。根本的な原因を特定することで、効率よくトラブルシューティングを行い、今後の再発も防止することができます。

この記事では、HTTP 407エラーの概要と原因を見ていきます。その後、クライアント側とサーバー側でそれぞれエラーを解決する方法をご紹介します。早速始めましょう!

「HTTP 407 Proxy Authentication Required」エラーの解決方法について動画での解説もご用意しています

HTTP 407エラーとは

「HTTP 407 Proxy Authentication Required」エラーは、サーバーがリクエストを完了できない時に発生します。これは、クライアントとサーバー間でプロキシサーバーを使用していて、認証情報の一部が不足していることが原因です。基本的に、プロキシはクライアントを認証することができません。

このエラーの発生元はいくつか考えられるため、原因の特定が複雑になることも。また、プロキシ自体に問題があることもあり、この場合は、クライアント側に解決の手立てはありません。

ただし、プロキシとの通信に関する問題を解決する方法はいくつかあります。

なお、このエラーは、一般的に見られる「HTTP_400 Bad Request」エラーに関連している可能性もあります。

HTTP 407エラーの原因

HTTPエラーは、クライアントがサーバーへの接続をリクエストして失敗した時に発生するものです。ウェブブラウザがHTTPプロトコルでサーバーにアクセスする際、クライアント/サーバー間で対話が行われます。HTTPコードは、この対話の処理に使用され、成功または失敗のメッセージを返します。

HTTP 407エラーは、不正なアクセスによって発生する401と似ており、違いは、407の場合、サーバーへの直接接続ではなくプロキシを使用した認証に失敗する点にあります。

クライアント認証は、安全な接続の確立に不可欠です。この通信の構成要素の1つは、デジタル証明書の交換で、証明書は、個人、法人、プログラム、または個々のコンピュータのIDに関連付けられています。サーバーは、デジタル証明書内の情報に基づいてリクエストを承認または拒否し、接続を許可または保留にします。

ほとんどの場合、単純な接続の遅れ、入力ミス、コードの矛盾などによって、デジタルIDが誤認されることが原因で拒否されます。または、サーバーへのアクセス権がないことも考えられます。

HTTP 407エラーの解決方法

HTTP 407エラーは、クライアント、サーバー、そしてプロキシのいずれかに原因があることになるため、トラブルシューティングとして、複数の解決策を実行する必要があるかもしれません。また、おそらくクライアントとサーバーにはアクセスできますが、プロキシの管理は行えないことが予想されます。

うまくいけば、アプリケーションパフォーマンス監視(APM)ツールを使って、深刻な問題になる前にエラーを検出することも可能です。サイト上のエラーの特定と解決に役立つ優れたAPMツールはいくつかあり、KinstaのAPMツールもその1つとして挙げられます。専用コントロールパネルのMyKinstaから簡単に使用できます。

それでは、HTTP 407エラーの原因を特定し、解決する方法を見ていきましょう。また他のエラー同様、万が一に備えて、サイトに変更を加える前にバックアップの作成をお忘れなく。

クライアント側の問題を解決する手順

まずは、クライアント側の問題から探っていくのが手っ取り早く賢明です。何かおかしな点がないか、別のブラウザや端末から接続してみてください。例えば、PCで407エラーが見られるのにスマホでは表示されない場合、端末のデジタルIDやセキュリティプログラムに問題がある可能性があります。

また、最近サイトに手を加えた場合は、変更前の状態に戻して再度接続テストを実施してください。その他、クライアント側に原因がありそうであれば、以下の手順に従ってトラブルシューティングを行います。

ステップ1. URLの確認

まずは、URLに誤りがないかどうかを確認しましょう。初歩的ですが、ちょっとした入力ミスがエラーを引き起こしている可能性もゼロではありません。URLを見直し、キャッシュをクリアして、サイトを再度読み込んで、エラーが消えるかを確認してみてください。

URLは直接入力するのではなく、検索エンジンを使って探しているページを表示させることも可能です。これでエラーが消えない場合は、バックエンドに問題があるかもしれません。

ステップ2. プラグインの無効化

サイトにエラーの原因となり得る変更を最近加えた場合は、追究する価値ありです。最近追加または更新したプラグイン、テーマ、拡張機能を調べてみましょう。

管理画面にアクセスできる場合は、「プラグイン」ページですべてのプラグインを無効化します。

WordPressでプラグインを一括で無効化
WordPressでプラグインを一括で無効化

その後、再度サイトにアクセスし、エラーが消えるかを確認します。これでエラーが解消された場合は、原因がプラグインにあることがわかります。

今度は、プラグインを1つずつ無効化し、その都度ページを更新します。特定のプラグインを有効にした時にのみエラーが発生する場合は、プロキシサーバーへのアクセスを妨げているコードに何かしらの問題があると思われます。

WordPressの管理画面にアクセスできない場合は、FileZillaなどのファイル転送プロトコル(FTP)クライアントを使ってサイトに接続します。認証情報を入力してサイトに接続したら、public_html > wp-contentに移動し、pluginsフォルダを見つけます。

フォルダを右クリックして、「名前の変更」を選択します。

FileZillaでpluginsフォルダの名前を変更
FileZillaでpluginsフォルダの名前を変更

フォルダ名を変更すると、サイト上のすべてのプラグインが自動的に無効化されます。これで、サイトからエラーが消えたかどうかを確認します。解決している場合は、フォルダ名を「plugins」に戻し、WordPressの管理画面にログインして、原因となっているプラグインを特定するまで、1つずつプラグインを有効化していきます。

また、不具合のあるプラグインを見つけたら、更新があるかどうかを確認することをお勧めします。これでエラーが解消されることがあります。プラグインが最新のバージョンになっている場合は、開発者に問い合わせ、問題を認識しているかどうか、エラーの修正等が行われているかなどの状況を確認しましょう。

ステップ3. サイトをエラー発生前の状態に復元

クライアント側で特に原因となるような問題が見当たらない場合、次のトラブルシューティングに進む前に、サイトの復元を行う手もあります。エラーが発生する前の状態にサイトを戻せば、最近の変更に起因しているのか、あるいは外部ソースに起因するのかを判断することができます。

なお、エラーが続く場合に備えて、できれば復元を行う前にバックアップを作成しておきましょう。バックアップしておけば、復元してもエラーが続いた場合は、サイトを現在の状態(復元前のエラーが表示されている状態)に再び戻す際、イチからサイトの編集を行わずに済みます。

バックアップを復元してエラーが解消された場合は、おそらくサイトに最近加えた変更が原因です。原因として考えられるものがあれば、まずはそれから検証を行い、加えた変更を段階的にやり直して、エラーを引き起こしている変更を特定しましょう。

サーバー側の問題を解決する手順

上記の操作を行なっても解決しない場合は、次にサーバー側の問題を探りましょう。例えば、サーバー上に他のサイトがあれば、そのサイトでも同じエラーが発生しているかを確認します。他のサイトでも同様のエラーが見られる場合は、サーバーに原因がある可能性が高いです。

ここからは、サーバー側でエラーを解決するためのトラブルシューティング方法をご紹介します。

ステップ1. エラーログの確認

エラーログには、発生したエラー、およびサイトとサーバーの変更履歴が記録されます。また、各接続リクエストの成功/失敗を確認することも可能です。

エラーログにアクセスするには、FTPでサイトのルートフォルダを開き、logsフォルダを選択します。すると、nginxphpの2つのフォルダが表示され、どちらのフォルダにもエラーログが格納されています。

FileZillaでサイトのエラーログを確認
FileZillaでサイトのエラーログを確認

Nginxはサービス、プロキシ、キャッシュを処理します。なお、利用しているホスティングサービスが別のウェブサーバーを使用している場合、このファイル名は異なります。PHPは、WordPressで使用されているスクリプト言語。どちらかのログで407エラーを検索すれば、エラーの原因と発生日時などが明らかになる可能性があります。

ステップ2. サーバーの設定ファイルの確認

予期せぬリダイレクトは、プロキシ認証エラーの原因になりがちです。プロキシサーバーに不審なものとして認識され、アクセスが拒否されることがあるため、ウェブサーバーの設定ファイルを確認し、意図しないリダイレクトの指示がないかどうかを調べてましょう。

これを行うには、.htaccessファイルを確認します。FTPクライアントを使用して、サイトのルートフォルダに移動し、appフォルダをクリック。次に、publicフォルダを選択すると、.htaccessファイルが表示されます。

FileZillaで.htaccessファイルを見つける
FileZillaで.htaccessファイルを見つける

このファイルを開き、「redirect」という言葉を含むコード行や、URLを書き換えているコード行を探します。疑わしいものや不要なものがあれば、削除しましょう(操作を行う前にファイルのコピーを取っておくことをお勧めします)。その後、サイトに再びアクセスし、エラーが消えているかを確認します。

なお、削除したコードは、おそらく何かの理由があって.htaccessファイルに記述されているため、削除することによって、サイトの一部が機能しなくなることがあります。とは言え、エラーを引き起こすコードには対処が必要になるため、利用しているサーバーに確認を取ることをお勧めします。

ステップ3. アプリやスクリプトのデバッグ

最後に実行したいのは、サイトのデバッグです。最近、カスタムコードやプラグインをインストールした場合は、単にバグがエラーを引き起こしていることも考えられます。無料のQuery Monitorを使用すると、コードにおかしな点がないかを調べることができます。

デバッグを実行する前には、サイトをステージング環境に複製しておきましょう。これは、DevKinstaを使用すれば簡単です。サイトを複製すれば、407エラーを引き起こしている問題を安全にデバッグすることができます。

デバッグにサポートが必要な場合は、WordPressのデバッグモードを利用すると、問題の分析が容易になるはずです。また、WordPressのデバックログを有効化すると、バグを追跡して後から確認することも可能です。

まとめ

HTTP 407エラーは、通常クライアントがプロキシサーバーに対する適切な認証情報を持っていないことが原因で、サーバーがリクエストを完了できない時に発生します。このエラーは、ユーザーのアクセスを妨げる可能性があり、すぐに対処するのが得策です。

クライアント側でエラーが発生した場合は、プラグインを無効にして、サイトをエラー発生前の状態に復元すると解決することがあります。サーバー側のエラーの場合は、サーバーの設定ファイルやアプリケーションのログを確認し、アプリやスクリプトを適宜デバッグしてください。

今回ご紹介したいずれかの方法で、必ずHTTP 407エラーを解決することができるはずです。