Linux
 Computer >> コンピューター >  >> トラブルシューティング >> Linux

Ubuntuサーバーのアップグレード後にNginxで404エラーが発生する場合の解決方法

現在、最も広く利用されているWebサーバー構成の一つが、Ubuntu Server上でNginxを稼働させる組み合わせです。このシステムは非常に効率的で、両方のパッケージが継続的にアップデート提供されているため、保守も容易です。システム管理者は通常、aptパッケージマネージャー経由でアップデートを行います。Ubuntu Serverにはデフォルトでグラフィカルインターフェースが搭載されていないためです。

ただし、Ubuntu Serverのアップグレードでは予期しないエラーが発生することがあり、GUIがない環境では初心者にとってトラブルシューティングが難しくなる場合があります。幸い、いくつかの簡単なコマンドを実行するだけで、アップグレード後のNginx 404エラーを解決できるケースは少なくありません。

方法1:欠落しているNginxエラーページを修正する

AWSやプライベートサーバーなど、LEMPスタック構成でサイトをホストしている場合、Ubuntu Serverのアップグレード後にサイトが突然ダウンすることがあります。まず、別のマシンのWebブラウザからサイトへアクセスしてみてください。404エラーが返された場合は、Ubuntu ServerのCLIで次のコマンドを実行し、直近のエラーを確認します。

tail -f /var/log/nginx/error.log

ログに以下のようなエラーが記録されている場合:

open() "/usr/share/nginx/html/50x.html" failed (2: No such file or directory)

これは、システムにエラーページが存在しないことを示しています。同じ行に「40x.html」が表示されることもありますが、サイトがダウンして404エラーが返されている状況では比較的まれです。lsコマンドで該当ディレクトリの中身を確認しましょう。何も存在しない場合は、50xエラー用のHTMLページを作成する必要があります。

なお、デフォルトのドキュメントルートディレクトリ構造をそのまま使うと、パッケージマネージャーが保存済みのファイルを上書きしてしまうトラブルが起きがちです。カスタムディレクトリ構造を作成できる権限があるなら、Nginx設定のdocroot行を変更しておくことで、こうした問題を未然に防げます。

方法2:PHPに正しいソケットを見つけさせる

エラーログに次のようなメッセージが表示されるケースもあります。

connect() to unix:/run/php/php7.0-fpm.sock failed (2: No such file or directory) while connecting to upstream

これは、PHP7.0が稼働してはいるものの、本来あるべき場所で動作していないことを意味します。バージョン番号はPHPの構成によって異なる場合があります。デフォルトのインストールでは/run/php/php7.0-fpm.sockまたは/var/run/php/php7.0-fpm.sockから実行されますが、このエラーが出ているということは、おそらくそうなっていないのでしょう。

まず、次のコマンドを実行して、システム上のどこかにPHP-FPMのソケットが存在していないか探してみてください。

find / -name 'php*fpm.sock'

該当する出力が得られたら、Nginx設定を更新し、fastcgi_passディレクティブでソケットの正しい場所を指定します。もちろん、「/directoryPath」の部分は実際の正しいパスに置き換えてください。ソケットファイルを使用している場合は、fastcgi_pass unix:/directoryPath/php/php7.0-fpm.sock;のように記述すれば設定が反映されます。

ソケットファイルを使わない旧式のTCPソケットを利用している場合は、次のコマンドでPHPソケットがポート9000でリッスン中かどうかを確認できます。

sudo netstat -tulpn | grep 9000

リッスンしている場合は、nanoやviなどのテキストエディタでfastcgi_passの設定を開き、unix:...の行を127.0.0.1:9000に書き換えます。

それでも解決しない場合は、使用中のバージョンのphp-fpmが実際に稼働しているかを確認してください。

sudo systemctl restart php7.0-fpm

そのうえで、上記の手順をもう一度繰り返します。

ほとんどの場合、PHP-FPM設定ファイル内のlistenエントリと、Nginx側のfastcgi_passの値は一致している必要があります。新しい構成では/run/php/php7.0-fpm.sockを、旧式の構成では127.0.0.1:9000を試してみるとよいでしょう。


著者について

Kevin Arrows(ケビン・アローズ)

Kevin Arrowsは、10年以上の業界経験を持つベテランのテクノロジースペシャリストです。Microsoft Certified Technology Specialist(MCTS)認定資格を保有し、最新の技術トレンドを追い続けることに強い情熱を注いでいます。ソフトウェア開発、サイバーセキュリティ、クラウドコンピューティングなど、幅広い技術トピックについて執筆しており、複雑な技術的概念をわかりやすく簡潔に説明する能力で同業者から高い評価を得ています。

  1. Ubuntuのソフトウェアアップデーターエラーを解決する方法:初心者向けステップバイステップガイド

    Ubuntuマシンでソフトウェアアップデーターを実行しようとした際、「リポジトリ情報のダウンロードに失敗しました(Failed to download repository information)」というメッセージが表示され、インターネット接続の確認を促されることがあります。ターミナルからapt-getコマンドでUbuntuを更新しようとした場合も、パッケージ管理ユーティリティから別の種類のアップデーターエラーが表示されることがあります。この問題は、Lubuntu、Xubuntu、Kubuntu、Ubuntu MATEなど、すべてのUbuntu派生ディストリビューションでも発生します。また、

  2. UbuntuでChromeアンインストール時に「サブプロセス /usr/bin/dpkg がエラーコード(1)を返しました」と出る原因と対処法

    Google Chromeは、高速な動作と使いやすいインターフェースを備えた、世界で最も利用されているウェブブラウザの一つです。ほぼすべてのオペレーティングシステムに対応しており、10億人以上のユーザーに愛用されています。しかしながら最近、Ubuntu環境でChromeをアンインストールする際に問題が発生するという報告が多数寄せられています。具体的には、Chromeのパッケージを削除しようとすると、「サブプロセス /usr/bin/dpkg がエラーコード(1)を返しました」というエラーが表示されてしまうのです。「サブプロセス /usr/bin/dpkg がエラーコード(1)を返しました」エラ