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とuwsgiの間の通信であり、ブラウザーとnginxの間の通信ではありませんでした。ブラウザにサイトをロードし、十分に長い時間待っていた場合、「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にあったということです（「もう少し待ってから、もう少し待ってください。そうすれば、私が答えを出します...」）。

その問題をどのように修正したか、覚えていません。いろいろな原因が考えられます。

クライアントが接続を閉じたからといって、ブラウザの問題だとは限りません！？どういたしまして！

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エラーがある場合はそうではありません。

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

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

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

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

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

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

• n uWSGIタイムアウトまでの秒数
• n+1 nginxタイムアウトまでの秒数
• n+2 sencondsがLoad Balancerにタイムアウトする
• n+3 CDNへのタイムアウトの秒数。

タイムアウトの一部（CDNなど）を設定できない場合は、タイムアウトを確認し、それに従って他のタイムアウトを調整します（n、n-1...）。

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

私の場合、クライアントのAPIが応答を受け取る前に接続を閉じたところ、499になりました。文字通りPOSTを送信し、すぐに接続を閉じます。これはオプションによって解決されます：

proxy_ignore_client_abort on

Nginxドキュメント

実際、499は「クライアントが接続を中断した」という意味です。

クライアントの読み取りタイムアウトは60秒でした（nginxのデフォルトのproxy_read_timeoutも60秒です）。つまり、私の場合は、nginxがerror.log an upstream timed out (110: Connection timed out) while reading upstreamを発行してから、nginxが「構成したバックエンドサーバーグループ内の次のプロキシサーバー」を再試行するということです。それが複数ある場合です。

次に、（デフォルトでは）すべてを使い果たすまで次々と試行します。それぞれがタイムアウトになると、「ライブ」バックエンドサーバーのリストからも削除されます。すべてが使い果たされた後、それは504 gateway timeout.

したがって、私の場合、nginxはサーバーを「使用不可」としてマークし、次のサーバーで再試行しました。その後、クライアントの60sタイムアウトが（すぐに）発生したため、upstream timed out (110: Connection timed out) while reading upstreamログが表示され、直後に499のログが続きます。しかし、それはちょうどタイミングの一致でした。

関連：

グループ内のすべてのサーバーが現在使用不可としてマークされている場合は、502 Bad Gateway.同様に10秒間を返します。ここ max_failsとfail_timeoutを参照してください。言うログを宿しなさいno live upstreams while connecting to upstream.

サーバーグループにプロキシバックエンドが1つしかない場合は、1つのサーバーを試してみ504 Gateway Time-outます。それproxy_read_timeoutを超えると、「ライブ」サーバーのリストから1つのサーバーが削除されません。ここを参照「グループ内にサーバーが1つしかない場合、max_fails、fail_timeout、slow_startパラメータは無視され、そのようなサーバーは利用不可と見なされることはありません。」

本当にトリッキーな部分は、 "localhost"にproxy_passを指定し、ボックスにipv6とipv4の "バージョンの場所"が同時に存在する場合（ほとんどのボックスはデフォルトでデフォルトである）、サーバーグループ内の複数のサーバーの「リスト」。つまり、サーバーを1つだけリストしても、「502 for 10s」を返すという上記の状況に陥ることがあります。ここを参照「ドメイン名が複数のアドレスに解決される場合、それらのすべてがラウンドロビン方式で使用されます。」1つの回避策は、それをproxy_pass http://127.0.0.1:5001;（そのipv4アドレス）として宣言して、ipv6とipv4の両方になるのを回避することです。次に、「単一サーバーのみ」の動作としてカウントされます。

これを問題の「より少ない」ものにするために微調整できるいくつかの異なる設定があります。タイムアウトを増やすか、タイムアウトしたときにサーバーを「無効」としてマークしないようにするか、リストを修正してサイズが1のみになるようにする：上記を参照:)

参照：https : //serverfault.com/a/783624/27813

このエラーは、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サイトをセットアップしていて、本当に本当に本当にバックエンドジョブ/ビューがタイムアウトしていた）

AJAX http応答として499「アンチウイルスによってリクエストが禁止されました」（軽いヒューリスティック分析によるカスペルスキーインターネットセキュリティによる誤検知）を取得すると、ディープヒューリスティック分析は何も問題がないことを正しく認識していました。

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

この動作の理由の1つは、の代わりにhttpfor を使用しているuwsgiことですsocket。uwsgi直接使用する場合は、以下のコマンドを使用してください。

uwsgi --socket :8080 --module app-name.wsgi

.iniファイルの同じコマンドは

chdir = /path/to/app/folder
socket = :8080
module = app-name.wsgi

これはOPの質問には答えられませんが、私は熱心に答えを検索した後、ここにたどり着いたので、私が発見したことを共有したいと思いました。

私たちのケースでは、これらの499が予想されることがわかりました。たとえば、ユーザーが一部の検索ボックスで先行入力機能を使用すると、ログに次のようなものが表示されます。

GET /api/search?q=h [Status 499] 
GET /api/search?q=he [Status 499]
GET /api/search?q=hel [Status 499]
GET /api/search?q=hell [Status 499]
GET /api/search?q=hello [Status 200]

したがって、私たちのケースproxy_ignore_client_abort onでは、前の回答で提案された使用が安全だと思います。それをありがとう！

私は有効にしていましたufwが、アップストリームポートを公開するのを忘れていました。

私の場合、私は次のような設定をしています

AWS ELB >> ECS(nginx) >> ECS(php-fpm).

ECS（php-fpm）サービスに間違ったAWSセキュリティグループを設定していたため、nginxはphp-fpmタスクコンテナーにアクセスできませんでした。そのため、nginxタスクログでエラーが発生しました

499 0 - elb-healthchecker/2.0

ヘルスチェックは、php-fpmサービスをチェックし、稼働していることを確認して応答を返すように構成されていました。

私はこれが古いスレッドであることを知っていますが、最近起こったことと完全に一致しているので、ここでドキュメント化すると思いました。（Dockerでの）セットアップは次のとおりです。

• nginx_proxy
• nginx
• 実際のアプリを実行しているphp_fpm。

症状は、アプリケーションログインプロンプトの「502ゲートウェイタイムアウト」でした。見つかったログの検査：

• ボタンは、HTTP経由で作品POSTに/login...とそう...
• nginx-proxyが/loginリクエストを受け取り、最終的にタイムアウトを報告しました。
• nginxは499応答を返しましたが、これはもちろん「ホストが死んだ」ことを意味します。
• /login要求がまったく表示されませんでした（！） FPMサーバのログに！
• FPMにはトレースバックやエラーメッセージはありませんでした... nada、zero、zippo、none。

問題は、ログインを検証するためのデータベースへの接続の失敗であることが判明しました。しかし、それを理解する方法は、純粋な当て推量であることがわかりました。

アプリケーショントレースバックログの完全な欠如...またはFPMによって要求が受信されたというレコードさえ...完全に（そして破壊的な...）驚きでした。はい、アプリケーションは障害をログに記録することになっていますが、この場合、FPMワーカープロセスがランタイムエラーで終了し、499nginx からの応答に至ったようです。さて、これは明らかに私たちのアプリケーションの問題です...どこかで。しかし、私はこのような何かに直面している次の人々のために何が起こったかの詳細を記録したかったのです。