400 Bad Request: Request Header or Cookie Too Large в Nginx — как исправить

kirilljsx

Ошибка 400 Bad Request: Request Header or Cookie Too Large в Nginx возникает, когда заголовки запроса или куки превышают лимиты сервера. Это частая проблема в веб-приложениях с большим количеством сессионных данных или аналитики. В этой статье разберём причины, диагностику и способы решения, чтобы ваш сайт работал стабильно.

Знание этих нюансов поможет быстро локализовать проблему и избежать простоев. Мы пройдёмся по настройкам Nginx, оптимизации куки и клиентским хитростям. Всё с примерами конфигов и таблицами для ясности.

Что значит эта ошибка и почему она появляется

Сервер Nginx возвращает 400 Bad Request, когда размер заголовков HTTP-запроса или куки превышает внутренние буферы. По умолчанию Nginx выделяет небольшие буферы для заголовков — обычно 1 КБ на основной и 8 КБ на дополнительные. Если браузер шлёт много куки (сессии, JWT-токены, аналитика), общий размер headers растёт и упирается в лимит.

В реальных проектах это случается с приложениями на Next.js с Auth0, Shopify-магазинами или сайтами с кучей трекеров. Браузеры вроде Chrome лимитируют куки до 4 КБ на домен, но сервер может “захлебнуться” уже на 2-3 КБ общих headers. Проблема усиливается, если юзер накапливает куки со временем — в инкогнито всё работает, а в обычном профиле ошибка выскакивает.

Вот типичные сценарии:

Сессионные куки с JWT-токенами в 1-2 КБ.
Аналитика и consent-куки от GDPR-баннеров (до 500 байт на штуку).
Корзины e-commerce или preferences, хранящиеся в cookies вместо сервера.

Лимиты по умолчанию в Nginx

Параметр	Значение по умолчанию	Когда срабатывает
client_header_buffer_size	1 КБ	Основной буфер для headers
large_client_header_buffers	4 x 8 КБ	Дополнительные буферы
Куки на домен (Chrome)	4 КБ на куки	Клиентский лимит

Общий размер headers редко превышает 16 КБ даже в тяжёлых кейсах, но дефолтные настройки Nginx не справляются.

Диагностика: как понять, что headers слишком большие

Сначала проверьте логи Nginx — там будет запись вроде “client sent too long header line” или напрямую “400 Bad Request: Request Header or Cookie Too Large”. Используйте curl с флагом -v для теста запроса или браузерные devtools (Network tab), чтобы увидеть размер headers.

В реальности разработчики часто видят это на проде: сайт падает для части юзеров, но в incognito ок. Причины — накопленные куки от аналитики, A/B-тестов или SDK вроде Auth0, где сессии шифруются и раздуваются до 8 КБ. Ещё один признак: ошибка интермиттирующая, исчезает после очистки кэша.

Шаги для диагностики:

Проверьте размер куки в devtools: F12 → Application → Cookies.
Симулируйте в curl: curl -v -H "Cookie: имя=длинное_значение" https://your-site.com.
Логи Nginx: tail -f /var/log/nginx/error.log | grep "too large".
Мониторинг: инструменты вроде NGINX Amplify покажут пиковые нагрузки на буферы.

Разбивка типичных куки по размеру

Тип куки	Средний размер	Можно оптимизировать?
Session ID	32-64 байт	Нет
JWT Token	800-2000 байт	Да, refresh-токены
CSRF	32-64 байт	Нет
Analytics	200-800 байт	Да, консолидация
Preferences	100-500 байт	Да, на сервер
Cart	500-5000 байт	Да, Redis

GDPR-куки от баннеров добавляют overhead — каждый consent генерит новые 500+ байт.

Настройка Nginx: увеличиваем буферы

Основное решение — поднять лимиты в конфиге Nginx. В блоке http или server добавьте директивы для буферов. Стандартный апгрейд: client_header_buffer_size 4k; и large_client_header_buffers 4 16k;. Это покроет 99% случаев без риска для безопасности.

В production на высоконагруженных сайтах лимит ставят до 32k-64k, но мониторят логи. Не забывайте перезагрузить Nginx: nginx -t && nginx -s reload. Если хостинг shared (Shopify-like), то настройки сервера недоступны — переходите к клиентским фиксам.

Пример конфига:

http {
    client_header_buffer_size 4k;
    large_client_header_buffers 4 16k;
    # Для особо жирных headers
    large_client_header_buffers 8 32k;
}

Рекомендации по настройке:

Начните с 4k/16k — хватит для JWT и аналитики.
Мониторьте error.log после изменений.
Ограничьте по IP, если DDoS-подозрения: limit_req_zone.
HTTPS only: headers меньше сжимаются в TLS.

Сравнение дефолтных и оптимизированных лимитов

Сценарий	Дефолт (ошибка)	Оптимизировано (OK)
10 куки по 300б	3 КБ → 400	16 КБ → проходит
JWT + Auth0	5-8 КБ → 400	32 КБ → проходит
E-commerce cart	10 КБ → 400	64 КБ → проходит

Оптимизация куки и приложений

Не всегда можно ковырять Nginx — оптимизируйте клиент. Храните минимум в cookies: session ID, CSRF и минимум auth. JWT разбейте на access/refresh, аналитику вынесите в localStorage или сервер. Используйте HttpOnly и Secure флаги для безопасности.

В фреймворках вроде Next.js с Auth0 проблема в SDK — сессии шифруются и жирнеют. Решение: кастомные хендлеры или переход на server-side sessions. Для e-commerce корзины в Redis вместо cookies сэкономят гигабайты трафика.

Практические шаги:

Очистите ненужные куки: удалите expired или debug.
Консолидируйте: один куки для аналитики вместо 5.
Сервер-сайд storage: Redis/Session для тяжёлых данных.
Cookie prefix: __Host- для строгих лимитов.

LocalStorage не идёт в headers, но не для sensitive data.

Когда лимиты не спасают: продвинутые приёмы

Если буферы на максимуме, смотрите вглубь стека. Прокси перед Nginx (Cloudflare) может сжимать headers. В браузере force-clear cookies на ошибке через JS. Для legacy-приложений — миграция на token-based auth без куки.

В высоконагруженных системах лимиты держат жёстко: 16 КБ max, с автоочисткой. Тестируйте под нагрузкой с Artillery или Locust, симулируя 100 куки на юзера. Это предотвратит регресс.

Баланс производительности и лимитов в Nginx

Ошибка 400 от больших headers решается комбо из Nginx-настроек и оптимизации приложений. Главное — мониторить размеры и не хранить лишнее в cookies. Осталось учесть кейсы с мобильными браузерами, где лимиты строже, или кластеры с балансировкой.

Дальше думайте о метриках: сколько реально тратит ваш трафик на headers и как это влияет на latency.