Страница работает по HTTPS, но новый виджет запрашивает скрипт или изображение по HTTP. Браузер может блокировать запрос либо повышать схему для некоторых ресурсов. Исправляйте источник адреса и проверяйте все вложенные запросы, а не разрешайте небезопасную загрузку ради исчезновения сообщения.
Найдите ресурс и инициатор mixed content
Разделите тип ресурса, инициатор и фактическое действие браузера. Подмена http на https в строке помогает только если конечный источник действительно поддерживает HTTPS и выдаёт нужный ресурс.
Браузеры блокируют или повышают схему mixed content в зависимости от типа ресурса; проблема требует проверки фактического запроса. Официальная документация.
Запишите точный HTTPS URL страницы и сообщение браузера. Найдите ресурс, который запрошен по HTTP, и его инициатор. Основной скрипт виджета может быть безопасным, а вложенный шрифт или API— нет. Отдельно различайте прямую смешанную ссылку и переход HTTPS ресурса обратно на HTTP. Браузер может блокировать одни типы или повышать схему для других, поэтому отсутствие видимой ошибки интерфейса не доказывает правильность источника. Начните с реального запроса и поведения конкретного браузера, не отключая защиту ради открытия ресурса.
Матрица скрипта, изображения, CSS и API
Учебные сценарии в таблице задают ожидаемое поведение; фактические ответы своего сайта заносите отдельно.
| Сценарий | Отличие | Решение | Проверка |
|---|---|---|---|
| HTTP скрипт | Исполняемый ресурс | Найти HTTPS вариант | Не отключать защиту |
| HTTP картинка | Может повышаться схема | Проверить итоговый URL | Источник исправлен |
| CSS url | Вложенная зависимость | Найти инициатор | Корректный HTTPS |
| HTTP после клика | Поздний запрос | Повторить сценарий | Не только загрузка |
Включите в таблицу script, stylesheet, image, iframe, font и запрос данных. Укажите буквальный URL в конфигурации, фактический URL после переходов, тип и итог: загрузка, повышение схемы или блокировка. Картинка может внешне работать благодаря действию браузера, хотя исходный адрес остаётся HTTP. Это нужно исправить в генераторе. Запрос API может появляться только после клика. Сохраните также ожидаемую функцию: чат, карта или форма. Такой набор позволяет принять виджет целиком, а не только его первый bootstrap, который успел загрузиться по HTTPS.
Сохраните Console и реальный Network запрос
Сохраните сообщение Console и соответствующий Network запрос: исходный URL, тип, инициатор, переходы и итоговый статус. Проверьте CSS url, iframe и запросы данных самого виджета, которые появляются после его старта.
В Console сохраните сообщение без приватных данных, затем найдите соответствующую запись Network. Проверьте инициатор и цепочку перенаправлений. CSS url может находиться в файле провайдера, а не в HTML вашей страницы. Некоторые запросы запускаются после открытия панели, поэтому держите журнал между действиями. Для заблокированного запроса отсутствие HTTP статуса не означает, что сервер вернул 404: браузер мог остановить загрузку заранее. В отчёте укажите, что именно наблюдалось. Не приписывайте провайдеру ответ, который клиент фактически не получил, и не выводите проблему сертификата только из mixed content сообщения.
Учебный виджет с HTTPS bootstrap и HTTP зависимостями
Учебный виджет стартует по HTTPS, но его stylesheet ссылается на HTTP шрифт, а кнопка — на HTTP API. Проверка только основного script пропустит обе зависимости; после исправления повторяется загрузка и нажатие.
Учебный виджет подключает https://widget.example/bootstrap.js, затем stylesheet с HTTP шрифтом и HTTP endpoint после клика. Проверьте первую загрузку и открытиепанели в одном чистом сеансе. Исправление только bootstrap ничего не меняет во вложенных адресах. После обновления конфигурации повторите оба действия и сравните список запросов. Если используется собственная копия stylesheet, сверяйте право и актуальный механизм подключения: самостоятельная замена файлов может нарушить требования сервиса. Опыт задаёт набор проверок, но не утверждает, что любой реальный провайдер имеет именно такую архитектуру.
Исправьте источник безопасного адреса
Обновите конфигурацию виджета или провайдера на поддерживаемый HTTPS источник. Проверьте сертификат, конечный ответ и зависимые ресурсы. Если безопасный вариант отсутствует, выбор замены или отключения функции согласуется с продуктовой задачей.
Замените источник URL на поддерживаемый HTTPS вариант и откройте его напрямую. Проверьте сертификат, содержимое и отсутствие перехода обратно на HTTP. Если адрес формируется настройкой CMS, исправьте сохранённое значение; если приходит из кода провайдера, используйте его актуальную безопасную конфигурацию или обратитесь к ответственному владельцу. Механическая замена схемы не обеспечивает работу сервера. При отсутствии HTTPS варианта выбор замены или удаления функции принимается по её задаче. Не проксируйте произвольный внешний контент без оценки архитектуры, доступа и требований провайдера только ради исчезновения сообщения.
Почему CSP не создаёт HTTPS у провайдера
CSP upgrade-insecure-requests не создаёт HTTPS на сервере провайдера. Разрешение HTTP или отключение браузерной защиты не является устранением причины mixed content.
Upgrade-insecure-requests предлагает браузеру использовать безопасную схему, но не устанавливает сертификат и TLS на чужом сервере. Если HTTPS ресурс недоступен, запрос всё равно не станет рабочим. CSP также может блокировать источник по другой причине, поэтому разделите mixed content и policy violation. Не добавляйте небезопасные исключения и не просите посетителей разрешать HTTP загрузку. Правильное исправление делает источники безопасными по факту. После изменения политики проверьте реальные запросы, а не только отсутствие красной строки: лишний ресурс может перестать загружаться вместе с нужной функцией, скрыв симптом без восстановления поведения.
Приёмка загрузки и поздних действий виджета
Перезагрузите HTTPS страницу, откройте панель, выполните безопасное тестовое действие и проверьте все появившиеся ресурсы. Для формы не отправляйте реальную заявку без предусмотренного теста. Сохраните отсутствие смешанных запросов и работоспособность виджета. Проверьте холодный сеанс, потому что кеш способен скрыть загрузку проблемного ресурса. Отдельно оцените ошибки CSP и сертификата, если они остаются. Приёмка подтверждает безопасные источники и нужную функцию; она не обещает изменение SEO позиций. Контроль поздних действий стоит повторять после обновления провайдера, которое может добавить новые вложенные запросы.
Критерии завершения проверки
На контрольном HTTPS URL нет смешанных запросов при загрузке и взаимодействии с виджетом. Он сохраняет нужное действие, вложенные ресурсы доступны по HTTPS и не перенаправляются обратно на HTTP.
- HTTP скрипт: Не отключать защиту. Зафиксируйте фактический результат и адрес проверенного сценария.
- HTTP картинка: Источник исправлен. Зафиксируйте фактический результат и адрес проверенного сценария.
- CSS url: Корректный HTTPS. Зафиксируйте фактический результат и адрес проверенного сценария.
- HTTP после клика: Не только загрузка. Зафиксируйте фактический результат и адрес проверенного сценария.
Для смежных вопросов: Content Security Policy (CSP): настройка и примеры и Как сделать редирект с HTTP на HTTPS (Apache, Nginx, WordPress). Отдельные проверки сайта собраны на странице технического аудита reChecker.