Nginx 499エラーコード
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設定に何の問題もないことを望んでいます。私は額面でそれを取っています...それは私の問題ではありません..そのクライアントの問題。
ありがとう
NginxのHTTP 499は、サーバーがリクエストに応答する前にクライアントが接続を閉じたを意味します。私の経験では、通常はクライアント側のタイムアウトが原因です。私が知っているように、それはNginx固有のエラーコードです。
私の場合、私は焦ってログを誤解してしまいました。
実際、実際の問題は、ブラウザとnginxの間ではなく、nginxとuwsgiの間の通信でした。ブラウザにサイトをロードし、十分な時間待っていた場合、「504-Bad Gateway」になります。しかし、それは非常に時間がかかったので、私は何かを試し続け、ブラウザで更新しました。そのため、504エラーが表示されるまで待つことはありませんでした。ブラウザで更新するとき、つまり前のリクエストが閉じられると、Nginxはそれを499としてログに書き込みます。
精緻化
ここでは、私が遊んで始めたとき、読者が私と同じように知っていると仮定します。
私のセットアップは、リバースプロキシ、nginxサーバー、およびアプリケーションサーバー、その背後にあるuWSGIサーバーでした。クライアントからのすべてのリクエストはnginxサーバーに送られ、その後uWSGIサーバーに転送され、その後同じ方法で応答が送信されます。これは誰もがnginx/uwsgiを使用する方法であり、それを使用することになっていると思います。
私のnginxは正常に機能しましたが、uwsgiサーバーに何か問題がありました。 uwsgiサーバーがnginxサーバーへの応答に失敗する可能性がある2つの方法（おそらくそれ以上）があります。
1）uWSGIは、「処理中です。しばらくお待ちください。すぐに応答があります」と言います。 nginxには一定の期間があり、20秒間待機します。その後、504エラーでクライアントに応答します。
2）uWSGIが死んでいるか、nginxがそれを待っている間にuWSGiが死んだ。 nginxはすぐにそれを確認し、その場合、499エラーを返します。
クライアント（ブラウザー）で要求を行うことにより、セットアップをテストしていました。ブラウザでは何も起こりませんでした。おそらく10秒後（タイムアウト未満）、何かが正しくないと判断し（これは正しい）、コマンドラインからuWSGIサーバーを閉じました。次に、uWSGI設定に移動し、新しいことを試してから、uWSGIサーバーを再起動します。 uWSGIサーバーを閉じると、nginxサーバーは499エラーを返します。
だから、私は499エラーでデバッグを続けました。つまり、499エラーをグーグルで調べます。しかし、私が十分長く待っていたら、504エラーが発生したでしょう。 504エラーが発生した場合、問題をよりよく理解し、デバッグすることができたはずです。
結論は、問題はハングし続けていたuWGSIにあったということです（「もう少し待ってください、もう少し待ってください、それから私はあなたのために答えがあります...」）。
修正方法that問題、覚えていない。それは多くのことが原因だと思います。
クライアントが接続を閉じたそれはブラウザの問題だという意味ではありません！？どういたしまして！
AWSまたはhaproxy（カスタム）のWebサーバー（nginx）の前にLB（ロードバランサー）がある場合、ログファイルで499エラーを見つけることができます。つまり、LBはnginxのクライアントとして機能します。
以下に対してhaproxyのデフォルト値を実行する場合：
timeout client 60000
timeout server 60000
これは、nginxからの応答がない場合、LBが60000ms後にタイムアウトすることを意味します。実行にさらに時間が必要な忙しいWebサイトまたはスクリプトでは、タイムアウトが発生する場合があります。あなたのために働くタイムアウトを見つける必要があります。たとえば、次のように拡張します。
timeout client 180s
timeout server 180s
そして、おそらく設定されます。
設定によっては、ブラウザに504ゲートウェイタイムアウトエラーが表示されることがあります。これは、php-fpmに問題があることを示していますが、ログファイルに499エラーがある場合はそうではありません。
私の場合、クライアントのAPIが応答を得る前に接続を閉じたときに499を得ました。文字通りPOSTを送信し、すぐに接続を閉じました。これはオプションによって解決されます：
proxy_ignore_client_abort on
このエラーは、php-fpmで標準のnginx設定を使用して再現するのが非常に簡単です。
ページ上でF5ボタンを押し続けると、サーバーに対する多数の更新要求が作成されます。以前の各リクエストは、新しい更新時にブラウザによってキャンセルされます。私の場合、クライアントのオンラインショップのログファイルで499を数十個見つけました。 nginxの観点から：次の更新要求の前に応答がクライアントに配信されていない場合、nginxは499エラーをログに記録します。
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:32 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:35 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:35 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
Php-fpmの処理に時間がかかる（重いWPページなど）場合、もちろん問題が発生する可能性があります。たとえば、php-fpmのクラッシュについて聞いたことがありますが、xmlrpc.phpの呼び出しを処理するようなサービスの適切な設定を防ぐことができると思います。
...グーグル検索からここに来た
私はここで他の場所で答えを見つけました-> https://stackoverflow.com/a/15621223/1093174
これは、AWS Elastic Load Balancerの接続アイドルタイムアウトを上げることでした！
（nginx/Apacheリバースプロキシを使用してDjangoサイトをセットアップしましたが、本当に本当に本当にバックエンドのジョブ/ビューのログがタイムアウトしました）
この問題が発生しましたが、原因はブラウザーのKaspersky Protectionプラグインが原因でした。この問題が発生した場合は、プラグインを無効にして、問題が解決するかどうかを確認してください。
499をポイントすると、nginxによってログに記録された接続の中断。 ただし、これは通常、バックエンドサーバーが遅すぎる場合に生成されます、および別のプロキシが最初にタイムアウトするか、ユーザーソフトウェアが接続を中止します。したがって、uWSGIが高速に応答しているかどうか、またはuWSGI /データベースサーバーに負荷がかかっているかどうかを確認してください。
多くの場合、ユーザーとnginxの間に他のプロキシがいくつかあります。 CDN、ロードバラサー、ワニスキャッシュなど、インフラストラクチャに存在するものもあれば、キャッシングプロキシなどのユーザー側に存在するものもあります。
LoadBalancer/CDNのようなプロキシがあなたの側にある場合...最初にバックエンドをタイムアウトし、ユーザーへの他のプロキシを徐々にタイムアウトするようにタイムアウトを設定する必要があります。
あなたが持っている場合：
user >>> CDN >>> Load Balancer >>> Nginx >>> uWSGI
以下を設定することをお勧めします。
- __WS_タイムアウトまでの
n秒 - nginxタイムアウトまでの
n+1秒 - 「n + 2」はロードバランサーのタイムアウトを検知します
- CDNに対する
n+3秒のタイムアウト。
タイムアウトの一部（CDNなど）を設定できない場合は、タイムアウトが何であるかを見つけ、それに応じてその他を調整します（n、n-1...）。
これにより、タイムアウトの正しいチェーンが提供されます。そして、あなたは本当に誰がタイムアウトを与え、ユーザーに正しい応答コードを返すかを見つけるでしょう。
この動作の理由の1つは、httpの代わりにuwsgiにsocketを使用していることです。 uwsgiを直接使用している場合は、以下のコマンドを使用します。
uwsgi --socket :8080 --module app-name.wsgi
.iniファイル内の同じコマンドは
chdir = /path/to/app/folder
socket = :8080
module = app-name.wsgi
499 "リクエストはアンチウイルスによって禁止されています" AJAX http応答として（軽度のヒューリスティック分析を使用したKaspersky Internet Securityによる誤検知、深層ヒューリスティック分析では何もなかったことが正しく認識されました）違う）。