На сайте работает HTTPS, но после подключения чата в консоли появилась ошибка Mixed Content. Значит, защищённая страница пытается получить ресурс по HTTP. Это может быть сам скрипт виджета, его картинка, шрифт или запрос, который выполняется только после открытия окна чата.
Найдите полный HTTP-адрес в сообщении браузера. Исправлять нужно источник этой ссылки, а затем проверять работу виджета. Исчезновение красной строки ещё не означает, что посетитель сможет отправить сообщение.
Найдите запрос и его источник
Откройте инструменты разработчика: в Chrome это меню «Дополнительные инструменты» → «Инструменты разработчика». На вкладке Console найдите сообщение Mixed Content и скопируйте URL. На вкладке Network включите Preserve log, обновите страницу и выполните действие, после которого появляется ошибка.
Например, главная загружается нормально, а HTTP-запрос возникает при нажатии «Написать в чат». Проверяйте это нажатие, а не только первую загрузку. В Network столбец Initiator помогает найти скрипт, который создал запрос.
Если запрос заблокирован браузером до отправки, у него может не быть ответа сервера и HTTP-статуса. Это не доказательство, что адрес возвращает 404: запрос мог вообще не дойти до поставщика виджета.
Определите, кто может изменить ссылку
| Где находится HTTP-адрес | Кому передать исправление |
|---|---|
| Вставленный в CMS код подключения | Тому, кто настраивает блок или шаблон |
| Настройки виджета в кабинете поставщика | Администратору этого кабинета |
| JavaScript поставщика формирует запрос | Поддержке поставщика со ссылкой и Initiator |
| Ваш CSS подключает шрифт или фон | Разработчику соответствующего файла |
Сохраните адрес страницы, HTTP-ресурса и действие пользователя. Не редактируйте вслепую сторонний минифицированный скрипт: при очередном обновлении изменение может исчезнуть, а ошибка остаться в исходном коде поставщика.
Убедитесь, что у ресурса работает HTTPS
Откройте HTTPS-вариант проблемного URL отдельно. Он должен выдавать нужный файл или ответ, с действующим сертификатом для этого имени. Замена http:// на https:// бесполезна, если у поставщика по новому адресу нет такого ресурса.
Проверьте также конечный адрес: HTTPS-ссылка может перенаправлять обратно на HTTP. Для виджета важно, чтобы безопасными были и подключение, и дальнейшие запросы. Иногда основной скрипт уже использует HTTPS, а старый URL остался внутри настройки картинки или API.
Если поставщик не поддерживает HTTPS, попросите безопасный способ подключения или замените виджет. Не оставляйте посетителю инструкцию отключить защиту браузера. Неизвестный прокси тоже не стоит подключать только ради исчезновения предупреждения.
Не путайте mixed content с другой блокировкой
Браузер может автоматически переводить некоторые HTTP-ресурсы на HTTPS, а другие блокировать. Лучше исправить исходную ссылку, чем рассчитывать на одинаковое поведение во всех случаях. Эти различия описаны в справке MDN о mixed content.
Политика CSP с upgrade-insecure-requests может переводить обращения на HTTPS, но не создаёт сертификат и файл у поставщика. Если ресурс по HTTPS отсутствует, виджет всё равно не заработает. Отдельное сообщение «Refused to…» из-за CSP требует проверки разрешённых источников; это разобрано в руководстве по CSP.
Переезд самого сайта на HTTPS — другая задача. Для него пригодится проверка перенаправлений с HTTP.
Проверьте сценарий посетителя целиком
После исправления обновите страницу с отключённым кешем и снова откройте виджет. Проверьте загрузку окна, отправку тестового сообщения и ожидаемый результат. Если ошибка затрагивала форму, отдельно подтвердите получение сообщения по реальному каналу.
Повторите проверку на странице, где виджет подключён другим шаблоном: например, в каталоге и карточке товара. В аудите сайта можно проверить страницы после изменения, а действия внутри виджета дополнительно пройдите в браузере. Сохраните итог: какой HTTP-адрес заменили и какой сценарий теперь выполняется.