nginx는 gunicorn에서 실행되는 Python 응용 프로그램의 프론트 엔드로 구성되었지만 약 65k의 데이터가 전송 된 후 nginx가 연결을 종료합니다.
예를 들어 다음과 같은 뷰가 있습니다.
def debug_big_file(request):
return HttpResponse("x" * 500000)
그러나 nginx를 통해 해당 URL에 액세스하면 65283 바이트 만 얻습니다.
$ curl https://example.com/debug/big-file | wc
…
curl: (18) transfer closed with outstanding read data remaining
0 1 65283
gunicorn에 직접 액세스하면 모든 것이 예상대로 작동합니다.
$ curl http://localhost:1234/debug/big-file | wc
…
0 1 500000
관련 nginx 설정 :
location / {
proxy_pass http://localhost:1234/;
proxy_redirect off;
proxy_headers_hash_bucket_size 96;
}
그리고 nginx 버전 1.7.0
다른 사실들 :
- 바이트 수는 요청마다 일치하지만 내용에 따라 다릅니다 (먼저 65,283이 아니라 65,372 바이트 후에 잘린 큰 PNG 파일로 알았습니다)
- 110k 바이트는 올바르게 전송
"x" * 110000
되지만 (즉, 모든 110,000 바이트를 반환) 120k 바이트는 그렇지 않습니다 tcpdump
nginx가 RST 패킷을 gunicorn에 보내고 있음을 제안합니다.
(a) gunicorn이 110k에서 120k 바이트 크기의 답글을 프레임으로 선택하는 방법과 (b) nginx가 110k에서 120k 바이트 사이의 동일한 샘플 페이로드 크기에 대해 프레이밍을 선택하는 방법을 보는 것이 도움이 될 것입니다. HTTP가 데이터를 프레임 할 수있는 세 가지 방법 : 컨텐츠 길이 제공; 청크 인코딩을 수행하십시오. 또는 몸체가 완성되었을 때 소켓을 닫을 것을 약속하는 것을 제외하고는 프레임을 전혀 제공하지 마십시오.
—
Brandon Rhodes
컨텐츠 길이 헤더가 제공되고 있습니다. 패킷 덤프로 다른 두 가지 상황이 어떻게되는지 보도록하겠습니다.
—
David Wolever
흠, 매우 이상하다. tcpdump는 nginx가 연결을 적극적으로 RST하고 있다고 제안합니다 (편집 참조). nginx도 HTTP / 1.0 및을 사용하고
—
David Wolever
Connection: close
있습니다. 또한 Content-Length
헤더가 올바른지 확인했습니다 .