【Nginx】response_status = 0を倒す方法

「余談」カテゴリの記事です。

TL:DR:

http2_max_field_size 8k; # всех спасет!

プロジェクトの 0 つで、バックエンドの内部ロジックを変更した後、ログに奇妙な応答コード、つまり XNUMX が表示され始めました。ログには次のように表示されます。

{
  "timestamp": "2020-01-17T08:41:51+00:00",
  "remote_addr": "zzz.zzz.zzz.zzz",
  "request_time": 0,
  "upstream_response_time": "",
  "upstream_header_time": "",
  "http_accept_language": "-language",
  "response_status": 0,
  "request": "",
  "host": "example.com",
  "upstream_addr": "",
  "http_referrer": "",
  "request_length": 5854,
  "bytes_sent": 0,
  "http_user_agent": ""
}


ドキュメントを読んだり、このトピックについてグーグルで検索したりしても、まったく何も見つかりませんでした。なぜなら... この動作は、クライアントがヘッダーを渡さずに接続を閉じたときに発生すると述べられています。 さて、wsgi_ のバッファ サイズに関するさまざまな珍しい問題もありますが、私たちの場合は「とにかく」という言葉には当てはまりませんでした。

一般的に、私たちの量ではまったく重大ではないという事実を考慮して、この問題は問題ではないと判断しました。

まさに、私が次の問題に困惑するまでは、http 経由ではリンクが問題なく開く場合がありますが、https 経由では機能することを完全に拒否し、素晴らしい結果が生じます。ホスト example.com への接続 #0 がそのまま残されます。
カール: (52) サーバーからの空の応答

ログでは、この問題を IP によってのみ追跡できました。上記の例からわかるように、リクエストやその他のデータはありませんでした。 悪名高いステータスだけが 0 ですが、要求を中断していないことはわかっています。 何が問題になるのかを考え始めました。 そして、すべてが非常に単純であることが判明しました。

443 SSLを聞く http2 バックログ=8192;

ssl 接続に http2 を使用する場合、リクエスト バッファを設定するだけでは十分ではなく、ngx_http_v2_module 内でも設定する必要があります。つまり、次のようになります。

Синтаксис:	http2_max_field_size размер;
Умолчание:	http2_max_field_size 4k;
Контекст:	http, server

HPACK を使用して圧縮されたリクエスト ヘッダーの最大サイズを制限します。 制約は名前と値の両方に等しく適用されます。 ハフマン エンコーディングが使用される場合、解凍された名前と値の文字列の実際のサイズはさらに大きくなる可能性があります。 デフォルトの制限は、ほとんどのクエリに適しています。

一般的にはこれです。 そしてなぜ全部? リンクの長さが同じ 4k よりも長かったためです。

たとえば 8kb (または十分と思われる大きさ) に設定することで、問題は解決します。
そんなこと。

出所: habr.com

コメントを追加します