ERR_CONTENT_LENGTH_MISMATCH: что означает ошибка и как её исправить

Ошибка ERR_CONTENT_LENGTH_MISMATCH означает, что браузер ожидал один объём HTTP-ответа, а фактически получил другой. Чаще всего передача страницы, изображения, CSS, JavaScript или файла оборвалась раньше, чем обещал заголовок Content-Length.

Сначала повторите запрос без кэша, найдите конкретный ресурс в Network и проверьте его через другой канал. Если ошибка воспроизводится, причину нужно искать в цепочке origin-сервер → прокси → CDN, а не в HTML страницы как таковом.

Что означает ERR_CONTENT_LENGTH_MISMATCH

Content-Length сообщает клиенту размер тела ответа в байтах. По HTTP Semantics это значение участвует в определении границ сообщения. Если соединение закрывается до получения объявленного числа байтов, HTTP/1.1 считает ответ неполным.

Это не HTTP-статус вроде 404 или 502. Сервер может успеть отправить 200 OK, но браузер всё равно отбросит незавершённый ответ. Поэтому главная страница иногда выглядит пустой или «ломается», хотя проверка одного только кода показывает успех.

В браузерах на Chromium название ошибки видно в DevTools или на странице сбоя. Другой браузер может показать иной текст, повторную загрузку либо просто отсутствие проблемного ресурса.

Быстрая проверка для владельца сайта

1. Откройте тот же URL в приватном окне и выполните жёсткую перезагрузку. Это исключит часть проблем локального кэша, но не исправит ошибку сервера.
2. Откройте DevTools → Network, включите сохранение журнала и перезагрузите страницу. Найдите запрос с ошибкой: это может быть не документ, а шрифт, скрипт, изображение или ответ API.
3. Зафиксируйте полный URL, время, HTTP-статус, Content-Length, Content-Encoding, протокол и узел, от которого пришёл ответ. Не публикуйте URL с токенами и другими секретами.
4. Повторите запрос из другой сети или внешней точки. Если сбой есть только у одного пользователя, проверьте расширения, антивирусный HTTPS-фильтр и локальный прокси.
5. Если ошибка повторяется у разных пользователей, передайте администратору URL и точное время — по ним проще сопоставить запрос с логами.

Для командной проверки подойдёт GET-запрос, который действительно читает тело:

curl -v --http1.1 --raw -o /dev/null "https://example.ru/path"

При преждевременном завершении curl обычно сообщает о частично полученном ответе. Запрос curl -I для этой проверки недостаточен: HEAD не передаёт тело, длину которого нужно проверить. Повторите тест и по HTTP/2, если он используется, потому что ошибка может проявляться только на одном участке цепочки.

Где чаще всего находится причина

Origin-сервер или приложение

Приложение могло начать отправку и завершиться до формирования полного ответа. Ищите в логах ошибку процесса, тайм-аут upstream, принудительное закрытие соединения или сбой генерации файла в то же время, когда браузер получил ошибку.

Опасная настройка — вручную задавать Content-Length для динамического ответа, который затем меняется шаблонизатором, сжатием или фильтром. Если размер заранее неизвестен, длину должен корректно определить серверный стек; подставлять приблизительное значение нельзя.

Reverse proxy и сжатие

Nginx, балансировщик или другой прокси может получить неполный ответ от приложения либо оборвать передачу по своему тайм-ауту. Отдельно проверьте, не сжимают ли один ответ два слоя и не сохраняется ли старый Content-Length после преобразования тела.

Сравните логи origin и внешнего прокси по одному request ID, если он настроен. Важно увидеть не только статус, но и число отправленных байтов, причину завершения upstream и время запроса.

CDN и кэш

Если origin отвечает стабильно, а ошибка появляется через CDN, сравните один и тот же объект через оба маршрута из контролируемой среды. Проверьте кэшированный вариант, правила сжатия, range-запросы и состояние соединения между CDN и origin.

Не очищайте весь кэш как единственный способ «лечения». Сначала устраните причину и затем инвалидируйте конкретный повреждённый объект: иначе ошибка может вернуться при следующем заполнении кэша. Для похожей ситуации пригодится разбор неполной загрузки CSS, JS и изображений через CDN.

Сеть пользователя

Одиночный случай может возникнуть из-за нестабильного соединения или программы, которая перехватывает HTTPS-трафик. Но если ошибка повторяется на разных устройствах и сетях для одного URL, очистка браузерного кэша у посетителей не является решением — проверяйте серверную цепочку.

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

• При обрыве на origin устраните падение процесса или тайм-аут, затем повторите загрузку большого и обычного ответа.
• При неверном заголовке уберите ручной расчёт Content-Length либо считайте его после всех преобразований тела.
• При конфликте сжатия оставьте ответственным один понятный слой и проверьте заголовки внешнего ответа.
• При проблеме прокси согласуйте его тайм-ауты с реальным временем работы приложения; простое увеличение лимита не заменяет исправление медленного обработчика.
• При ошибке CDN исправьте взаимодействие с origin, удалите только затронутый объект из кэша и дождитесь нового корректного ответа.
• После изменения проверьте критичный URL несколько раз снаружи и убедитесь, что файл или страница загружается полностью, а не только возвращает 200 OK.

Отдельно проверьте страницу без кэша, с кэшем и после истечения его срока. Если сбой зависел от размера ответа, прогоните маленький и крупный объект. Если зависел от сжатия, сравните запросы с разными Accept-Encoding, не меняя несколько настроек одновременно.

Как не пропустить повторение

Разовая успешная загрузка подтверждает только текущий запрос. Если проблема появляется волнами, поставьте критичный URL на регулярную внешнюю проверку и сопоставляйте её время с логами сервера и CDN. Web-Puls можно использовать для такого контроля доступности; для страницы, которая иногда приходит неполной при статусе 200, дополнительно полезно проверять ожидаемый текст.

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

Что передать специалисту

Подготовьте проблемный URL без секретных параметров, точное время и часовой пояс, скриншот Network, response headers, результат curl, сведения о CDN или прокси и список недавних изменений. Доступы и персональные данные не добавляйте в открытые сообщения.

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