[Nginx] response_status = 0을 해제하는 방법

"사이드노트" 카테고리에 속하는 글입니다.

TL : DR :

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

프로젝트 중 하나에서 백엔드의 일부 내부 로직을 변경한 후 로그에서 이상한 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_에 대한 버퍼 크기를 가진 다양한 이국적인 것들이 있는데, 우리의 경우에는 "어떤 식으로든"이라는 단어에 맞지 않습니다.

일반적으로 우리는 문제가 우리 볼륨에서는 전혀 중요하지 않다는 사실을 고려하여 문제가 문제가 아니라고 결정했습니다.

정확히 다음 문제 때문에 당황했습니다. 어떤 경우에는 링크가 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