ERR_RESPONSE_HEADERS_TOO_BIG означает, что браузер получил от сайта слишком большой блок HTTP-заголовков ответа и остановил загрузку до обработки страницы. Обычно источник находится в Set-Cookie, повторяющихся заголовках или настройках CDN/reverse proxy, а не в DNS или SSL.
Начните не с увеличения лимитов, а с поиска слоя, который раздувает ответ: приложение, веб-сервер, CDN или защитный сервис. Очистка cookies может быть полезным тестом, но не считается исправлением серверной причины.
Чем эта ошибка отличается от HTTP 431
В ответе сервера сначала идут статус и заголовки: например, Content-Type, Location, Cache-Control, Content-Security-Policy и один или несколько Set-Cookie. После них передаётся тело страницы. При ERR_RESPONSE_HEADERS_TOO_BIG браузер не принимает именно этот блок ответа.
Код 431 Request Header Fields Too Large описывает обратную ситуацию: сервер считает слишком большими заголовки запроса клиента, часто Cookie. Поэтому советы для 431 нельзя механически применять к ERR_RESPONSE_HEADERS_TOO_BIG.
Быстрая проверка: проблема у одного посетителя или у всех
- Зафиксируйте точный URL и время ошибки. Проверьте не только главную, но именно тот адрес, где произошёл сбой.
- Откройте URL в приватном окне. Если там страница работает, сравните поведение с обычным профилем: сохранённые cookies могли включить отдельную ветку ответа приложения.
- Проверьте тот же URL с другого устройства. Если ошибка воспроизводится у всех, вероятнее общий ответ сервера или CDN.
- Не ограничивайтесь
curl -I: запрос HEAD может обрабатываться иначе, чем обычный GET.
Заголовки GET-ответа можно увидеть так:
curl -sS -D - -o /dev/null 'https://example.ru/problem-page'Вывод может содержать Set-Cookie и другие чувствительные значения. Не публикуйте его целиком в тикете: передавайте названия заголовков, их количество и обезличенные размеры, а секреты удаляйте.
Где искать источник слишком больших заголовков
Set-Cookie и сессии
Частая причина — приложение отправляет много Set-Cookie, повторно создаёт один cookie или кладёт в cookie большой сериализованный объект. Проверьте ответ гостю и авторизованному пользователю отдельно, а также поведение после нескольких переходов и редиректов.
Если очистка cookies помогла только на время, ищите цикл их повторного создания. Пользовательская очистка устраняет симптом в одном браузере, но следующий ответ способен вернуть проблему.
Дубли на нескольких слоях
Один и тот же заголовок могут добавлять приложение, веб-сервер и CDN. Особенно внимательно сравните Content-Security-Policy, Link, CORS-заголовки, Server-Timing, диагностические и трассировочные поля. Исправление — оставить единственного владельца правила или убрать повтор, а не бездумно удалять защитные заголовки.
Redirect, CDN и reverse proxy
Проверьте каждый переход в цепочке редиректов: слишком большой блок может возвращать промежуточный URL, а не конечная страница. Сравните ответ через CDN с ответом origin-сервера, но обходите CDN только из разрешённой административной среды и сохраняйте правильное имя хоста для TLS.
В журнале nginx сообщение upstream sent too big header while reading response header from upstream указывает, что заголовки backend не поместились в буфер ответа proxy. Директивы для больших клиентских заголовков относятся к запросу и не исправляют эту причину.
Порядок исправления
- Найдите самый крупный или многократно повторённый заголовок и компонент, который его добавляет.
- Уберите дубли и устаревшие cookies. Большое состояние сессии храните на сервере, а в cookie оставляйте только необходимый идентификатор и атрибуты.
- Отключите публичные debug- и tracing-заголовки, если они не нужны клиенту. Политику безопасности сокращайте только после проверки её назначения.
- Если заголовки легитимны, измерьте их фактический размер на проблемном маршруте и лишь затем корректируйте лимит соответствующего proxy. Большой запас без анализа переносит сбой на следующий узел или браузер.
- После изменения сбросьте затронутый кэш CDN, если ответ мог быть закэширован, и повторите GET-проверку.
Для nginx с проксированием проверяют proxy_buffer_size, потому что он используется при чтении первой части ответа upstream. Конкретное значение зависит от измеренного ответа и цепочки посредников; универсального безопасного числа для всех сайтов нет.
Как убедиться, что ошибка устранена
Проверьте проблемный URL в чистом и обычном профиле, для гостя и авторизованного пользователя. Затем повторите сценарий, который раньше накапливал cookies или включал редирект.
Отдельно проверьте ответ через CDN и origin, если архитектура позволяет это сделать безопасно. Успех означает не только открывшуюся страницу, но и отсутствие повторного роста заголовков после нескольких запросов.
Автоматический мониторинг в Web-Puls помогает зафиксировать доступность URL и время повторных сбоев, но не заменяет анализ содержимого response headers. Если URL снова перестанет отвечать нормально, история проверок поможет сопоставить инцидент с изменением приложения или proxy.
Что передать хостингу или разработчику
Укажите точный URL, время, браузер, повторяемость для гостя и авторизованного пользователя, наличие CDN и обезличенный список самых крупных заголовков. Добавьте строки серверного журнала вокруг инцидента, но не отправляйте значения cookies, токены авторизации и персональные данные.
Если источник не удаётся локализовать между приложением, nginx и CDN, отправьте заявку на профессиональную поддержку: приложите безопасные результаты проверки и кратко опишите, после какого изменения появилась ошибка.