NginxかApacheか？異なるサーバー環境における502エラーの独占的トラブルシューティングガイド

11月9日 21:20更新

00234

紹介

ブラウザで "502 不正なゲートウェイ「これは通常、ウェブサーバーの内部通信に障害が発生したことを意味します。この場合ワードプレスユーザーに関する限り、ウェブサイトはほとんど次の方法で運営されている。Nginxもしかしたらアパッチ環境で発生します。どちらも502エラーが発生する可能性がありますが、根本的な原因やトラブルシューティングの方法は異なります。この記事では、ウェブサイトへのアクセスを迅速に回復するために使用するサーバーソフトウェアに基づいたトラブルシューティングの正確な診断ガイドを提供します。

502 Bad GatewayNginx Apache比較サーバーゲートウェイエラーウェブサイトトラブルシューティング

第1章：502エラーに共通する性質を理解する

その違いを掘り下げる前に、まず統一した認識を確立する必要がある：502 Bad Gatewayエラーとは何か？

その性質上、502エラーはHTTPゲートウェイまたはプロキシとして動作するサーバー（つまり、ユーザーと直接対面するウェブサーバー）が、アップストリームサーバー（つまり、アプリケーションロジックを実際に処理するバックエンドサービス）から無効なレスポンスを受け取ったことを示すステータスコード。簡単に言うと、ユーザーが WordPress サイトを訪問すると、まず Nginx または Apache にリクエストが届きます。

その後、このウェブサーバーはリクエストをPHPを扱うプロセス（最も一般的なのはPHP-FPM）に渡し、WordPressのコア、テーマ、プラグインのコードを実行させる必要があります。このパススルー処理が失敗したり、PHP-FPM が有効なコンテンツを返さなかったりすると、ウェブサーバーはユーザーに 502 エラーを投げます。

つまり、NginxであろうとApacheであろうと、どちらも同じ役割を果たす：通信の仲介問題は、この「仲介者」とバックエンドの「作業者」（ワーカー）が同じではないということだ。問題は、この「仲介者」とバックエンドの「労働者」（"worker"）が同じだということだ。PHP-FPM)は対話に対するアプローチが違う。

第2章 Nginx環境における502エラーのトラブルシューティング

Nginx はその高いパフォーマンスとイベント駆動型のアーキテクチャで知られています。PHP-FPM と通信する際には、通常は特定のプロトコル (FastCGI)を実行する必要がある。これを理解することが、トラブルシューティングを成功させる鍵である。

2.1 Nginxのエラーログを調べて最初の手がかりを見つける

Nginxのエラーログは調査の出発点となります。ログの場所はシステムによって異なりますが、一般的なパスは以下のとおりです。 /var/log/nginx/error.log.そのファイル、特にエラーが発生した時点に近いレコードを見ることが、重要な第一歩となる。

Nginxのログで502エラーに関連する最も一般的なエントリは以下の通りです：

コネクト() failed: これは、Nginx が設定で指定された PHP-FPM プロセスプールに接続できなかったことを意味します。
プライマリー・スクリプト不明これは、Nginxが指定されたPHPスクリプトを見つけられなかったか、実行できなかったことを意味します。index.php).

2.2 "connect() failed "の詳細な調査。

ログに接続失敗のエラーが表示された場合、問題の核心は Nginx と PHP-FPM との物理的な接続の確立に失敗したことです。

2.2.1 PHP-FPM プロセスプールの状態を確認する

PHP-FPM サービスが実行されていないか、クラッシュしている可能性があります。その状態を調べるには、以下のコマンドを使用します：

sudo systemctl status php-fpm # systemctl を使用しているシステムの場合。
#またはを使用しているシステムの場合
sudo service php-fpm status

サービスが実行されていない場合は、起動してみてください：sudo systemctl start php-fpm.起動に失敗したりサービスが何度もクラッシュしたりする場合は、 PHP-FPM 自体の設定やログを確認する必要があります。

2.2.2 コミュニケーション方法と権限の確認

Nginx と PHP-FPM は主に二つの方法で通信を行います：ユニックス・ソケット もしかしたら TCP/IPソケット.

Unix ソケットチェック： Nginxの設定が次のようなものである場合 fastcgi_pass unix:/var/run/php/php-fpm.sock； チェックが必要な指示の
- このソケットファイルが存在するかどうか：ls -l /var/run/php/php-fpm.sock
- Nginxプロセスが実行されているユーザー（通常はwwwデータもしかしたらnginx) にソケットファイルへの読み書き権限があるかどうかを確認する。パーミッションエラーは接続失敗の一般的な原因である。
TCP/IPソケットチェック： として設定されている場合 fastcgi_pass 127.0.0.1:9000；をチェックする必要がある：
- PHP-FPM がポートをリッスンしているかどうか：netstat -tulpn | grep 9000
- システムのファイアウォールが、ローカルループバックアドレス（127.0.0.1）のこのポートでの通信をブロックしているかどうか。

2.3 リソースの枯渇とプロセスのブロッキング

Nginxが502を返すもう一つのよくある理由は、PHP-FPMの子プロセスがリクエスト処理中にタイムアウトしたり、リソース不足で終了したりすることです。

PHP-FPMのリソース設定を確認する： PHP-FPM プロセスプール設定ファイル (通常は/etc/php/7.x/fpm/pool.d/www.confバージョン番号は異なる可能性があります）、以下のパラメータに注意してください：
- pm.max_children同時リクエスト数がこの値を超えると、新しいリクエストは拒否され、502になる。
- リクエスト終了タイムアウトひとつの PHP リクエストの処理時間がこのタイムアウト設定を超えると、プロセスは強制終了され、たいていの場合は 502 エラーが発生します。この値を適切に増やすことは可能ですが、実行に時間がかかりすぎるスクリプトやクエリを最適化することの方が重要です。

第3章 Apache環境502エラーのトラブルシューティング

Apache は通常mod_phpモジュールまたはmod_proxy_fcgiを PHP-FPM と組み合わせて PHP リクエストを処理します。後者(Apache + PHP-FPM)は最近のデプロイメントではますます一般的になってきており、このトラブルシューティングもそれに焦点を当てる。

3.1 Apacheのエラーログの解析

Nginxと同様に、Apacheのエラーログは主要な情報源です。一般的なパスは /var/log/apache2/error.log もしかしたら /var/log/httpd/error_log.

Apache のログでは、プロキシエラーに関するエントリを見るかもしれません。mod_proxyモジュールは PHP-FPM と通信します。

3.2 プロキシモジュールの設定と権限の問題

PHP-FPMと通信するためのプロキシとしてApacheを使用する場合、 Nginxとは設定が大きく異なります。

3.2.1 mod_proxy モジュールと mod_proxy_fcgi モジュールの検証

必要なApacheモジュールが有効になっていることを確認してください。これは以下のコマンドで確認できます：

sudo a2enmod proxy_fcgi Debian/Ubuntu システムの場合#。
# または httpd -M の出力を見てください。

3.2.2 バーチャルホストの設定の見直し

Apache は通常、PHP リクエストを PHP-FPM にプロキシする方法を Web ホスティング設定ファイルで定義します：

<ファイルマッチ
    SetHandler "proxy:fcgi://127.0.0.1:9000"
    #またはUnixソケットを使用: SetHandler "proxy:unix:/var/run/php/php-fpm.sock|fcgi://localhost"
</ファイルマッチ

要確認：

セットハンドラディレクティブのパス (IP:Port あるいは Unix ソケットのパス) は、PHP-FPM の実際のリスニングアドレスとまったく同じです。
Unix ソケットを使う場合、Apache ランタイムユーザ (通常はwwwデータもしかしたらアパッシュ)は、そのソケットファイルに対する読み取り権限と書き込み権限を持っていなければならない。

3.3 モジュールの競合とリソース制約

モジュールの競合は、Apache環境では特に注意を要する問題である。

モジュールハンドラの衝突を避ける： 両方がロードされている場合mod_php(昔ながらの治療）とmod_proxy_fcgi(現代的な処理) であり、設定を誤ると PHP ファイルの処理権限を巡って競合し、 502 エラーを含む予測不可能な挙動を引き起こす可能性があります。PHP-FPM を設定した後は、通常はmod_phpまたは、新しいエージェント・コンフィギュレーションに干渉しないことを確認する。
ApacheとPHPのリソース制限を調整する： アパッチタイムアウトディレクティブと PHP の最大実行時間ディレクティブは、いずれも長時間実行するスクリプトに影響を及ぼします。同様に、PHP-FPM のリソース設定 (pm.max_children)もこの環境に適用され、サーバーの負荷に応じて合理的に調整する必要がある。

第4章プラットフォームに共通するトラブルシューティングと予防策

NginxとApacheの構成は異なりますが、共通の上流であるPHP-FPMとWordPress自体を対象としているため、普遍的に適用できるトラブルシューティング手順がいくつかあります。

4.1 PHP-FPM の健全性を診断する

フロントエンドのWebサーバーの種類に関係なく、PHP-FPMの状態は決定的である。

PHP-FPM サービスを再起動します： 手っ取り早く復旧する方法として、PHP-FPM を再起動することで死んでいるプロセスやメモリリークを取り除くことができます。次のようなコマンドを実行します：sudo systemctl restart php-fpm.
PHP-FPMのログを分析する： PHP-FPM は、(プール設定ファイル内に) 独自のログファイルを持っています。キャッチワーカー出力歌で応えるphp_admin_flag[log_errors]。設定)。これらのログを見ることで、PHP スクリプトが失敗した理由 (メモリの枯渇、実行のタイムアウト、致命的なエラーなど) について正確な情報を得ることができます。

4.2 WordPressプラグインとテーマの競合のトラブルシューティング

WordPressのプラグインやテーマの欠陥は、PHPプロセスをクラッシュさせる一般的な原因です。

トラブルシューティングモードに入る： FTPまたはSSH経由でウェブサイトのファイルにアクセスします。
プラグインディレクトリの名前を変更する： そうしれいかんwp-content/pluginsディレクトリ名をプラグインを無効化.この時点ですべてのプラグインが無効になる。
ウェブサイトをチェック サイトのフロントエンドを更新してください。502エラーが消えたら、プラグインのひとつに問題があることを意味します。問題の原因となっているプラグインが見つかるまで、プラグインを1つずつ有効にしてください。
トピックをトグル プラグインに問題がない場合は、アクティブなテーマをWordPressのデフォルトテーマ（Twenty Twenty-Fourなど）に変更して、テーマの互換性の問題を除外してみてください。

概要

502 Bad Gatewayエラーは厄介ですが、追跡不可能ではありません。Nginx を使用している場合は、PHP-FPM への FastCGI 接続、ソケットファイルのパーミッション、プロセスのリソース制限を中心にトラブルシューティングを行う必要があります。Apache を使用している場合はmod_proxy_fcgiエージェントの設定、モジュールの競合問題、関連ファイルのパーミッション。

この的を絞った診断プロセスをマスターすれば、次に502エラーに直面したときでも冷静に対処することができ、経験豊富なシステムドクターのように病巣を突き止め、修正を施し、最終的にWordPressサイトを健全で活気のある状態に戻すことができます。

お問い合わせ
チュートリアルが読めない？無料でお答えします！個人サイト、中小企業サイトのための無料ヘルプ！	カスタマーサービス WeChat
① 電話：020-2206-9892
② QQ咨询：1025174874
三 Eメール：[email protected]
④ 勤務時間: 月～金、9:30～18:30、祝日休み