Данные пришли, но не читаются
Чтобы экономить трафик, серверы сжимают ответы алгоритмами вроде gzip или brotli и сообщают об этом в заголовке Content-Encoding. Браузер, получив такой ответ, обязан распаковать данные перед показом. ERR_CONTENT_DECODING_FAILED означает, что распаковка не удалась: заголовок обещает один формат, а содержимое ему не соответствует либо повреждено.
Такое расхождение — почти всегда ошибка конфигурации сервера или промежуточного узла, а не проблема вашего компьютера. Поэтому исправить её посетителю удаётся редко, а вот проверить, где именно ломается, можно быстро.
Если ошибка проявляется только в одном браузере, сравните версии и включённые режимы экономии трафика: они изменяют заголовки запроса, и сервер отвечает иным форматом сжатия.
Типичные источники
Первый — двойное сжатие: приложение уже отправило сжатый ответ, а веб-сервер или прокси сжал его повторно либо, наоборот, добавил заголовок, не сжимая содержимое. Второй — обрыв передачи, из-за которого поток заканчивается посреди сжатого блока.
Третий — неправильная работа кеша или CDN: они хранят сжатую версию и отдают её клиенту, не поддерживающему этот формат, либо путают версии. Четвёртый — ошибка в самом коде приложения, вывод которого попал в поток до начала сжатия, например служебное сообщение PHP или пробелы перед сжатием.
Проверка и диагностика
Обновите страницу с полной очисткой кеша (Ctrl+F5) и откройте её в режиме инкогнито. Если после этого страница открылась, проблема была в повреждённой записи кеша браузера, и очистка данных сайта её решит.
Затем проверьте другой браузер и другую сеть. Если ошибка устойчиво повторяется, откройте панель разработчика на вкладке сети и посмотрите заголовки ответа: значение Content-Encoding и размер. Несоответствие между заявленным сжатием и фактическим видом данных подтверждает сбой сервера.
Если вы работаете через прокси или защитную программу, отключите её на время теста: они иногда изменяют заголовки, не меняя тело.
Что можно сделать посетителю
Очистите кеш и cookie сайта, отключите расширения, обновите браузер. Перезагрузите роутер, если ошибка возникает только дома. Проверьте систему на нежелательные программы, перехватывающие трафик.
Если ничего не помогло, подождите: часто это следствие свежего изменения на стороне сервера, которое владелец быстро исправляет. Сообщите ему адрес страницы и время ошибки, это ускорит поиск причины. Проверьте также, нет ли на устройстве программ, сжимающих или фильтрующих трафик, вроде экономии данных в мобильных браузерах. Отключите такую функцию на время проверки.
Что проверить владельцу
Убедитесь, что сжатие включено ровно в одном месте цепочки: либо в приложении, либо на веб-сервере, либо на CDN. Проверьте, что заголовок Content-Encoding выставляется только для действительно сжатых ответов и что для запросов без поддержки сжатия отдаётся обычная версия.
Изучите настройки кеша: варианты ответа должны различаться по заголовку Vary. Запросите страницу утилитами командной строки с разными значениями Accept-Encoding и убедитесь, что содержимое разворачивается без ошибок.
Проверка сжатия со стороны разработчика
Чтобы убедиться, что сервер отдаёт корректное сжатие, запросите страницу утилитой командной строки, явно указав заголовок Accept-Encoding, и сохраните ответ в файл. Затем попробуйте распаковать его соответствующей программой. Если распаковка не удаётся, значит, тело не соответствует заявленному формату.
Повторите проверку без заголовка Accept-Encoding: в ответе не должно быть Content-Encoding, а данные должны быть обычным текстом. Так вы поймёте, различает ли сервер клиентов по их возможностям.
Проверьте и кеширующие слои: запрос к источнику напрямую, минуя CDN, отделит ошибки самого сервера от ошибок промежуточных звеньев. Если напрямую ответ корректен, а через CDN нет, сбросьте кеш CDN и проверьте правила сжатия на его стороне.
Когда сжатие включено на нескольких уровнях, документируйте, где именно оно применяется. Через полгода после запуска такая заметка избавляет от долгих поисков и повторения той же ошибки при очередном обновлении конфигурации.