ERR_CONTENT_LENGTH_MISMATCH: что значит и как исправить

Что сделать прямо сейчас

Если вы просто открываете сайт:

1. Обновите страницу: F5, на Mac — Cmd+R. Если соединение оборвалось случайно, со второго раза страница может загрузиться целиком.
2. Если страница снова обрывается, исправить это может только владелец сайта. Сообщите ему адрес страницы и код ошибки ERR_CONTENT_LENGTH_MISMATCH.

Если сайт ваш, переходите к разделам «Как проверить» и «Как исправить» ниже: там все команды по шагам.

Что значит ошибка

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

Если соединение закрылось раньше, чем пришло обещанное число байт, страница дошла не целиком. По правилам HTTP такой ответ считается неполным, и Chrome сообщает об ошибке ERR_CONTENT_LENGTH_MISMATCH. В исходном коде Chrome это ошибка -354.

Как выглядит в Chrome

В нашей проверке Chrome показал ту часть страницы, которая успела прийти, — без сообщения об ошибке. Когда после заголовков не пришло ничего, страница осталась пустой.

Код ошибки виден в инструментах разработчика: откройте их клавишей F12 или Ctrl+Shift+I, на Mac Cmd+Option+I, и перейдите на вкладку Console («Консоль»). Там будет строка Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH. Та же строка появится, если оборвалась загрузка картинки, скрипта или стиля на странице.

Если Chrome всё же показывает страницу ошибки, на ней заголовок «Страница недоступна» и текст «Сайт example.com неожиданно разорвал соединение.», ниже — код ERR_CONTENT_LENGTH_MISMATCH и кнопка «Перезагрузить».

Причины

• Программа сайта оборвала ответ. Она начала отдавать страницу, но аварийно завершилась или закрыла соединение, не дослав её до конца.
• nginx не дождался программы. Если программа надолго замолкает посреди ответа, nginx перестаёт ждать и закрывает соединение. По умолчанию он ждёт 60 секунд между двумя порциями данных.
• На диске сервера кончилось место. Если ответ программы не помещается в память, которую nginx отводит под него, часть ответа nginx записывает во временный файл на диске. Когда записать не получается, nginx обрывает ответ.
• В Content-Length указано больше, чем отправлено. Программа сама ставит этот заголовок, называет в нём больше байт, чем присылает на самом деле, и закрывает соединение.

Как проверить

Шаг 1 выполните на своём компьютере: на Mac — в программе Терминал, в Windows — в командной строке. Если вы ни разу не открывали терминал, начните с инструкции Как открыть терминал: там всё по шагам. Скопируйте команду целиком, замените example.com на адрес своего сайта и нажмите Enter.

Шаг 1. Загрузите страницу командой curl

На Mac:

curl -sS --http1.1 -o /dev/null https://example.com/

В Windows:

curl -sS --http1.1 -o NUL https://example.com/

Вместо https://example.com/ укажите полный адрес страницы, которая обрывается. Ключ --http1.1 просит соединение по протоколу HTTP/1.1, -o /dev/null (в Windows — -o NUL) не сохраняет страницу, а -sS оставляет на экране только сообщения об ошибках.

Если страница пришла целиком, curl ничего не напишет. Если ответ оборвался, появится строка с номером 18, например:

curl: (18) transfer closed with 99877 bytes remaining to read

Число в ней — сколько байт не дошло. Если вместо числа написано outstanding read data remaining, сервер отправлял страницу частями — это соседняя ошибка ERR_INCOMPLETE_CHUNKED_ENCODING.

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

Шаг 2. Посмотрите журнал ошибок nginx

Этот и следующий шаги выполняются на сервере. Если вы ещё не подключались к нему, начните с инструкции Как подключиться к VPS по SSH.

Откройте обрывающуюся страницу ещё раз и сразу после этого выполните команду:

sudo tail -n 50 /var/log/nginx/error.log

Она покажет последние 50 строк журнала ошибок nginx, самые новые — внизу. Поищите в них такие слова:

Если в той же строке есть слова while reading upstream, сбой случился посреди ответа — это как раз случай с этой страницы. Слова while reading response header from upstream значат, что программа подвела ещё до начала ответа. Тогда посетители видят не эту ошибку, а 502 Bad Gateway или 504 Gateway Timeout.

Шаг 3. Проверьте место на диске

df -h

Команда покажет диски сервера. Найдите строку, у которой в последнем столбце, Mounted on, стоит знак /. Если в столбце Use% у неё 100%, место кончилось.

Как исправить

Если программа сайта обрывает ответ

Найдите в журнале самой программы записи за то же время, что и строка в журнале nginx: если программа упала, причина будет там. Если программа запущена как служба, последние 50 строк её журнала покажет команда sudo journalctl -u имя_службы -n 50.

Если заголовок Content-Length программа ставит сама, проверьте, что число в нём — длина в байтах именно того, что она отправляет. Или уберите этот заголовок: без него страница всё равно дойдёт, просто браузер не будет знать её длину заранее.

После правки перезапустите программу и повторите шаг 1.

Если nginx не дожидается программы

Лучше всего ускорить саму программу. Если долгий ответ — это нормально, например при выгрузке большого отчёта, разрешите nginx ждать дольше. Откройте файл настроек сайта — например, командой sudo nano /etc/nginx/sites-available/example.com — и добавьте в блок location со строкой proxy_pass такую строку:

proxy_read_timeout 300s;

300s — это 300 секунд, то есть пять минут: столько nginx будет ждать следующей порции данных. Если сайт на PHP и в блоке location вместо proxy_pass стоит fastcgi_pass, строка нужна другая:

fastcgi_read_timeout 300s;

Сохраните файл — Ctrl+O, Enter, затем Ctrl+X — и проверьте настройки:

sudo nginx -t

В ответе должны быть слова syntax is ok и test is successful. Если вместо них сообщение об ошибке, в нём указаны файл и номер строки: исправьте строку и проверьте снова. Когда проверка прошла, примените настройки:

sudo systemctl reload nginx

Если команда ничего не ответила, настройки применены. Затем повторите шаг 1.

Если кончилось место на диске

Посмотрите, какие папки занимают больше всего места:

sudo du -xh --max-depth=2 / 2>/dev/null | sort -h | tail -n 20

Подсчёт может занять минуту-другую. Последняя строка — весь диск целиком, над ней — самые большие папки. Удалите то, что точно не нужно: старые архивы, резервные копии и выгрузки, которые вы делали сами. Системные папки — /usr, /lib, /boot — не трогайте. Если не уверены, нужен ли файл, не удаляйте его.

Когда место освободится, повторите шаг 1. Перезапускать nginx не нужно.

На обычном хостинге

Настройки nginx и диск сервера на обычном хостинге в руках хостинга. Если вы сами задавали заголовок Content-Length в коде сайта, проверьте его, как описано выше. Если нет, напишите в поддержку хостинга адрес страницы, время, когда она оборвалась, и код ошибки ERR_CONTENT_LENGTH_MISMATCH.

Соседние ошибки

Источники

• Исходный код Chromium: net_error_list.h — ошибка -354; localized_error.cc — что Chrome пишет на странице ошибки.
• RFC 9112, раздел 6.3 и раздел 8 — ответ, который оборвался раньше объявленной длины, считается неполным.
• Документация curl — ключи --http1.1 и -o, код выхода 18.
• Документация nginx: proxy_buffering, proxy_read_timeout и fastcgi_read_timeout.
• Исходный код nginx: ngx_http_upstream.c — что nginx пишет в журнал и как обрывает ответ, если программа подвела посреди ответа.

Проверено в Chrome 155 на локальном тестовом сервере 8 октября 2026 года.

Сверено 8 октября 2026 года.

Что почитать дальше

• ERR_INCOMPLETE_CHUNKED_ENCODING — что делать, если обрывается страница, которую сервер отправлял частями.
• 504 Gateway Timeout — что делать, если программа сайта отвечает слишком долго.
• «Не удается получить доступ к сайту» — коды ошибок Chrome и что они значат.