ゲートウェイのエラーとタイムアウトのトラブルシューティング:502、504

この記事は、504/502/ゲートウェイエラーに関連する問題のトラブルシューティングに役立ちます。トラブルシューティングを行う場合、nginx と PHP の間で処理がどのように機能するかを理解しておくと役立ちます。PHP は、WordPress などの高性能 Web アプリケーションホスティングによく使用されます。

この構成に関連して発生する一般的なエラー:

504 ゲートウェイタイムアウト
ゲートウェイタイムアウト (504)
HTTP エラー 504 – ゲートウェイのタイムアウト
ゲートウェイタイムアウトエラー
502 不正なゲートウェイ
悪いゲートウェイ

なぜゲートウェイがあるのですか?

リクエストが Web ブラウザーを介して送信されると、最初に軽量のフロントエンド Web サーバーである nginx に到達し、次に nginx がそこからどこへリクエストを送信するかを決定します (電車の車掌のように)。 Nginx は通常、リソース (画像やキャッシュされたページなど) の単純な要求を処理し、動的ページ (WordPress 管理ページやショッピングカートなど) の要求を apache (modsecurity および .htaccess 処理用) に送信し、次に PHP に送信します。次のようになります:

nginx -> apache -> php -fpm

nginx は、適切なタイプのリクエストを apache と PHP に送信するゲートウェイとして機能します。 apache や php などの「ダウンストリーム」に問題がある場合、 ゲートウェイを取得します。 502 Bad Gateway などのエラーまたは 504 ゲートウェイタイムアウト .

この問題は、コードの実行が非常に遅いか、Apache または PHP サービスの実際の問題である可能性がありますが、ホストしている問題はコードの問題であることが最も一般的です。

サーバーログを使用して詳細情報を取得

ゲートウェイエラーの原因を特定するには、ログをチェックして、報告されている内容を確認します。ブラウザで見ているように、ログが 502 または 504 エラーを報告するだけの場合もありますが、これは役に立ちません。ただし、Gateway エラーの直前にログに記録されたエラーまたは警告が表示されることがあります。これにより、エラーの原因となっているプラグインまたはテーマが特定されます。

Plesk を使用してログを表示する方法については、こちらをご覧ください。 これらのエラーを使用して問題の根底に到達できる場合は、間違いなくそうしてください!それ以外の場合は、物事を絞り込むための追加の方法を読んでください。

ヘルプ！ Web サイトの管理領域にアクセスすることさえできません。 (WordPress の wp-admin と同様)

一定の Gateway エラーが発生している場合、Web サイトの管理領域 (WordPress の wp-admin など) にアクセスできない場合がありますが、この問題のトラブルシューティングを行うにはアクセスする必要があります。アクセスを回復する唯一の方法は、問題が解決されるまでアクセスをブロックすることです。

アクセスをブロックするには、次の 2 つの方法のいずれかを実行できます:1) リソースを消費しているサイトの特定の部分へのアクセスをブロックするか、2) 自分の IP 以外のすべての IP へのアクセスを一時的にブロックして、アクセスを取り戻すことができます.

自分以外のすべての IP へのアクセスをブロックするには (簡単)

Plesk にログインし、apache &nginx 設定 にアクセスします。ページ。 [サイトへのアクセスを拒否する] の下」カスタム値を入力して "* にします「 （引用符なし）。次に、[除外] の下に自分の IP アドレスを入力し、変更を保存します。変更を保存してから、サーバーが再起動するまで (~1 分)、実行中の PHP プロセスがタイムアウトになるまで (~2 分)、最大 3 分間待つ必要がある場合があります。

トラブルシューティングが完了したら、必ずこのブロックを削除してください。

リソースを大量に消費するリクエストへのアクセスをブロックするには (より複雑)

この問題を引き起こしているページまたはリソースがサイトに 1 つしかない場合 (1 つのページの読み込みが遅いなど)、ログを使用してその特定の要求 URI を特定します。次に、次のコードスニペットを .htaccess ファイルの先頭に追加して、問題のあるリソースを (一時的にでも) ブロックして、管理パネルにアクセスできるようにします。 filename\.php を置き換えますログに表示される実際のリクエスト URI を使用します (これは、ドメインの後に続く部分です)。ファイルパスにドットが含まれている場合は、例に示すようにバックスラッシュを先頭に追加してください。

<FilesMatch filename\.php>
Order Allow,Deny
Deny from all
</FilesMatch>

ゲートウェイエラーの一般的な理由

可能な応急処置:

問題が 1 回限りのもの (スクリプトを実行しても実行が停止しないなど) の場合、解決策は直接基盤となるサービスを再起動することです、そのスクリプトを強制的に終了します。

サーバへのルートアクセス権または Plesk への管理者アクセス権がない場合は、Plesk でウェブサイトの設定を変更することで、このような再起動をトリガーできることがよくあります。たとえば、ドメインの [PHP 設定] ボタンに移動して、小さな変更 (メモリを 32MB から 48MB に増やすなど) を行ってから、変更を保存してみてください。この更新により、Apache と PHP の処理が再開され、エラーが解決される可能性があります!

変更が有効になるまでに最大 3 分 (プロバイダーによってはそれ以上) かかる場合があります。

それでも問題が解決しない場合、または問題が再発する場合は、次の考えられる原因/症状を調べて、自分のケースに最も適したものを判断する必要があります.

エクスポート、インポート、または時間がかかる大きなレポートを実行しようとしています

サイトが正常に実行されていても、サイトのデータに対して大規模なエクスポート、インポート、またはレポートを実行しようとするたびに、ゲートウェイエラーが発生します。これは、レポートを処理する前にタイムアウトに達しているためです。この長期的な問題を解決するための非常に簡単な方法はありませんが、短期的な問題を解決する方法があります:一時的にタイムアウトを増やします.

PHP 設定の変更方法に関するガイドの手順に従って、Plesk コントロールパネルでこれを行うことができます。 max_execution_time の値 (秒単位) を変更する必要があります。そして max_input_time プロセスを 5 分間実行できるように、300 などに設定します。 長時間のアクションが完了したら、忘れずにこれらの値を元に戻してください。

タイムアウトを恒久的に増やせないのはなぜですか?

技術的には可能ですが、タイムアウトを永続的に増やすと、サイトのパフォーマンスに悪影響を及ぼす可能性が非常に高くなります。 .タイムアウトは、意図的にデフォルトで 30 秒または 60 秒のような値に設定されています。プロセスの完了にそれほど時間がかかり、実行時間の長いプロセスをトリガーしすぎると、利用可能なすべての処理スロットが使い果たされ、すべての訪問者に対してサイト全体がダウンする可能性があります。したがって、タイムアウト値を 30 ～ 60 秒前後に保つことで、これが最大でもその時間だけ発生するようになります。

自分のサイトまたはホームページへのほぼすべてのリクエストの処理に時間がかかる

これが問題かどうかは、サイトの 1 つまたは複数のページが読み込みを開始するまでに 10 秒以上かかり、10 秒以上経過するまでブラウザに何も表示されない場合にわかります。

これが発生する一般的な理由は 2 つあります。

1) コードのパフォーマンスの問題 :パフォーマンスが最適化されていない、または問題のあるコードがサイトで実行されています。この例としては、コード内の無限ループ、または (バッチで取得するのではなく) 1 回のクエリで何百万ものデータベースレコードを取得しようとするものがあります。最初に確認することは、プラグイン、新しいテーマ、カスタムコードなど、最近サイトに追加されたコードです。これを絞り込むために、おそらく開発者に関与してもらいたいと思うでしょう.これのいくつかの一般的に認識されているバージョンを含む KB 記事がありますが、これらの提案で原因を特定できない場合、残りのオプションは徹底的なトラブルシューティングです。 WordPress の徹底的なトラブルシューティングのガイドはこちらにあります。

2) 遅い、または応答しない外部リソースリクエスト: 一部の PHP コードは、外部リソース (他の場所でホストされている) と通信しようとしていますが、応答に時間がかかりすぎているか、まったく応答していません。外部リソースに関する問題を解決するには、ウェブサイトの PHP コード（カスタムコードまたはプラグイン / テーマコード）のどの部分が外部リソースを取得しようとしているかを調べる必要があります。これは、API やスクレイピングを介して支払い処理業者や気象データの取得などのサードパーティサービスに接続する最も一般的なコードです。以下にいくつかの例を示します:

一部のペイメントゲートウェイまたは XML API サービスは、標準以外のポートを使用します (ただし、標準ポートがはるかに頻繁に使用されるようになったため、最近では非常にまれです)。ポート 80 または 443 を使用していない場合は、ブロックされたポートで通信しようとして失敗している可能性があります。
古い Twitter ウィジェットは、バックエンドコードを使用してツイートを取得することが知られており、Twitter サーバーへの接続に失敗すると、このようなハングアップが発生します。これは、Javascript を介して非同期的に動作する Twitter 独自のフィード埋め込みには適用されません。

WordPress やその他のプラグイン付きの CMS を使用している場合は、外部と通信する可能性のあるプラグインを無効にして、問題が解決するかどうかを確認してください。

どのプラグインに問題があるかを直感的に判断できない場合、残りのオプションは徹底的なトラブルシューティングです. WordPress の徹底的なトラブルシューティングのガイドはこちらにあります。

原因:リクエストを処理するために必要な PHP プロセスが多すぎます

あなたの大量のトラフィックが動的処理リクエストを作成するため、多くの PHP プロセスが必要な場合、主な目標は、ページの読み込みごとに発生する必要がある動的処理の量を減らすことです。方法は次のとおりです。

WordPress を使用している場合は、キャッシュをインストールして最適化する方法について、こちらをご覧ください。
すでにキャッシュを有効にしている場合、次のステップは、動的処理が発生しているケースを検出して削減することです。

原因:バッファが限られている

Apache または PHP プロセスは、nginx が処理できるよりも大きなデータサイズを生成している可能性があります。 Apache と PHP は両方とも、このデータを nginx を介して Web サイトの訪問者に渡す必要があるため、「Upstream sent too big header」(アップストリームが大きすぎるヘッダーを送信しました) を示す 502 エラーを生成します。このエラーは、WordPress プラグイン OptInMonster を使用しているお客様で確認されていますが、どのソフトウェアでも発生する可能性があります。

当社の共有ホスティングは、nginx 用により大きなバッファーで既に最適化されているはずですが、独自の VPS をお持ちの場合、または当社でホスティングされていない場合は、これらの値を自分で nginx 構成に適用する必要があります:

fastcgi_buffers 128 4096k;
fastcgi_buffer_size 4096k;

これは、大きな (4MB) ヘッダーを受け入れても問題ないことを nginx に伝えます。これらを次のようなファイルに挿入できます:/etc/nginx/conf.d/increase_buffers.conf 次に、nginx を再起動して変更を適用します。例:

echo 'fastcgi_buffers 128 4096k;
fastcgi_buffer_size 4096k;' > /etc/nginx/conf.d/increase_buffers.conf

原因:PHP-FPM が正しく構成されていないか、調整が必要 (VPS/専用サーバーのみ)

一定のゲートウェイタイムアウトエラーが発生し、それらを解消する唯一の方法が PHP を再起動することである場合 (上記のとおり)、または VPS を使用していて、PHP プロセスが CPU 使用率の高い状態で長時間実行されている場合必要以上に長い間 (またはサーバー技術者からそう言われている場合)、それらを抑えるためにいくつかの措置を講じる必要があります。

注:共有ホスティングを使用している場合、PHP-FPM 構成は既に共有ホスティング環境用に最適化されているため、ゲートウェイエラーが発生している場合、この解決策は適用されません。

以下は、私たちのために機能したいくつかのオプションですが、これらは実際の問題の回避策であることに注意することが非常に重要です.応答速度が不十分なコードを特定し、そのパフォーマンスを最適化することが真の解決策です。

<オール>

PHP-FPM を使用すると、Plesk にいくつかの変更を加えることで、PHP プロセスマネージャー (FastCGI プロセスマネージャー =FPM) を調整できます。「オンデマンド」スタイルの PHP-FPM プロセスを使用している場合は、新しいプロセスを正常に終了/再起動する前に、各プロセスが処理するリクエストの数を減らしたい場合があります。これは、pm.max_requests としてラベル付けされます。パフォーマンスに問題がある場合は、100 または 150 を試してください

PHP プロセスが停止していない場合は、それらを *make* 停止する必要があるかもしれません。これを行うには、いくつかの良い方法があります。まず、 pm.process_idle_timeout を設定して、PHP-FPM プロセスのアイドルタイムアウトを確実に設定します。 – 10 秒に設定してみてください (FPM 設定の下のフィールドでこれを行うことができます。

PHP プロセスがまだ続く場合死んでいない場合は、さらに攻撃的になる必要があるかもしれません。 request_terminate_timeout を設定してみてください max_execution_time 設定よりも数秒長くなります。 max_execution_time がプロセスを強制終了しない場合、request_terminate_timeout は確実に終了します。

このガイドが役に立った場合は、利用可能な他のガイドと投稿を確認してください。高性能なカナダの Web ホストまたは VPS ホスティングパートナーが必要な場合は、当社のサービスをチェックしてください!