Ошибка 400 Bad Request с текстом Request Header Or Cookie Too Large в Nginx всплывает «вдруг»: после установки плагина авторизации, подключения SSO, включения A/B‑тестов, добавления CDN/WAF или просто из-за накопившихся cookie у активных пользователей.
Суть одна: Nginx не смог прочитать или буферизовать HTTP‑заголовки запроса (включая Cookie), потому что их общий размер или длина одной строки превысили лимиты. Ниже — практичная схема: где именно упирается Nginx, как корректно настроить large_client_header_buffers и client_header_buffer_size, и что делать, если раздувание происходит на reverse proxy.
Как устроены лимиты заголовков в Nginx (и почему 400 появляется внезапно)
Nginx читает стартовую строку и заголовки запроса в буферы. Если один из заголовков (часто это Cookie) слишком длинный, либо суммарно заголовков «слишком много и слишком жирно», Nginx вернёт 400 ещё до проксирования на бэкенд и до обработки приложением.
На практике к росту заголовков чаще всего приводит:
Big cookie: приложение кладёт в cookie JWT/сессию/настройки; появляются дубли или «хвосты» после миграций.
SSO/OAuth2/OIDC: токены и служебные параметры раздувают заголовки или cookie.
Цепочка прокси: CDN → WAF → LB → Nginx добавляет
X-Forwarded-*, трассировку и метки.Маркетинг/аналитика: множество трекерных cookie, иногда на нескольких доменах/поддоменах.
Некорректная очистка после смены домена/пути/флагов
Secure/SameSite, когда браузер хранит несколько вариантов одного имени.
Почти всегда это не «трафик» и не бэкенд: запрос отсекается на фронте Nginx на этапе чтения заголовков.
Быстрая диагностика: где именно ломается запрос
1) Находим подсказку в error.log
Обычно в error.log есть прямое указание. Ищите “client sent too large request header” или упоминание cookie.
sudo tail -n 200 /var/log/nginx/error.logЕсли логов много, фильтруйте по ключевым словам:
sudo grep -E "too large request header|Request Header Or Cookie Too Large|cookie" /var/log/nginx/error.log | tail -n 502) Проверяем, что 400 отдаёт именно Nginx
Если 400 прилетает мгновенно и вы не видите проксирования на upstream (в access‑логе нет характерных признаков маршрутизации на бэкенд), это почти наверняка лимит заголовков.
Быстрый запрос на заголовки ответа:
curl -I -sS localhost/ 2>/dev/null | headДальше важно понять масштаб: ошибка только у части пользователей (типично для раздутых cookie) или у всех (часто после добавления новых заголовков на прокси).
3) Прикидываем размер Cookie и других заголовков
Самый частый виновник — огромный Cookie. Возьмите проблемный запрос из DevTools браузера (Network) и оцените длину cookie (или всего набора заголовков).
Если у вас есть строка (значение cookie или весь заголовок), можно посчитать размер в байтах так:
python3 - <<'PY'
import sys
s = sys.stdin.read()
print(len(s.encode('utf-8')))
PYНе логируйте cookie/токены в проде «просто так»: это почти всегда персональные данные и секреты. Для диагностики лучше использовать точечные замеры и короткое окно времени.
Какие директивы отвечают за лимиты: large_client_header_buffers и client_header_buffer_size
Параметры задаются обычно в контексте http или server. Для лимитов заголовков логичнее на уровне http (чтобы поведение было единым), но если проблема только у одного виртуального хоста — ограничивайте в server.
client_header_buffer_size
client_header_buffer_size — базовый размер буфера для чтения заголовков запроса. Если конкретный заголовок не помещается, Nginx пытается задействовать «большие буферы» из large_client_header_buffers.
large_client_header_buffers
large_client_header_buffers задаёт количество и размер дополнительных буферов для чтения больших заголовков. Формат: large_client_header_buffers <число> <размер>;. Например, 4 буфера по 16k.
Практическая интерпретация ошибки request header or cookie too large такая: не хватило либо размера одного большого буфера для «длинной строки», либо суммарного числа буферов, когда заголовков много.
Поднимать буферы «с запасом на мегабайты» — плохая идея: это увеличивает потенциальное потребление памяти на соединение и расширяет поверхность для DoS через огромные заголовки. Поднимайте умеренно и параллельно чините первопричину.
Рабочие настройки: как увеличить буферы без лишнего риска
Типовой осторожный шаг: поднять размер до 16k или 32k и число буферов до 4–8. Точные значения зависят от реальных заголовков, HTTP/2, наличия SSO и количества служебных заголовков от промежуточных прокси.
Пример для http-блока
http {
client_header_buffer_size 8k;
large_client_header_buffers 4 16k;
# остальная конфигурация
}Пример для конкретного server (если проблема только на одном сайте)
server {
listen 80;
server_name example.com;
client_header_buffer_size 8k;
large_client_header_buffers 4 16k;
location / {
proxy_pass http://backend;
}
}Проверьте синтаксис и примените конфигурацию:
sudo nginx -tsudo systemctl reload nginxЕсли после 4 16k ошибка ушла — хорошо. Если нет, не прыгайте сразу на «128k навсегда»: найдите конкретный заголовок, который раздувается, и устраните причину.
Если вы используете reverse proxy: почему «лишние» заголовки съедают буферы
В цепочках с CDN/WAF/LB проблема часто выглядит так: приложение «нормальное», cookie «вроде обычные», но на вход Nginx прилетает слишком много служебных заголовков. Частые источники:
CDN/WAF добавляет трассировку, идентификаторы защиты, отпечатки браузера.
Балансировщик накапливает длинные цепочки
X-Forwarded-For(если никто не нормализует заголовок).Несколько прокси по пути дублируют заголовки разными именами.
Практика: контролируйте X-Forwarded-For и real IP
X-Forwarded-For легко превращается в «колбасу» на десятки IP. На каждом звене важно либо добавлять адрес корректно, либо (если модель доверия позволяет) перезаписывать заголовок, чтобы он не разрастался бесконтрольно.
На стороне Nginx как обратного прокси обычно используют proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;. Но если перед вами уже стоит доверенный балансировщик, иногда правильнее строить схему с real_ip (доверенные подсети) и нормализацией заголовков на входе. Делайте изменения аккуратно: ошибка здесь ломает «реальный IP» и может повлиять на ACL/лимиты/логи.
Если проблема возникла после переезда или смены домена/схемы (HTTP → HTTPS), полезно проверить, не расплодились ли у клиентов разные варианты cookie из-за Domain/Path и редиректов. В таком сценарии пригодится материал про миграции и HSTS: миграция домена, 301 и HSTS.
Почему лучше чинить big cookie в приложении, а не бесконечно увеличивать буферы
Увеличение large_client_header_buffers — быстрый способ погасить инцидент, но первопричина часто остаётся: приложение складывает слишком много данных в cookie.
Типовые анти‑паттерны:
Хранить в cookie профиль пользователя, набор фич-флагов или огромный JWT с множеством claims.
Дублировать данные в нескольких cookie с разными
PathиDomain.Оставлять «старые» cookie после переезда/смены префикса и не делать явную очистку.
Что сделать со стороны приложения
Провести инвентаризацию cookie: какие реально нужны, какие можно удалить/укоротить.
Перенести «тяжёлые» данные из cookie в server-side сессию (Redis/БД) и хранить в cookie только короткий идентификатор.
Если используете JWT — сократить payload, убрать лишние claims, проверить, не кладёте ли вы токен одновременно в cookie и в заголовок
Authorization.Настроить корректную очистку cookie при log out и при смене домена/пути.
Риски и тонкости: память, атаки и побочные эффекты
Чем больше буферы заголовков, тем больше потенциальное потребление памяти на соединение. Это повышает чувствительность к сценариям, когда клиент держит много соединений и шлёт большие заголовки. Поэтому:
Увеличивайте значения ровно настолько, насколько нужно по факту.
Держите включёнными разумные лимиты на соединения/частоту запросов и защиту от «медленных клиентов» (настройки зависят от вашей архитектуры).
Проверяйте, что после изменений не начали проходить явно мусорные запросы, которые раньше отсеивались автоматически.
Чек-лист: как устранить nginx 400 из-за заголовков за 15 минут
Найдите запись в
error.logи убедитесь, что это лимит заголовков.Определите, что раздувается:
Cookieили reverse proxy headers (частоX-Forwarded-For).Временно увеличьте
large_client_header_buffers(например, до4 16k) иclient_header_buffer_size(до8k), затем примените конфиг.Параллельно исправьте первопричину: сократите cookie, нормализуйте заголовки на прокси, устраните дубли.
Вернитесь через день и пересмотрите значения буферов: возможно, их можно уменьшить обратно.
Частые вопросы
Можно ли просто поставить большие значения и забыть?
Технически можно, но это увеличивает потребление памяти и делает фронт менее устойчивым к злоупотреблениям большими заголовками. Правильнее: умеренно поднять лимиты и устранить источник big cookie или разрастания заголовков.
Почему ошибка появляется только у части пользователей?
Cookie индивидуальны: у кого-то накопились старые cookie, кто-то попал в эксперимент/фич-флаг, кто-то авторизован через SSO и получает более «тяжёлые» токены. Поэтому важно смотреть именно проблемный браузер/профиль.
Это связано с HTTP/2 или HTTP/3?
Причина та же — размер заголовков. При HTTP/2 заголовки передаются иначе, но лимиты на стороне Nginx всё равно существуют. Ориентируйтесь на фактические значения Cookie, Authorization, X-Forwarded-For и реальные сообщения в error.log.
Итог
Ошибка Request Header Or Cookie Too Large — это прямой сигнал: заголовки запроса не помещаются в буферы Nginx. В большинстве случаев помогает аккуратная настройка client_header_buffer_size и large_client_header_buffers, но надёжное решение — найти и убрать первопричину: big cookie или разросшиеся reverse proxy headers.
Если вы часто меняете домены/делаете переносы и хотите снизить риск «случайных» проблем с cookie и редиректами, держите под рукой план миграции: перенос сайта без простоя.
Для проектов, где нужна гибкая настройка Nginx, изоляция и быстрый доступ к конфигам, удобнее работать на VDS, чем на шаред‑окружении.
