Ошибка 431 Request Header Fields Too Large: что делать

Ошибка 431 означает, что один из компонентов на пути запроса отказался его обрабатывать из-за слишком больших HTTP-заголовков. Это не то же самое, что большой загружаемый файл: тело запроса может быть небольшим, а лимит превышают cookies, данные авторизации или совокупность служебных заголовков. Начните с проверки в приватном окне, затем выясните, ошибка возникает у одного пользователя или у всех. Так можно быстро разделить локальную проблему браузера и общий сбой конфигурации.

Что означает 431 Request Header Fields Too Large

Код 431 описан в RFC 6585. Сервер может вернуть его в двух случаях:

• слишком велик общий набор заголовков запроса;
• слишком велико одно конкретное поле.

Под «сервером» здесь полезно понимать не только приложение. Ответ может сформировать CDN, балансировщик, reverse proxy, веб-сервер или само приложение. У каждого слоя могут быть собственные ограничения, поэтому изменение настройки только на origin-сервере не всегда решает проблему.

431 легко спутать с соседними ошибками:

• 413 Content Too Large относится к слишком большому телу запроса, например к загружаемому файлу;
• 429 Too Many Requests означает ограничение по частоте запросов, а не по размеру заголовков;
• 400 Bad Request — более общий ответ на некорректный запрос; некоторые компоненты не обязаны использовать именно 431.

Если вы видите 429, используйте отдельный разбор: что проверить при Too Many Requests.

Почему заголовки становятся слишком большими

Cookies накопились для домена

Браузер отправляет подходящие cookies автоматически. После нескольких изменений авторизации, аналитики, экспериментов или структуры поддоменов могут остаться устаревшие значения. По отдельности они выглядят безобидно, но в одном поле Cookie складываются вместе.

На такой сценарий указывает простая картина: сайт не открывается в обычном окне, но работает в приватном режиме или в другом браузере. Это ещё не доказательство, однако хороший способ выбрать направление проверки.

В заголовок положили слишком много данных

Токен, сериализованное состояние интерфейса или иной крупный фрагмент данных иногда помещают в Cookie или Authorization. Заголовки подходят для ограниченной служебной информации, но плохо заменяют серверное хранилище состояния.

Заголовки увеличиваются на промежуточных слоях

CDN и прокси добавляют служебные поля, а цепочка прокси может дополнять уже существующие значения. Ошибка в правилах перенаправления заголовков или повторное добавление одного и того же значения способно постепенно раздуть запрос. Важно проверять не только то, что отправил браузер, но и то, что дошло до следующего слоя.

Ограничения компонентов не согласованы

Допустимый запрос на одном уровне может быть отвергнут на следующем. Фактический предел всей цепочки задаёт компонент с наиболее строгим ограничением. Универсального значения, которое следует бездумно установить везде, нет: решение зависит от программного стека, модели нагрузки и требований безопасности.

Что сделать пользователю сайта

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

1. Откройте тот же URL в приватном окне. Если страница загрузилась, сравните поведение с обычной сессией.
2. Проверьте другой браузер или устройство. Это помогает понять, привязана ли ошибка к конкретному профилю.
3. Удалите данные только проблемного сайта. Не обязательно очищать все cookies и историю. После удаления потребуется войти в аккаунт заново.
4. Отключите расширения для контрольной проверки. Расширения, работающие с запросами, могут менять заголовки. Не оставляйте защитные расширения выключенными постоянно: цель шага — только воспроизведение.
5. Зафиксируйте условия ошибки. Запишите точный URL, время, действие перед сбоем и результат в приватном окне. Не пересылайте в тикет значения Cookie, Authorization и токены: они могут быть чувствительными.

Если 431 исчез после удаления данных сайта, пользователю этого может быть достаточно. Но владельцу ресурса всё равно стоит выяснить, почему браузер накопил такой набор cookies, иначе обращения повторятся.

Как владельцу сайта найти источник 431

Шаг 1. Определите масштаб

Проверьте проблемный URL:

• без авторизации;
• после входа;
• в новом профиле браузера;
• с другого устройства или сети;
• с обычным GET-запросом без пользовательских cookies.

Для командной строки можно начать с контрольного запроса:

curl -v -o /dev/null https://example.ru/problem-page

Команда покажет отправленные и полученные заголовки, но не воспроизведёт сессию реального пользователя автоматически. Не вставляйте чужие cookies или токены в общие терминалы, историю команд и переписку.

Шаг 2. Найдите слой, который вернул ответ

Сопоставьте время запроса с журналами CDN, балансировщика, reverse proxy, веб-сервера и приложения. Если запись есть на внешнем прокси, но отсутствует на origin, запрос, вероятно, был остановлен раньше. Если приложение получило запрос и само вернуло 431, изучайте его валидацию и middleware.

Не полагайтесь только на внешний вид страницы ошибки: шаблон ответа можно заменить. Надёжнее использовать идентификаторы запроса, трассировку между слоями и журналы без чувствительных значений.

Шаг 3. Сравните заголовки рабочего и ошибочного запроса

В инструментах разработчика откройте вкладку Network и сравните Request Headers. Ищите не секретные значения, а структуру:

• необычно длинное поле Cookie;
• крупный Authorization;
• повторяющиеся служебные заголовки;
• множество cookies с пересекающимися Domain и Path;
• рост полей, которые добавляет прокси.

Значения авторизации нельзя копировать в задачу целиком. Для диагностики обычно достаточно имени поля, измеренного размера, слоя отказа и безопасного фрагмента без секрета.

Шаг 4. Исправьте причину

В зависимости от результата исправление может быть разным:

• удалить устаревшие cookies и прекратить их повторное создание;
• уменьшить хранимое в cookie состояние, а подробные данные держать на сервере;
• точнее задать область cookie через Domain и Path;
• убрать дублирование заголовков на прокси;
• согласовать ограничения CDN, прокси, веб-сервера и приложения;
• изменить лимит только после оценки реального запроса и рисков.

Простое увеличение лимита без разбора причины — слабое решение. Оно может скрыть ошибку приложения и увеличить объём данных, которые инфраструктура обязана разбирать. Сначала устраните лишние заголовки, затем настройте обоснованный запас и проверьте все слои цепочки.

Три практических сценария

Ошибка только у давно авторизованных пользователей

Новый посетитель открывает сайт, а пользователь со старой сессией получает 431. Приватное окно работает. Сначала сравните набор cookies до и после входа, проверьте устаревшие имена и правила их удаления. После исправления протестируйте как новую, так и сохранённую сессию.

Ошибка появилась у всех после изменения прокси

Контрольный запрос без cookies тоже получает 431, а приложение не видит обращение. Проверьте последний инфраструктурный релиз, правила передачи заголовков и лимиты внешнего слоя. Откат одного ошибочного правила может быть безопаснее, чем срочно повышать пределы на всех компонентах.

Мониторинг показывает «работает», а отдельные клиенты жалуются

Обычная HTTP-проверка не использует персональные cookies посетителя, поэтому пользовательский сценарий с разросшейся сессией может остаться зелёным. Это важное ограничение: доступность публичного URL и работоспособность конкретной авторизованной сессии — разные проверки.

Чтобы не потерять детали во время аварии, полезно заранее иметь план эскалации при падении сайта.

Как контролировать проблему после исправления

После изменения повторите тесты для анонимного и авторизованного пользователя. Добавьте проверку проблемного URL в smoke-тест релиза и убедитесь, что запрос проходит через ту же CDN- и proxy-цепочку, что и реальный трафик. Подробный порядок можно сверить с чеклистом проверки сайта после релиза.

Web-Puls можно использовать для регулярной проверки публичного URL и уведомления о нештатном HTTP-ответе. Такой контроль поможет заметить общий 431, который начал получать обычный запрос. При этом мониторинг без пользовательской сессии не заменяет отдельный сценарный тест авторизации и не доказывает, что cookies конкретного клиента имеют допустимый размер.

Полезно также вести инвентаризацию cookies: кто создаёт каждое поле, для какого домена и пути оно нужно, когда удаляется и что произойдёт после изменения формата. Эта практика помогает предупреждать не только 431, но и трудно воспроизводимые ошибки старых сессий.

Когда нужна профессиональная диагностика

Обращение к специалисту уместно, если непонятно, какой слой возвращает 431, нет доступа к журналам CDN или прокси, ошибка зависит от авторизации либо изменение лимита затрагивает несколько компонентов. В заявке достаточно указать домен, проблемный URL, время проверки, масштаб сбоя и шаги воспроизведения. Секретные заголовки прикладывать не нужно.

Можно отправить запрос через форму профессиональной поддержки или выбрать удобный способ связи на странице контактов. Диагностика особенно полезна, когда нужно не просто убрать сообщение в браузере, а безопасно согласовать настройки всей цепочки.

Краткий чеклист

• проверить URL в приватном окне и другом браузере;
• понять, затронут один пользователь или все;
• сравнить анонимный и авторизованный запрос;
• определить компонент, который сформировал 431;
• найти крупное или повторяющееся поле;
• убрать источник лишних данных;
• согласовать ограничения по всей цепочке;
• повторить smoke-тест и настроить наблюдение за HTTP-ответом.

Вывод

Ошибка 431 говорит не о размере страницы, а о заголовках запроса. Для одного пользователя первым кандидатом становятся cookies и профиль браузера; для массового сбоя — CDN, прокси, веб-сервер, приложение и их несогласованные ограничения. Не начинайте с максимального лимита. Сначала локализуйте слой, сравните рабочий и ошибочный запрос, устраните лишние данные и только затем меняйте конфигурацию.