ERR_BLOCKED_BY_RESPONSE: что делать владельцу сайта

Пошаговая диагностика ERR_BLOCKED_BY_RESPONSE: как найти заблокированный ресурс, проверить политики браузера и исправить заголовки без ослабления защиты.

Ошибка ERR_BLOCKED_BY_RESPONSE означает, что Chromium получил ответ на запрос, но не разрешил странице использовать его. Чаще всего конфликтуют источник страницы и ресурса, заголовки CORP/COEP или режим CORS; поэтому перезапуск сервера и очистка DNS обычно не помогают.

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

Что именно заблокировал браузер

Это не HTTP-статус вроде 404 или 502. Основной документ может открыться с кодом 200, а браузер отдельно заблокирует скрипт, изображение, шрифт, iframe или другой ресурс. В результате страница выглядит сломанной, хотя сервер формально отвечает.

В Chrome или Chromium откройте DevTools → Network, включите сохранение журнала и перезагрузите страницу. Найдите красный запрос и зафиксируйте:

  1. полный Request URL без токенов и других секретов;
  2. тип ресурса и колонку Initiator;
  3. адрес страницы, которая начала запрос;
  4. HTTP-статус, редиректы и Content-Type;
  5. уточнение ошибки в Console или Issues.

Формулировки наподобие CorpNotSameOrigin, CorpNotSameSite или AfterDefaultedToSameOriginByCoep сразу указывают на CORP/COEP. Ошибка ERR_BLOCKED_BY_CLIENT обычно относится к расширению или фильтру и требует другой диагностики.

Проверьте происхождение страницы и ресурса

Для браузера origin — это сочетание схемы, имени хоста и порта. Поэтому https://site.example и https://cdn.site.example принадлежат разным origin, хотя домены выглядят связанными. Переход с HTTPS на HTTP или нестандартный порт тоже меняет origin.

Сначала ответьте на два вопроса: ресурс действительно должен загружаться с другого origin и он публичный? Если нет, исправьте URL, схему, порт или ошибочный редирект. Если да, разрешение следует настраивать на сервере ресурса с учётом способа загрузки.

Проверьте итоговый ответ, включая цепочку перенаправлений:

curl -I -L https://cdn.example.org/assets/app.js

Смотрите на Location, Content-Type, Cross-Origin-Resource-Policy, Cross-Origin-Embedder-Policy и Access-Control-Allow-Origin. Успешный ответ curl доказывает доступность сервера, но не подтверждает, что браузер разрешит странице использовать тело ответа.

Разберите CORP, COEP и CORS по ролям

CORP ограничивает встраивание ресурса

Заголовок ответа Cross-Origin-Resource-Policy может разрешать загрузку только с того же origin, с того же site или с любых origin. Если публичный файл CDN ошибочно отдаётся с same-origin, страница на другом хосте его не получит.

Не меняйте значение на cross-origin автоматически. Оно уместно для действительно публичных ресурсов, но не для личных кабинетов, закрытых API и ответов с данными пользователя.

COEP задаёт правило для документа

Если основной документ отдаёт Cross-Origin-Embedder-Policy: require-corp, внешние ресурсы в режиме no-cors должны явно разрешить встраивание через CORP. Альтернативой может быть CORS-режим запроса, если сервер ресурса корректно разрешает нужный origin.

Перед включением строгой политики полезно проверить все CDN, iframe, виджеты, шрифты и сторонние скрипты через Report-Only. Простое удаление COEP способно скрыть симптом, но одновременно отменить задуманную изоляцию страницы.

CORS решает другую задачу

CORS позволяет серверу сообщить, каким origin разрешено читать ответ при CORS-запросе. CORP, напротив, ограничивает использование ответов для запросов no-cors. Поэтому добавление одного Access-Control-Allow-Origin не всегда исправляет конфликт COEP/CORP, а безусловный wildcard может расширить доступ сильнее, чем требуется.

Если явного указания на CORP/COEP нет, проверьте MIME-тип и тело ответа. Нередко URL скрипта или изображения после редиректа возвращает HTML-страницу входа либо страницу ошибки; защитный механизм браузера не обязан передавать такой cross-origin ответ вызывающей странице.

Как исправить ошибку без ослабления защиты

Выберите ветку, которая совпадает с назначением ресурса:

  • Ресурс должен быть локальным. Верните загрузку на тот же origin и устраните подмену хоста в шаблоне, сборке, reverse proxy или CDN.
  • Публичная статика должна работать с CDN. Настройте подходящий CORP либо CORS и атрибут crossorigin для конкретного типа загрузки. Проверьте, что правило применяется к итоговому ответу, а не только к первому редиректу.
  • После включения COEP пропали внешние ресурсы. Составьте список зависимостей и по очереди получите разрешение от каждого их сервера. Если поставщик не поддерживает нужную политику, замените интеграцию или осознанно пересмотрите режим изоляции.
  • Вместо файла приходит HTML. Исправьте маршрут, авторизацию, редирект и Content-Type; не маскируйте HTML-ошибку заголовком JavaScript или изображения.
  • Заголовки меняет CDN или proxy. Сравните ответ origin-сервера и публичного адреса, затем уберите дублирующее или более строгое правило в том слое, который его добавляет.

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

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

Откройте Network с отключённым кэшем, выполните полную перезагрузку и убедитесь, что запрос больше не помечен как blocked. Проверьте итоговый URL, ожидаемый Content-Type и фактическое появление ресурса на странице.

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

Внешний мониторинг Web-Puls может регулярно подтверждать, что публичный URL отвечает, и предупредить о его недоступности. Но он не заменяет браузерную проверку CORP/COEP на конкретной странице: финальная приёмка должна включать DevTools и реальный пользовательский сценарий.

Когда передать проблему специалисту

Помощь полезна, если заголовки одновременно формируют приложение, веб-сервер и CDN или ошибка появилась после изменения политики безопасности. Подготовьте адрес страницы и ресурса, время проверки, цепочку редиректов и заголовки ответа; значения Cookie, Authorization и токены удалите.

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

Проверьте свой сайт прямо сейчас

Введите адрес сайта: Web-Puls покажет HTTP-код, время ответа и базовую диагностику. Для постоянного контроля можно подключить мониторинг.

Нужна помощь с диагностикой ошибки?

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