問題タブ [http-status-code-502]

nginx の proxy_next_upstream の動作がおかしい。

他国にプロキシする上流がリクエストを返さなかった場合に、次のサーバーに渡したい。だから私はこのようにアップストリーム（プロキシから他国へ）を設定しました。

それはうまくいきます。しかし、Tomcat を接続するためのアップストリームも、失敗したときに再試行します。

上流の tomcat 設定

アップストリームに2つ以上のサーバーがある場合にのみ、nginxは次のアップストリームを試みると思います。

ただし、アップストリームにサーバーが 1 つある場合でも、2 回以上試行します。

nginx、Tomcat、Java Spring を使用しています。

私のnginxの設定、アクセスログ、エラーログがあります。

プロキシ構成

ログ形式

アクセスログ

エラーログ

ご覧のとおり、proxy_next_upstream_tries を 2 に設定しました。しかし、2 回以上リトライします。(アクセス ログ : {502, 502, 502, 502} -> アップストリームが次のサーバーへのプロキシを 4 回試行することを意味します)

それについて質問があります。

1. アップストリームのTomcatが次のサーバーを通過するために再試行しないようにします。出来ますか？
2. アップストリームにサーバーが 1 つあるのに再試行するのはなぜですか?
3. 2回以上再試行するのはなぜですか?
4. アップストリームが 502 を返すと、一時的に接続できないのはなぜですか? (発生時、サーバーの状態は正常でした)

私の質問の 1 つに対する答えを知っている場合は、お知らせください。

ありがとうございました。

私は現在、プッシュ通知を処理するレガシー プロジェクトを持っています。そのサブスクライバー ベースは Firebase にあります。サブスクリプションは gcloud プラットフォームの機能を使用するため、次のテクノロジーがあります。

ノード: "10" firebase-admin ":" ^ 8.9.2 "、firebase-functions ":" ^ 3.3.0 "

通知が作成されると、ベースのサブスクライバーに通知をディスパッチするのと同じように、異なる vps に送信される .json ファイルが生成されます。

しかし、今月 11 日の時点で、以前は発生しなかったランダムな 502 エラーが発生し始めました。502 を送信する関数は次のとおりです。

実装に変更はありません。CMS (CMS は python 3.6 にあります) 側では、ログに次のエラーが表示されます。

それをトリガーするコード行は次のとおりです。

応答時間がどのように増加する可能性があり、何が原因である可能性がありますか? ありがとう。

CDN で Google クラウド バランサーを使用すると、エラー 502 が発生します。ロード バランサーを削除すると、ウェブサイトが正常に動作するため、ロード バランサーの設定で何か間違ったことをしたにちがいないと確信しています。

これは、ここでロードバランサーを構成する方法 です

• HTTP ヘルスチェックまたは HTTPS ヘルスチェックを使用する必要があります。
• このリンクを確認しました。同じ問題があるようですが、うまくいきません。
• openlitespeedフォーラムのチュートリアルに従って、サーバー管理パネルでKeep-Alive Timeout (secs) = 60sを設定し、長時間接続を受け入れるようにインスタンスを構成しましたが、まだ機能していません.
• この 2 つのファイアウォール ルールをこの Google クラウド リンクに追加して、Google ヘルス チェック IP を許可しましたが、まだ機能しませんでした: https://cloud.google.com/load-balancing/docs/health-checks#fw-netlb https: //cloud.google.com/load-balancing/docs/https/ext-http-lb-simple#firewall

ロード バランサのログ メッセージを確認すると、 failed_to_pick_backend というエラーが表示されます。ロード バランサーを再構成しようとしましたが、役に立ちませんでした。

私は Google Cloud を学び始めたばかりで、私の知識は本当に限られています。誰かがこの問題を解決する方法を順を追って教えてくれれば幸いです。ありがとうございました！

502最近、CPU を集中的に使用する 20MB 以上の画像デコード/解析関数を Elastic Beanstalk アプリケーションに追加しましたが、関数自体を呼び出すか、アプリへの後続の無関係なリクエストがエラーになる場合があることに気付きました。アプリ自体ではなく、Nginx から:

私の Elastic Beanstalk インスタンスはOS をt2.small実行してDocker running on 64bit Amazon Linux 2/3.2.0おり、ロード バランサーは次のようになります。

より大きなインスタンス サイズに切り替えるか、ロード バランサーのプロセスを増やすことで、発生している502エラーを軽減できますか?

Gunicorn を使用する Google Cloud Run に Python アプリケーションをデプロイしています。gunicorn とクラウド実行のタイムアウトは両方とも 900 秒に設定されています。これは Cloud Run のタイムアウトでもあります。奇妙なことに、この関数を呼び出すと、Cloud Run から 502 エラーが発生します。アプリケーションの実行時間が 60 秒未満の場合ではなく、60 秒を超える場合です。たとえば、以下のデプロイされた関数はこのエラーをスローしました。

ただし、スリープを 40 秒に変更すると、次のようになります。

502 エラーはありませんでした。当初はデフォルトタイムアウトが60秒のnginxが原因かと思っていましたが、デフォルトでdockerやcloud runでnginxがデプロイされているようには見えず、これが原因ではないようです。私の Dockerfile は以下のとおりです。

フロントエンドで使用してクラウド実行を呼び出していますaxiosが、私の理解ではタイムアウトがないため、これが問題になるとは思いません。どんな助けでも大歓迎です、ありがとう！

編集:これはクロムコンソールのエラーメッセージの画像です-あまり役に立たないようです: