nginx припиняє з'єднання після 65 кбайт

У мене nginx налаштований як передній додаток для програми Python, що працює під рушницею, але nginx припиняє з'єднання після того, як було надіслано близько 65 к даних.

Наприклад, у мене є вид, який виглядає приблизно так:

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

Але коли я отримую доступ до цієї URL-адреси через nginx, я отримую лише 65283 байти:

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

Зауважте, що все працює так, як очікувалося, коли ви отримуєте прямий доступ до зброї:

$ 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

Деякі інші факти:

Кількість байтів узгоджується з запитом на запит, але вона змінюється залежно від вмісту (я вперше помітив це у великому файлі PNG, який був відрізаний після 65 372 байт, а не 65 283)
110k байтів надсилаються правильно (тобто "x" * 110000повертає всі 110 000 байт), але 120k байтів - ні
tcpdump припускає, що nginx надсилає RST-пакет для gunicorn:

nginx gunicorn

— Девід Уолвер
джерело

Було б корисно побачити (a) яким чином gunicorn вибирає кадр розміром від 110 до 120 кбайт, і (b) як nginx потім вибирає обрамлення для того ж діапазону розмірів вибіркової корисної навантаження між 110 к і 120 к байт. Три способи, яким HTTP може обрамляти дані: надавати довжину вмісту; робити кодоване кодування; або взагалі не надавати рамки, окрім обіцянки закрити розетку, коли корпус буде завершений.

— Брендон Родос

Надається заголовок довжини вмісту. Дозвольте мені

— перенести

Хрм, дуже дивно. tcpdump припускає, що nginx активно RST-іє з'єднання (див. редагування). nginx також використовує HTTP / 1.0 та Connection: close. Я також підтвердив, що Content-Lengthзаголовок правильний.

— Девід Уолвер

Добре! Після подвійної перевірки журналів nginx це виявилося проблемою:

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"

Деякі способи дозволу для proxy_tempкаталогу змішалися, що не дозволило nginx належним чином забуферувати його.

— Девід Уолвер
джерело

Так, я просто вирішив подібну проблему, заглянув у журнали nginx, мав рядок, що містить

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

, зробив sudo chown -R www-data:www-data /var/lib/nginx/і це виправлено.

— Епіген