nginx 65k bayttan sonra bağlantıyı sonlandırır

Gungin altında çalışan bir Python uygulaması için ön uç olarak yapılandırılmış nginx var, ancak nginx yaklaşık 65k veri gönderildikten sonra bağlantıları sonlandırıyor.

Örneğin, şöyle bir görünüm var:

def debug_big_file(request):
    return HttpResponse("x" * 500000)

Ancak bu URL'ye nginx aracılığıyla eriştiğimde yalnızca 65283 bayt alıyorum:

$ curl https://example.com/debug/big-file | wc
…
curl: (18) transfer closed with outstanding read data remaining
   0       1   65283

Gunicorn'a doğrudan erişirken her şeyin beklendiği gibi çalıştığını unutmayın:

$ curl http://localhost:1234/debug/big-file | wc
…
   0       1   500000

İlgili nginx yapılandırması:

location / {
    proxy_pass http://localhost:1234/;
    proxy_redirect off;
    proxy_headers_hash_bucket_size 96;
}

Ve nginx sürüm 1.7.0

Diğer bazı gerçekler:

Bayt sayısı, istek isteğinden tutarlıdır, ancak içeriğe göre değişir (önce 65,283 değil, 65,372 bayttan sonra kesilen büyük bir PNG dosyası ile fark ettim)
110 bin bayt doğru bir şekilde gönderilir (yani, "x" * 110000110.000 baytın tümünü döndürür), ancak 120 bin bayt
tcpdump nginx'in gunicorn'a bir RST paketi gönderdiğini gösteriyor:

nginx gunicorn

— David Wolever
kaynak

(A) gunicorn'un 110k ila 120k bayt boyutundaki cevapları nasıl çerçevelemeyi seçtiğini ve (b) nginx'in 110k ila 120k bayt arasındaki aynı örnek taşıma kapasitesi aralıkları için çerçevesini nasıl seçtiğini görmek yararlı olacaktır. HTTP'nin verileri çerçevelemesinin üç yolu: içerik uzunluğu sağlamak; yığın kodlama yapmak; veya gövde tamamlandığında soketi kapatmayı vaat etmek dışında hiçbir çerçeve vermeyin.

— Brandon Rhodes

İçerik uzunluğu başlığı sağlanıyor. Aksi halde ikisi arasında neler olup bittiğini görmek için paket dökümü yapmama izin ver…

— David Wolever

Hrm, çok garip. tcpdump, nginx'in bağlantıyı aktif olarak RST yapıyor olduğunu önerir (düzenlemeye bakınız). nginx ayrıca HTTP / 1.0 ve Connection: close. Ayrıca Content-Lengthbaşlığın doğru olduğunu onayladım .

— David Wolever

Tamam! Nginx günlüklerini iki kez kontrol ettikten sonra, sorun ortaya çıktı:

2014/05/26 16:50:56 [crit] 31396#0: *11 open() "…/proxy_temp/2/00/0000000002" failed (13: Permission denied) while reading upstream, client: 1.2.3.4, server: _, request: "GET /debug/big-file HTTP/1.1", upstream: "http://127.0.0.1:1234/debug/big-file", host: "example.com"

Bazı proxy_tempdizinlerin izinlerinin nasıl karıştığı nginx'in ona doğru arabelleğe alınmasını engelledi.

— David Wolever
kaynak

Evet, sadece böyle bir problemi çözdüm, nginx günlüklerine baktım, içeren bir satırım vardı

[crit] 6636#0: *16817 open() "/var/lib/nginx/proxy/7/03/0000000037" failed (13: Permission denied) while reading upstream

, yaptı sudo chown -R www-data:www-data /var/lib/nginx/ve düzeltildi.

— Epigene