フロントエンド例外 502 不正なゲートウェイの原因と解決策

502 不正なゲートウェイサーバーがゲートウェイまたはプロキシとして動作している場合、要求を完了するために次のサーバーにアクセスしますが、サーバーは不正な応答を返します。解決策は、Web ページを更新するか、コンピューターのキャッシュファイルをクリーンアップしてから、開きたい Web ページを開くことです。一般的に、この方法は機能しますが、アクセスしている Web ページがブロックされている可能性を排除することはできません。アクセスしている Web ページがブロックされている場合、どのように更新しても役に立ちません。

502 不正なゲートウェイエラーの発生

1. 502 不正なゲートウェイエラーとは何ですか?

簡単に言えば、502 は不正なゲートウェイのエラーコードです。

2. 502エラーの原因

接続タイムアウト。サーバーにリクエストを送信しました。現在サーバーの接続数が多すぎるため、サーバーは正常な応答を返すことができず、次のようなエラーが発生します。

理由1: DNSキャッシュ

DNS キャッシュ。一般的な理由は、VPN を使用せずに Facebook などのサイトにアクセスしていることです。

この時点では当然アクセスできませんが、ローカルマシン上にバッファが残されます。

この状況は通常、数分以内にアクセス可能になります。 DOS ウィンドウで ipconfig /flushdns を実行することもできます。このコマンドは DNS キャッシュをフラッシュします。

2番目の理由: ブラウザプロキシ

ブラウザでプロキシが有効になっています。必ずプロキシをオフにしてください。

3番目の理由: DNSがハイジャックされる

DNS がハイジャックされました。外国の DNS を使用してもハイジャックされます。一部のマシンは VPN でアクセスできますが、一部のマシンはアクセスできません。また、プロキシ、ファイアウォール、ローカルネットワークの原因は除外されました。この時点で、Facebook などのリモート Web サイトに ping を実行します。アクセスできないマシンは通常、どこからも ping できない奇妙な IP アドレスを取得します。アクセス可能なマシンの IP アドレスには、アクセスできないマシンから直接アクセスでき、ping することもできます。この場合、VPN サーバーの DNS を削除できます。

別の DNS に切り替えます。 Windows システムでは、ローカルネットワーク接続のプロパティでデフォルトの DNS を削除し、Google などの外部 DNS を選択できます。または opendns。

3.502 HTTPサイクルエラー

あらゆるクライアント (Web ブラウザーや CheckUpDown ロボットなど) は、次のループを実行して Web サーバーと通信します。

IP 名 (Web サイトの URL の先頭の「http://」) から Web サイトの IP アドレスを取得します。この検索 (IP 名を IP アドレスに変換する) は、ドメインネームサーバー (DNS) によって提供されます。

その IP アドレスへの IP ソケット接続を開きます。このソケットを通じて HTTP データのストリームを書き込みます。

応答とともに Web サーバーから HTTP データストリームを受信します。このデータストリームには、HTTP プロトコルによって生成されたステータスコード値が含まれます。このデータストリームを解析して、ステータスコードやその他の有用な情報を取得します。

このエラーは、上記のクライアントが「502」であると確認された HTTP ステータスコードを受信したときに、最後のステップで発生します。

4. 502エラーを修正する

通常、この問題は、アクセスしようとしている Web サーバー上の Web サイトを含む、バックエンドコンピューター間の IP 通信が不良なために発生します。この問題を分析する前に、ブラウザのキャッシュを完全にクリアする必要があります。

インターネットを閲覧中に訪問しようとするすべての Web サイトでこの問題が発生する場合、次の 2 つの可能性があります。

1) ISPに重大な機器障害/過負荷が発生している
2) ファイアウォールが正しく機能していないなど、内部インターネット接続に問題があります。

最初のケースでは、ISP だけがサポートできます。 2 番目のケースでは、インターネットへのアクセスを妨げている問題を解決するのはユーザーの責任です。

この問題が、アクセスしようとしている Web サイトの一部でのみ発生する場合、それらの Web サイトのいずれかの機器が故障しているか過負荷になっていることが原因である可能性が高くなります。サイトの管理者に連絡してください。

5. 502 Bad Gatewayの問題を解決する方法

最も簡単な方法: CTRL+F5 強制更新

最善の解決策は、もちろんサーバー上で実行することですが、これは誰にとっても可能ではありません。では、どのような解決策があるのでしょうか?簡単に言えば、それは非常に簡単です。つまり、リフレッシュするのです（通常のリフレッシュではありません）

リフレッシュの原則: リフレッシュには 2 つの種類があることを知らない人も多いかもしれません。いわゆるリフレッシュとは、実際には、サーバーからローカルハードディスクブラウザーにデータをダウンロードし、ローカルハードディスクからブラウザーにデータを読み取って表示することを意味します。

① 基本更新: 更新をクリックするか、F5 ショートカットキーを使用します。基本更新では、ローカルハードディスクからブラウザーにデータを取得するだけで、サーバーに要求を再発行しません。ほとんどのユーザーはほとんどの場合この方法で更新するため、502 エラーが発生しても効果はありません。
② サーバーから更新: 再度閲覧したい Web リンクを直接クリックすると、先ほど 502 bad getway が表示されたページが正常に閲覧できるようになっていることがわかります。論理は理解できましたか?閲覧したいウェブページのリンクをクリックすると、サーバーからデータが再度ダウンロードされます。解決策は、サーバーから更新することです。ショートカットキー Ctrl + F5 を使用すると、サーバーに要求が再送信されます。サーバーが正常に応答できる場合は、ページが表示されます。

添付: Nginx 502 Bad Gateway エラーの原因と解決策

Nginx 502 Bad Gateway エラーの原因と解決策

Nginx 502 Bad Gateway エラーに何度か遭遇しました。ここでメモしておこうと思います。

502 エラーが発生する状況は多数あります。それぞれの状況について個別に説明しましょう。

1. fastcgiバッファが小さすぎる

エラーが発生した場合は、まず /var/log/nginx ディレクトリ内の nginx ログファイルを探します。ログには次のエラーが見つかります。

2013/01/17 13:33:47 [エラー] 15421#0: *16 アップストリームからの応答ヘッダーの読み取り中にアップストリームが大きすぎるヘッダーを送信しました

情報を調べたところ、nginx バッファにバグがあり、当社の Web サイトのページが過剰なバッファを消費する可能性があることがわかりました。

ネットで解決策を探したところ、海外のウェブサイトでバッファを増やす方法を見つけ、Nginx 502 Bad Gateway の問題が完全に解決しました。方法は次のとおりです。

http {
    ...
    fastcgi_buffers 8 16k;
    fastcgi_buffer_size 32k;
    ...
}

サーバーやウェブサイトの状況に応じて、上記2つの設定項目を増やしてください。

2. プロキシバッファの設定が小さすぎる

nginx リバースプロキシを使用している場合、ヘッダーが大きすぎてデフォルトの 1k を超えると、上記のアップストリームから送信されたヘッダーが大きすぎるというエラーが発生します (簡単に言うと、nginx は外部リクエストをバックエンドに送信して処理しますが、バックエンドから返されるヘッダーが大きすぎて nginx が処理できず、502 が発生します)。

サーバー{
        聞く 80;
        サーバー名 *.lxy.me;
 
        位置 / {
 
################# 次の 3 行を追加します proxy_buffer_size 64k;
            プロキシバッファ 32 32k;
            proxy_busy_buffers_size 128k;
################ 次の 3 行を追加します proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
............
}

3. php-cgiプロセスのデフォルト数が少なすぎる

インストールおよび使用中に 502 エラーが発生した場合、通常は php-cgi プロセスのデフォルト数が 5 であることが原因です。502 は、phpcgi プロセスが不足していることが原因である可能性があります。/usr/local/php/etc/php-fpm.conf を変更し、max_children 値を適切に増やす必要があります。 max_requests 値が十分でない可能性もあります。これら 2 つの設定項目は大量のメモリを消費するので、サーバーの構成に応じて設定してください。そうしないと逆の効果が出る可能性があります。

4. PHP実行タイムアウト

PHP 実行タイムアウト。/usr/local/php/etc/php.ini を変更し、max_execution_time を 300 に変更します。

5. nginx 待機時間タイムアウト

一部の PHP プログラムの実行時間は、Nginx の待機時間を超えます。nginx.conf 構成ファイルで FastCGI のタイムアウト時間を適切に増やすことができます。

http {
  fastcgi_connect_timeout 300;
  fastcgi_send_timeout 300;
  fastcgi_read_timeout 300;
  ......
  }

nginx 502 不正ゲートウェイのトラブルシューティング方法

Nginx 上で実行されている一部の Web サイトでは、「502 Bad Gateway」エラーが発生する場合があり、頻繁に発生することもあります。以下は、参考のために編集者が収集して分類した Nginx 502 エラーのトラブルシューティング方法です。

Nginx 502 エラーにはさまざまな原因がありますが、プロキシモードのバックエンドサーバーの問題によって発生します。これらのエラーは通常、nginx 自体の問題ではなく、バックエンドから原因を見つける必要があります。しかし、これらのミスの責任はすべて nginx が負うことになり、nginx の推進者たちは本当に疑わしい存在になりました。結局のところ、言葉の観点では、それは悪いゲートウェイを意味するのでしょうか?それは単にnginxが悪いだけではないでしょうか?問題を理解していない人がこれを見ると、すぐに nginx のせいにするでしょう。次のバージョンの nginx では、エラーメッセージがもう少しわかりやすくなり、少なくとも現在の単純な 502 Bad Gateway ではなく、独自の名前を付けるのを忘れないようになることを期待します。

Nginx 502 トリガー条件

502 エラーが最もよく発生するのは、バックエンドホストがクラッシュした場合です。アップストリーム設定には proxy_next_upstream という設定があります。この設定は、バックエンドホストからデータを取得するときに nginx がどのようなエラーに遭遇し、次のバックエンドホストに転送するかを指定します。502 が表示されるすべての状況が含まれます。デフォルトはエラータイムアウトです。エラーはクラッシュや切断などを意味し、タイムアウトは読み取り輻輳タイムアウトを意味するので、理解しやすいです。私は通常、全体を次のように書きます:

proxy_next_upstream エラー タイムアウト invalid_header http_500 http_503;

しかし、今は http_500 項目を削除する必要があるかもしれません。http_500 は、バックエンドが 500 エラーを返すときに別のホストにリダイレクトすることを指定します。バックエンド jsp にエラーがある場合は、スタックトレースのエラー情報が多数出力されますが、現在は 502 に置き換えられています。しかし、社内のプログラマーたちはそうは考えませんでした。彼らは nginx にエラーがあると信じていました。彼らに 502 の原理を説明する時間は本当にありませんでした...

バックエンドは通常 Apache Resin なので 503 エラーは保持できます。Apache がクラッシュした場合はエラーですが、Resin がクラッシュした場合は 503 だけなので、やはり保持する必要があります。

解決

502 問題が発生した場合、次の 2 つの手順に従って優先的に解決できます。

1. 現在の PHP FastCGI プロセスの数が十分かどうかを確認します。

netstat -anpo | grep "php-cgi" | wc -l

実際に使用されている FastCGI プロセスの数が、事前に設定された FastCGI プロセス数に近い場合は、FastCGI プロセスの数が不足しており、増やす必要があることを意味します。

2. 一部の PHP プログラムの実行時間は、Nginx の待機時間を超えます。nginx.conf 構成ファイルで FastCGI のタイムアウト時間を適切に増やすことができます。例:

http {
  fastcgi_connect_timeout 300;
  fastcgi_send_timeout 300;
  fastcgi_read_timeout 300;
  ......
  }
  ......

php.ini の memory_limit の設定が低すぎるとエラーが発生します。php.ini の memory_limit を 64M に変更し、nginx を再起動すると、エラーが修正されました。PHP のメモリが不足していることが判明しました。

この変更を行っても問題が解決しない場合は、次の解決策を参照してください。

1. max-children と max-requests

Nginx php(fpm) xcache はサーバー上で実行されており、1 日の平均トラフィックは約 300 万 PV です。

最近、PHP ページのオープンが非常に遅くなり、CPU 使用率が突然非常に低いレベルに低下し、システム負荷が突然非常に高いレベルに上昇し、ネットワークカードのトラフィックを確認すると、突然非常に低いレベルに低下していることが判明するという状況が頻繁に発生します。この状況は回復するまで数秒しか続きませんでした。

php-fpm ログファイルを確認すると、いくつかの手がかりが明らかになりました。

9 月 30 日 08:32:23.289973 [通知] fpm_unix_init_main()、行 271: getrlimit(nofile): max:51200、cur:51200 9 月 30 日 08:32:23.290212 [通知] fpm_sockets_init_main()、行 371: 継承されたソケット fd=10、「127.0.0.1:9000」を使用しています 9 月 30 日 08:32:23.290342 [通知] fpm_event_init_main()、行 109: libevent: epoll を使用しています 9 月 30 日 08:32:23.296426 [通知] fpm_init()、行 47: fpm が実行中です、pid 30587

これらの文章の前には、子供を閉じたり開いたりすることに関するログが 1,000 行以上あります。

php-fpm には max_requests というパラメータがあり、これは各子プロセスがシャットダウンされる前に処理できるリクエストの最大数を指定します。デフォルト設定は 500 です。 PHP は各子プロセスへのリクエストをポーリングするため、トラフィックが多い場合、各子プロセスが max_requests に到達するまでにかかる時間はほぼ同じになり、すべての子プロセスが基本的に同時に閉じられることになります。

この期間中、nginx は php ファイルを php-fpm に転送して処理することができないため、CPU は非常に低いレベルに低下します (php を処理する必要はなく、SQL を実行する必要もありません)。一方、負荷は非常に高いレベルに上昇します (子プロセスを閉じたり開いたり、nginx が php-fpm を待機する)。また、ネットワークカードのトラフィックも非常に低いレベルに低下します (nginx はクライアントに送信するデータを生成できません)。

解決策は簡単です。子の数を増やし、max_requests を 0 以上の値に設定します。

/usr/local/php/etc/php-fpm.conf を開き、次の 2 つのパラメータを増やします (サーバーの実際の状況によっては、値が大きすぎると機能しません)

<値名="max_children">5120</値> <値名="max_requests">600</値>

次にphp-fpmを再起動します。

2. バッファサイズを増やす

nginx エラーログを開くと、「アップストリームから応答ヘッダーを読み取っているときに、pstream が大きすぎるヘッダーを送信しました」のようなエラーメッセージが見つかりました。情報を調べたところ、nginx バッファにバグがあり、当社の Web サイトのページがバッファを過剰に消費する可能性があることがわかりました。外国人の方が書いていた修正方法を参考に、バッファ容量サイズ設定を追加し、502問題が完全に解決しました。その後、システム管理者はパラメータを調整し、クライアントヘッドバッファと fastcgi バッファサイズの 2 つの設定のみを保持しました。