170

499個のNGINXエラーコードがたくさん表示されます。これはクライアント側の問題だと思います。NGINXや私のuWSGIスタックでは問題ありません。499を取得すると、uWSGIログに相関関係があることに注意してください。

address space usage: 383692800 bytes/365MB} {rss usage: 167038976
bytes/159MB} [pid: 16614|app: 0|req: 74184/222373] 74.125.191.16 ()
{36 vars in 481 bytes} [Fri Oct 19 10:07:07 2012] POST /bidder/ =>
generated 0 bytes in 8 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1
switches on core 1760)
SIGPIPE: writing to a closed pipe/socket/fd (probably the client
disconnected) on request /bidder/ (ip 74.125.xxx.xxx) !!!
Fri Oct 19 10:07:07 2012 - write(): Broken pipe [proto/uwsgi.c line
143] during POST /bidder/ (74.125.xxx.xxx)
IOError: write error

私はより詳細な説明を探しており、それがuwsgiのNGINX構成に問題がないことを望んでいます。私はそれを額面通りに受け止めています。クライアントの問題のようです。

4

15 に答える 15

98

私の場合、せっかちで、ログを誤解してしまいました。

実際、本当の問題は、ブラウザーと nginx の間ではなく、nginx と uwsgi の間の通信でした。ブラウザにサイトをロードして十分に待っていたら、「504 - Bad Gateway」が表示されていたでしょう。しかし、時間がかかりすぎたので、いろいろ試してからブラウザで更新しました。そのため、504 エラーが表示されるまで待つことはありませんでした。ブラウザで更新すると、それは前のリクエストが閉じられたときであり、Nginx はそれをログに 499 として書き込みます。

推敲

ここでは、私が遊び始めたときと同じように、読者はほとんど知らないと仮定します。

私のセットアップは、リバース プロキシ、nginx サーバー、およびアプリケーション サーバー、その背後にある uWSGI サーバーでした。クライアントからのすべてのリクエストは nginx サーバーに送られ、uWSGI サーバーに転送され、同じ方法で応答が返されました。これは、誰もがnginx/uwsgiを使用する方法であり、使用することになっていると思います。

nginx は正常に動作しましたが、uwsgi サーバーに問題がありました。uwsgi サーバーが nginx サーバーへの応答に失敗する可能性がある 2 つの方法 (おそらくそれ以上) があります。

1) uWSGI は、「処理中です。お待​​ちください。すぐに応答があります」と表示されます。nginx には一定の時間 (fx 20 秒) があります。その後、504 エラーでクライアントに応答します。

2) uWSGI が死んでいるか、nginx が待っている間に uWSGi が死んでいる。nginx はそれをすぐに認識し、その場合は 499 エラーを返します。

クライアント（ブラウザ）でリクエストを作成してセットアップをテストしていました。ブラウザでは何も起こらず、ハングし続けました。おそらく 10 秒後 (タイムアウト未満)、何かがおかしいと判断し (これは本当でした)、コマンドラインから uWSGI サーバーを閉じました。次に、uWSGI 設定に移動し、何か新しいことを試してから、uWSGI サーバーを再起動します。uWSGI サーバーを閉じた瞬間、nginx サーバーは 499 エラーを返しました。

そのため、499 エラーでデバッグを続けました。これは、499 エラーをグーグル検索することを意味します。しかし、十分に待っていたら、504 エラーが発生していたでしょう。504 エラーが発生していれば、問題をよりよく理解してデバッグできたはずです。

結論として、問題はハングし続けた uWGSI にあったということです (「もう少し待ってください。もう少し待ってください。そうすれば答えがあります...」)。

どうやってその問題を解決したか、覚えていません。いろいろ原因が考えられます。

于 2014-12-07T22:52:49.707 に答える
19

499nginx によってログに記録された接続の中止を指します。ただし、通常、これはバックエンド サーバーが遅すぎて、別のプロキシが最初にタイムアウトするか、ユーザー ソフトウェアが接続を中止した場合に発生します。したがって、uWSGI / データベースサーバーに負荷がかかっているかどうかについて、uWSGI の応答が速いかどうかを確認してください。

多くの場合、ユーザーと nginx の間に他のプロキシがいくつかあります。CDN、Load Balacer、Varnish キャッシュなどのインフラストラクチャにあるものもあれば、キャッシング プロキシなどのユーザー側にあるものもあります。

LoadBalancer / CDN のようなプロキシが側にある場合は、タイムアウトを設定して、最初にバックエンドをタイムアウトし、徐々に他のプロキシをユーザーにタイムアウトするように設定する必要があります。

あなたが持っている場合：

user >>> CDN >>> Load Balancer >>> Nginx >>> uWSGI

設定することをお勧めします：

  • nuWSGI タイムアウトまでの秒数
  • n+1nginx タイムアウトまでの秒数
  • n+2Load Balancer にタイムアウトを送信します
  • n+3CDN へのタイムアウト秒。

一部のタイムアウト (CDN など) を設定できない場合は、そのタイムアウトを見つけて、それに応じて他のものを調整します ( n、n-1...)。

これにより、正しい一連のタイムアウトが提供されます。そして、誰がタイムアウトを与えているかを実際に見つけて、正しい応答コードをユーザーに返します。

于 2019-06-23T08:34:59.047 に答える
3

...Google検索からここに来ました

ここの他の場所で答えを見つけました-> https://stackoverflow.com/a/15621223/1093174

これは、AWS エラスティック ロード バランサーの接続アイドル タイムアウトを引き上げるためのものでした。

(nginx/apache リバース プロキシを使用して Django サイトをセットアップしましたが、本当に本当にログ バックエンド ジョブ/ビューがタイムアウトしていました)

于 2016-03-15T05:33:41.337 に答える
0

この問題が発生しましたが、原因はブラウザーの Kaspersky Protection プラグインが原因でした。これが発生した場合は、プラグインを無効にして、問題が解決するかどうかを確認してください。

于 2016-09-18T18:12:21.043 に答える