属于“边注”类别的文章。
在一个项目中，更改了一些内部后端逻辑后，我开始在日志中观察到一个奇怪的response_code，即0。在日志中，它看起来像这样：
{ "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_的缓冲区大小，在我们的案例中，这不适合“ no way”一词。
总体上，他们认为问题不是问题，因为从我们的角度来看，这绝对不是关键。
直到我对以下问题感到困惑为止：在某些情况下，链接可以通过http打开而不会出现问题，但是完全拒绝通过https进行工作，这提供了一个奇妙的效果：与example.com主机的连接＃0保持不变
curl：（52）来自服务器的空回复
可以仅通过IP在日志中跟踪此内容-如上例所示，没有请求或任何其他数据。 只有臭名昭著的状态0，但我知道我没有中断请求！ 我开始选择可能出问题的地方。 一切都变得非常简单：
监听443 ssl http2 backlog = 8192;好吧，如果您使用http2进行ssl连接，仅配置请求缓冲区是不够的，还必须在ngx_http_v2_module中进行配置，即：
: http2_max_field_size ; : http2_max_field_size 4k; : http, server
限制使用HPACK压缩的请求标头的最大大小。 该限制对名称和值均适用。 如果使用霍夫曼编码，则名称和值的解压缩字符串的实际大小可能会更大。 默认限制适用于大多数查询。总的来说就是这样。 又为什么呢？ 因为链接的长度很长-超过了相同的4k。
将其放入例如8kb（或足够多的大小）中-我们解决了这个问题。
这样的事情。