HTTP‑лимиты в Nginx, Apache и HAProxy: как правильно задать размеры тела и заголовков

HTTP‑лимиты — это не «страшные ошибки 413/431», а инструмент контроля ресурсоемкости и безопасности. Если вы сталкивались с «Payload Too Large», «Request Header Fields Too Large», внезапными 400 на фронтенде или 502 от бэкенда, почти наверняка где‑то в цепочке прокси и веб‑серверов лимиты не согласованы. В этой статье системно пройдемся по Nginx, Apache и HAProxy: какие параметры отвечают за размеры тела запроса и заголовков, как выбирать значения, где диагностировать и чем опасны несогласованные настройки.

Зачем контролировать HTTP‑лимиты

Лимиты нужны по трем причинам:

• Защита от злоупотреблений. Избыточные заголовки (огромные Cookie/User-Agent), длинные URI, слишком большие тела — все это может превращаться в DoS на памяти и диске (буферизация, временные файлы).
• Предсказуемость ресурсов. Четкие границы для заголовков и тела запроса позволяют планировать потребление RAM/IO и избежать деградации при пиках.
• Снижение класса багов. Несогласованные лимиты между балансировщиком, кэшем, WAF и апстримом вызывают неожиданные ошибки: фронт отбрасывает, а бэкенд принимает; или наоборот.

Правильная стратегия — минимально достаточные лимиты под реальную нагрузку и согласование по всей цепочке: клиент → CDN/WAF → балансировщик → reverse proxy → приложение.

Nginx: ключевые директивы и практические пресеты

client_max_body_size: предел размера тела запроса

client_max_body_size определяет максимальный размер тела HTTP‑запроса (например, загрузка файла). По умолчанию около 1m. Директиву можно задавать в контекстах http, server, location, что удобно для пер‑локальных исключений (например, для эндпоинта загрузки медиаконтента).

http {
    # Глобально ограничим до 20 МБ
    client_max_body_size 20m;

    server {
        server_name example.com;

        # Для API загрузки поднимем лимит до 200 МБ
        location /api/upload/ {
            client_max_body_size 200m;
            proxy_pass http://backend;
        }

        # Для всего остального — строже
        location / {
            client_max_body_size 10m;
        }
    }
}

Советы:

• Не задавайте «на вырост». Большой лимит увеличит риски злоупотреблений и нагрузку на дисковую буферизацию (client_body_temp_path).
• Если апстрим (например, PHP‑FPM) имеет свой лимит загрузки, согласуйте значения: чтобы Nginx отсеивал «лишнее» раньше приложения.

large_client_header_buffers и client_header_buffer_size: заголовки и первая строка

Две близкие директивы отвечают за буферизацию стартовой строки запроса и заголовков:

• client_header_buffer_size — размер первичного буфера (обычно 1k–4k+). Если не хватает, Nginx задействует large_client_header_buffers.
• large_client_header_buffers N M; где N — количество буферов, M — размер каждого (часто по умолчанию 4 8k/16k в зависимости от страницы памяти). Они используются для длинных URI и «толстых» заголовков.

http {
    # Чуть увеличим первичный буфер
    client_header_buffer_size 2k;

    # Разрешим до 4 крупных буферов по 16k
    large_client_header_buffers 4 16k;
}

Если заголовки больше — Nginx вернет 400 или 431 (в зависимости от ситуации). Слишком маленькие буферы при большом количестве/размере заголовков (например, Cookie) ведут к неожиданных 400/431 в пике.

Связанные параметры: client_body_buffer_size, client_body_timeout, таймауты и проксирование

client_body_buffer_size определяет, какой объем тела запроса попадет в память до спула на диск. Большие значения экономят IO на малых загрузках, но увеличивают RAM на соединение. client_body_timeout и client_header_timeout предотвращают медленные атаки (slowloris).

http {
    client_body_buffer_size 128k;
    client_body_timeout 15s;
    client_header_timeout 15s;
}

Если Nginx выступает как reverse proxy, обратите внимание на proxy_buffer_size (буфер ответа для заголовков) и proxy_buffers: слишком маленькие могут породить 502/504 при больших заголовках ответа (например, много Set-Cookie).

location / {
    proxy_buffer_size 16k;
    proxy_buffers 8 16k;
    proxy_busy_buffers_size 64k;
}

Практические пресеты для Nginx

• Типовой сайт: client_max_body_size 10m, client_header_buffer_size 2k, large_client_header_buffers 4 8k.
• SPA + крупные Cookie: large_client_header_buffers 4 16k.
• Загрузки медиа: для соответствующих location поднимайте client_max_body_size до 100–500m, но ограничивайте IP/аутентификацией и контролируйте client_body_timeout.

Отдельный фронтенд на полноценном сервере удобнее держать на VDS: гибче масштабирование, проще тестировать лимиты на стейджинге.

Для небольших проектов подойдет и виртуальный хостинг, если лимиты согласованы с приложением.

Apache httpd: LimitRequest* и не только

В Apache управление лимитами сосредоточено в директивах семейства LimitRequest*:

• LimitRequestBody — предел тела запроса (байты). По умолчанию 0, то есть не ограничено.
• LimitRequestFields — максимум заголовков (количество). По умолчанию 100.
• LimitRequestFieldSize — размер одного заголовка (байты). По умолчанию 8190.
• LimitRequestLine — длина стартовой строки (метод + URI + версия). По умолчанию 8190.

Их можно задавать в контексте сервера, виртуального хоста и даже для отдельных директорий/локаций. Это удобно для селективных исключений.

<VirtualHost *:80>
    ServerName example.com

    # Глобальнее и строже
    LimitRequestBody 10485760
    LimitRequestFields 100
    LimitRequestFieldSize 8190
    LimitRequestLine 8190

    # Для загрузок увеличим только тело
    <Location "/upload">
        LimitRequestBody 209715200
    </Location>
</VirtualHost>

Рекомендации:

• Не опускайте LimitRequestFields слишком низко: некоторые клиенты добавляют десятки заголовков (трекинг, SRV/корреляция, security‑метки).
• Если у вас часто длинные URI (например, фильтры отчета в GET), подумайте о переносе в POST и/или поднятии LimitRequestLine. Но лучше минимизировать длину URL.

HAProxy: tune.bufsize, максимусы заголовков и особенности HTTP/2

В HAProxy большинство ограничений упирается в размер внутреннего буфера. Ключевой параметр — tune.bufsize (по умолчанию 16384), общий для запросов и ответов. Все заголовки, стартовая строка и часть тела (если буферизуется) должны помещаться в него с запасом на переписывание.

• tune.bufsize — общий размер буфера на соединение. Поднятие до 32768 или 65536 решает проблемы с большими заголовками, но повышает RAM на соединение.
• tune.maxrewrite — запас для модификации заголовков (переписывание, добавление). По умолчанию около 1024. Если активно добавляете заголовки, увеличьте.
• tune.http.maxhdr — максимум заголовков в сообщении (по умолчанию 101). Важно при очень «шумных» клиентах или множественных Set-Cookie.

global
    tune.bufsize 32768
    tune.maxrewrite 4096
    tune.http.maxhdr 200

defaults
    mode http
    option http-buffer-request
    timeout client 30s
    timeout server 30s
    timeout connect 5s

frontend fe_http
    bind :80
    http-request deny if { hdr_len(Cookie) gt 16000 }
    use_backend be_app

backend be_app
    server s1 127.0.0.1:8080 check

Замечания:

• option http-buffer-request полезна для нормализации и проверки заголовков до проксирования.
• HAProxy не является «весовым контроллером контента» для произвольного chunked тела без доп. логики. Часто проще ограничивать тело на уровне Nginx/Apache или приложения и/или проверять Content-Length там, где это уместно.
• HTTP/2 в HAProxy декодируется в H1‑представление внутри буфера, так что лимиты по буферу все равно актуальны. HPACK‑компрессия не отменяет предельный размер декодированных заголовков.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Согласование лимитов в цепочке: CDN/WAF → HAProxy → Nginx/Apache → приложение

Самые неприятные ошибки — от несогласованности. Пример: внешний CDN разрешает заголовки до 32k, HAProxy настроен на 16k, Nginx — на 8k. Клиент с «толстой» Cookie проходит CDN, упирается в 431 на балансировщике и никогда не доходит до приложения. Обратная ситуация: балансировщик принимает большие заголовки, а Nginx режет 400 на бэкенде.

Алгоритм:

1. Определите реальные требования: максимальный размер загрузки, среднюю и пиковую длину Cookie, URI, количество заголовков, Set‑Cookie в ответе.
2. Назначьте целевые лимиты «сверху вниз»: от внешнего узла (CDN/WAF) до приложения — одинаковые или с небольшим запасом в сторону фронта.
3. Проверьте границы и поведение при превышении: куда уйдет 413/431, какой текст и страница ошибки, кто логирует первичным.

Практические сценарии и типовые значения

Загрузки файлов (медиа, документы)

Для стандартных сайтов достаточно 10–50 МБ на эндпоинтах загрузки. Для медиаплатформ — 100–500 МБ, иногда больше. Используйте отдельные location/VirtualHost с расширенными лимитами, защищайте эндпоинт авторизацией и ставьте адекватные таймауты. Важно: согласуйте с пределами приложения (например, PHP upload_max_filesize и post_max_size), чтобы ошибку отдавал внешний слой (Nginx/Apache), а не глубоко в бизнес‑логике.

Тяжелые Cookie и множество заголовков

Single‑Page‑приложения и сложная аутентификация порой накапливают десятки килобайт в Cookie. В этом случае:

• Поднимите буферы заголовков на фронте (Nginx large_client_header_buffers, HAProxy tune.bufsize).
• Проведите гигиену Cookie: уменьшите количество ключей, TTL, избегайте больших payload.
• Проверьте размер заголовков ответа (Set-Cookie) и proxy_buffer_size у Nginx.

Длинные URI и «бесконечные» GET

Фильтры и сортировки в GET склонны раздувать запросы. Лучше переводить такие операции на POST с компактным JSON. Если неизбежно — поднимайте LimitRequestLine в Apache и буферы заголовков/строки у Nginx.

Диагностика: 400, 413, 414, 431, 494

Быстрые ориентиры:

• 413 Payload Too Large — превышен client_max_body_size (Nginx) или LimitRequestBody (Apache).
• 431 Request Header Fields Too Large — слишком большие/много заголовков. У Nginx может быть 400/431 в зависимости от конкретной части.
• 414 URI Too Long — длинная стартовая строка (Apache LimitRequestLine, Nginx — буферы заголовков).
• 494 (Nginx нестандартный) — часто интерпретируется как «Request header too large» при определенных условиях.

Что смотреть в логах:

• Nginx: error.log с упоминаниями «client sent too large request»; включите уровень info/debug на проблемный сервер/локацию для воспроизведения.
• Apache: error_log сообщит о request body exceeds или request header too large.
• HAProxy: фронтенд‑логи и предупреждения о превышении буфера. Проверьте counters, errors, show info в сокете для статистики падений.

Инструменты для быстрого теста:

# Размер файла для проверки лимитов тела
fallocate -l 25M test.bin
curl -i -X POST -H "Content-Type: application/octet-stream" --data-binary @test.bin http://example.com/upload

# Проверка длинного заголовка Cookie
python3 -c "print('Cookie: x=' + 'a'*17000)" | sed 's/^/ -H "'/;s/$/"/' | xargs curl -I http://example.com

# Длинный URI
curl -I "http://example.com/?q=$(python3 -c 'print("a"*10000)')"

Безопасность и злоупотребления

Слишком щедрые лимиты открывают вектор для «header bomb» и «body bomb» атак. Несколько аспектов:

• RAM‑удар: большие буферы в HAProxy (tune.bufsize) и Nginx (large_client_header_buffers) при многих одновременных соединениях конвертируются в сотни мегабайт и гигабайты памяти.
• Диск и IO: буферизация тела на диск при медленных клиентах плюс большие лимиты — путь к высокой нагрузке на сторы.
• Slowloris и таймауты: держите client_header_timeout/client_body_timeout в адекватных пределах, а на балансировщике — агрессивнее гасите медленные соединения.
• Разнобой лимитов — фактор для классов уязвимостей на стыке протоколов (включая request smuggling). Выравнивайте правила и нормализацию заголовков на внешнем узле. Дополнительно посмотрите рекомендации в статье про заголовки безопасности: HTTP Security Headers для Nginx и Apache.

Если работаете по HTTPS, следите за валидностью сертификатов — это напрямую влияет на доверие клиентов и SEO. Для этого у нас доступны SSL-сертификаты.

Шпаргалка значений по умолчанию и ориентиры

Осторожно: значения по умолчанию зависят от версии и платформы. Ориентировочно:

• Nginx: client_max_body_size ≈ 1m; client_header_buffer_size ≈ 1k–4k; large_client_header_buffers по умолчанию 4×8k/16k (зависит от размера страницы); client_body_buffer_size ≈ 8k/16k.
• Apache: LimitRequestBody=0 (без ограничений), LimitRequestFields=100, LimitRequestFieldSize=8190, LimitRequestLine=8190.
• HAProxy: tune.bufsize=16384, tune.maxrewrite≈1024, tune.http.maxhdr=101.

Практические ориентиры для продакшена:

• Обычный сайт: тело 10–20 МБ, заголовки до 8–16 КБ, 100–150 заголовков максимум.
• Корпоративное SSO с «тяжелыми» Cookie: заголовки 16–32 КБ, контроль числа заголовков и гигиена Cookie.
• Медиасервисы: отдельные эндпоинты 100–500 МБ, строгие таймауты и квоты на пользователя/IP.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Чек‑лист внедрения

• Зафиксируйте фактические требования: максимальный upload, средний/пиковый объем заголовков и их количество.
• Согласуйте лимиты на всех слоях: внешний прокси, балансировщик, веб‑сервер, приложение.
• Настройте ответы об ошибках: единая страница/JSON для 413/431, понятное сообщение для клиентов.
• Пропишите таймауты против slow‑атак и лимиты скорости, если применимо.
• Проверка в стейджинге: сценарии с нагрузкой, длинными Cookie/URI, большими файлами, HTTP/2 и HTTP/1.1.
• Наблюдаемость: метрики 4xx по кодам, алерты по росту 413/431, семплы логов на аномалии. По кэшированию и валидации ответа поможет обзор: Cache‑Control и ETag.

Частые ошибки

• Подняли tune.bufsize в HAProxy до 64k, но забыли про RAM на пике соединений.
• Увеличили client_max_body_size в Nginx, но не синхронизировали лимиты приложения — 500/502 на апстриме.
• Игнорировали proxy_buffer_size и получили 502 на больших Set-Cookie от приложения.
• Недооценили LimitRequestFields — редкие клиенты валятся на 400 из‑за количества заголовков.
• Тестировали только HTTP/1.1, а в продакшене основная доля трафика — HTTP/2, где декодированные заголовки больше ожидаемых.

Примеры целостной настройки

Nginx (frontend) с безопасными лимитами

http {
    client_max_body_size 20m;
    client_body_buffer_size 128k;
    client_body_timeout 15s;
    client_header_timeout 15s;
    client_header_buffer_size 2k;
    large_client_header_buffers 4 16k;

    server {
        listen 80;
        server_name example.com;

        location /upload/ {
            client_max_body_size 200m;
            proxy_pass http://app;
        }

        location / {
            proxy_pass http://app;
            proxy_buffer_size 16k;
            proxy_buffers 8 16k;
        }
    }
}

Apache (backend) с согласованными LimitRequest*

<VirtualHost *:8080>
    ServerName app.internal
    LimitRequestBody 209715200
    LimitRequestFields 150
    LimitRequestFieldSize 16384
    LimitRequestLine 16384
</VirtualHost>

HAProxy (edge) с увеличенным буфером и базовой валидацией

global
    tune.bufsize 32768
    tune.maxrewrite 4096
    tune.http.maxhdr 200

defaults
    mode http
    option http-buffer-request
    timeout client 30s
    timeout server 30s
    timeout connect 5s

frontend fe
    bind :80
    # Защитимся от монструозных Cookie
    http-request deny if { hdr_len(Cookie) gt 20000 }
    default_backend be

backend be
    server s1 127.0.0.1:80 check

Итоги

HTTP‑лимиты — это про баланс: достаточно большие, чтобы не мешать нормальным клиентам, и достаточно строгие, чтобы защищать ресурсы. Начните с инвентаризации реальных потребностей, согласуйте параметры по всей цепочке, добавьте диагностируемость и постепенно уточняйте значения. Обращайте внимание на связку: client_max_body_size, large_client_header_buffers, LimitRequestBody, LimitRequestFields, LimitRequestFieldSize и tune.bufsize. Так вы избежите «мистических» 400/413/431, сэкономите время поддержки и улучшите стабильность сервиса.