#Что означает и когда возникает ошибка
Ошибка возникает после входа в приложение, длительной работы с ним или при накоплении cookie. Не путайте предел заголовков входящего запроса с client_max_body_size: последний касается тела запроса, а не Cookie. Если проблема у одного браузера, начинайте с его данных; если массовая — с настроек приложения и Nginx.
#Причины и как их различить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Переполнен один заголовок CookieПриложение добавило слишком много или слишком длинные значения cookie. | В приватном окне та же страница открывается, у постоянного пользователя — нет. | Удалить только cookie затронутого сайта; найти источник роста. |
| Неверно выбран предел заголовкаВ Nginx действует large_client_header_buffers; один заголовок должен помещаться в один буфер. | В error.log есть client sent too long header line либо ошибка 400 при длинном Cookie. | После устранения чрезмерных cookie точечно пересмотреть размер буфера. |
| Заголовки увеличивает промежуточный узелCDN, прокси или шлюз может принимать запрос, который затем отвергает следующий слой. | Разное поведение при запросе непосредственно к Nginx и через CDN. | Сравнить логи соответствующих слоёв без отключения защиты. |
#Пошаговая диагностика и исправление
- Проверьте, что ошибка связана именно с cookieОткройте сайт в обычном окне браузера и запишите полный адрес, время и HTTP-код на вкладке «Сеть» инструментов разработчика (F12 → «Сеть», затем обновите страницу). После этого откройте тот же адрес в приватном окне, не входя в учётную запись. Если страница открылась, причина вероятнее в cookie или состоянии пользователя. Если оба варианта дают ошибку, переходите к журналу сервера; приватное окно не служит подтверждением серверной настройки.
- Удалите данные лишь одного сайтаЕсли приватное окно работает, в Chrome откройте «Настройки» → «Конфиденциальность и безопасность» → «Сторонние файлы cookie» → «Посмотреть все данные и разрешения сайтов» (названия могут отличаться по версии); найдите домен и удалите его данные. Предупредите пользователя: произойдёт выход из аккаунта, корзина/локальные настройки могут исчезнуть. Войдите повторно и обновите страницу. При повторном росте cookie передайте проблему разработчику приложения, а не увеличивайте лимит без причины.
- Найдите соответствующую запись в NginxНа сервере Debian/Ubuntu войдите по SSH с учётной записью с правом sudo. Откройте терминал на своём компьютере и подключитесь привычным SSH-клиентом. Выполните
sudo journalctl -u nginx --since "30 minutes ago" --no-pagerили проверьте фактическийerror_logизsudo nginx -T. Ищите сообщения о длинной строке заголовка на время ошибки; в журнале не публикуйте значения cookie или сеансовые токены. Если сообщение отсутствует, проверьте настройки и журналы балансировщика перед Nginx. - Определите действующий предел и правильный виртуальный серверВыполните
sudo nginx -T 2>&1 | grep -nE "large_client_header_buffers|client_header_buffer_size|server_name|listen "и найдите настройки именно того server-блока, который обрабатывает домен. Учитывайте параметры сервера по умолчанию на раннем этапе выбора виртуального сервера. Выводnginx -Tможет содержать секреты: не пересылайте его целиком. Не увеличивайте client_max_body_size — это не исправит длинный Cookie. - Исправьте причину в приложенииВ коде приложения найдите место записи
Set-Cookieи убедитесь, что оно не добавляет к cookie журнал действий, большие структуры JSON, дубликаты или повторяющиеся значения. Оставляйте в cookie только необходимые короткие идентификаторы, остальные данные храните на сервере. После исправления повторите сценарий входа и убедитесь в инструментах разработчика, что Cookie перестал увеличиваться при каждом запросе. Если код чужой, передайте разработчику обезличенные сведения, не правьте сессионные cookie вручную. - Увеличьте буфер только при обоснованной необходимостиЕсли приложение уже исправлено, а допустимый по вашей архитектуре заголовок всё ещё больше стандартного, сохраните копию конкретного файла конфигурации (например,
sudo cp -a /etc/nginx/conf.d/app.conf /etc/nginx/conf.d/app.conf.bak-20261102, заменив имя на действительное). Добавьте в подходящий блокhttpилиserverпримерlarge_client_header_buffers 4 16k;. Значение 16k — пример, не универсальная рекомендация. Проверьте синтаксис командойsudo nginx -t, затем выполнитеsudo systemctl reload nginxтолько при успешном тесте. Если ошибка или ухудшение — восстановите копию, повторите тест и перезагрузите конфигурацию. - Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
- Повторите проверку после входаПосле исправления снова войдите в приложение и откройте страницу, на которой была ошибка; убедитесь, что HTTP 400 исчез, количество cookie не растёт, а в журнале больше нет сообщений о превышении длины заголовка. Если не помогло, сравните запросы до и после CDN, а также проверьте ограничение заголовков у следующего прокси; не передавайте содержимое Cookie в обращениях поддержки.
#Проверка результата
Воспроизведите запрос в обычном окне после авторизации и проверьте отсутствие ответа 400 и записей о слишком длинном заголовке. Если снова появляется через несколько часов, исправляйте генерацию cookie.
#Если проблема осталась
Сохраните дату, точный URL без паролей и токенов, код ответа, обезличенные строки error.log и access.log за это время и перечень уже сделанных изменений. Сравните работу при обращении через публичный адрес и через внутренний балансировщик, если он есть. Если причину пока не удалось подтвердить, восстановите исходную конфигурацию из копии и передайте эти сведения администратору или разработчику приложения; не меняйте несколько параметров одновременно.