SiteGuard4 ноября 202616 мин чтения

Mixed Content: как найти и исправить смешанный контент на HTTPS-сайте

Mixed Content возникает, когда HTTPS-страница пытается загрузить ресурс по незащищённому HTTP-адресу. Чтобы исправить смешанный контент, нужно найти такой запрос, определить, откуда берётся адрес, проверить доступность ресурса по HTTPS и изменить источник ссылки. Новый SSL-сертификат сам по себе не переписывает URL в шаблонах, базе данных и сторонних виджетах.

Для посетителя проблема выглядит вполне конкретно: пропали фотографии товара, не работает калькулятор, исчезла карта или форма перестала отправлять заявку. Ниже — порядок диагностики в Chrome DevTools, исправления HTML, CSS, JavaScript и WordPress, а также проверки результата после очистки кеша. Примеры с example.com иллюстративные: используйте реальные адреса своего проекта.

Что такое Mixed Content на HTTPS-сайте

Предположим, страница каталога открыта по https://example.com/catalog/, но её шаблон ссылается на http://cdn.example.com/app.js. Документ получен по защищённому соединению, а дополнительный ресурс запрашивается по HTTP. Такой сценарий относится к смешанному контенту. Запрос может быть создан HTML-разметкой, таблицей стилей, JavaScript или вставленным сторонним компонентом.

Схожую ситуацию после подключения CDN разбирает документация Cloudflare. Наличие HTTPS у основной страницы не означает, что все связанные файлы автоматически получили корректные защищённые адреса. Особенно часто проблема обнаруживается после переноса, смены домена, обновления темы или подключения старого виджета.

Обычная ссылка на внешний HTTP-сайт и загрузка HTTP-скрипта внутри защищённой страницы — разные действия браузера. Не считайте каждое найденное в тексте http:// доказательством Mixed Content. Для диагностики нужен фактический запрос ресурса из защищённого контекста и сообщение о его обработке. Отдельного внимания требуют скачивания и отправка форм: там тоже важно проверить защищённость конечного соединения.

Наблюдение	Направление диагностики	Что исправлять
HTTPS-страница пытается получить скрипт по HTTP	Mixed Content	Адрес ресурса и источник, который его сформировал
Браузер отклоняет сертификат самого сайта	Срок, имя и доверие сертификату	Конфигурацию TLS и предъявляемый сертификат
HTTPS API доступен, но браузер запрещает читать ответ с другого origin	Возможная проблема CORS	Правила обмена между конкретными источниками
Ресурс имеет HTTPS, но запрещён политикой страницы	Возможная проблема Content Security Policy	Адрес ресурса и действующую CSP

Эти ошибки могут появляться последовательно. После замены HTTP на HTTPS запрос доходит до сервера и выявляет другую проблему, например CORS или неверный MIME-тип. Это повод продолжить диагностику по новому сообщению, а не вернуть незащищённый адрес. Назначение CORS описано в справке MDN.

Почему одни ресурсы видны, а другие заблокированы

Современное поведение браузеров нельзя свести к правилу «картинки разрешены, скрипты запрещены». Для части HTTP-запросов применяется автоматическая замена схемы на HTTPS, другие блокируются. Это описано в руководстве MDN по Mixed Content. Успешная автозамена не означает, что старый адрес исчез из вашего кода.

Ресурс в HTTPS-странице	На что ориентироваться	Что проверить владельцу
Изображение в обычном `img src`, аудио или видео	Для предусмотренных типов браузер может повысить запрос до HTTPS	Фактический URL, доступность защищённой версии и предупреждения
Скрипт, таблица стилей, iframe, запрос fetch или шрифт по HTTP	Такие смешанные запросы относятся к блокируемым	Источник HTTP-адреса и работоспособность HTTPS-замены
Изображение из `srcset` или `picture`	Не переносите на него правила обычного `img src`	Все варианты изображения, выбранные на разных экранах
HTTP-ресурс с IP-адресом вместо имени	Обычное автоматическое повышение смешанных запросов имеет исключение для IP	Подходящий HTTPS-адрес с корректным сертификатом

Исключения для IP и набора изображений отражены в рабочей спецификации Mixed Content. Для публичного сайта исправляйте исходные адреса и проверяйте целевые браузеры. Сценарии локальных устройств и специальных разрешений браузера требуют отдельной настройки и не являются универсальным решением для интернет-магазина.

Практический вывод: видимая фотография ещё не доказывает отсутствие проблемы. В одном браузере адрес может автоматически преобразоваться, на другом экране будет выбран иной вариант из srcset, а старый CSS продолжит запрашивать шрифт по HTTP. Проверять нужно реальные запросы и действия пользователя, а не только внешний вид первого экрана.

Как найти Mixed Content в Chrome DevTools

Начните со страницы и действия, где проявляется сбой. Если карта появляется после открытия вкладки «Контакты», воспроизведите именно этот шаг. Если ошибка возникает в корзине после расчёта доставки, одной загрузки главной страницы будет недостаточно. Запишите браузер, адрес и последовательность действий, чтобы повторить проверку после правки.

Шаг 1. Найдите сообщение в Console

Откройте нужную HTTPS-страницу и выберите инструменты разработчика в меню браузера.
Перейдите в Console, очистите предыдущие сообщения и перезагрузите страницу.
Выполните действие, которое загружает проблемный элемент: прокрутку, открытие окна, выбор варианта товара или запуск формы.
Найдите сообщение с Mixed Content. Сохраните адрес страницы, адрес ресурса и указание на блокировку либо автоматическое повышение до HTTPS.

Запросы вроде mixed content the page at обычно появляются после копирования начала английского сообщения консоли. Читать нужно всю строку: она связывает защищённую страницу с конкретным незащищённым ресурсом. Условная запись проблемы может выглядеть так:

Страница: https://example.com/catalog/
Запрошенный ресурс: http://cdn.example.com/app.js
Результат: Mixed Content, загрузка заблокирована

Точный текст зависит от браузера и версии. Не ищите ошибку только по одному заранее известному коду. Если консоль показывает HTTPS-адрес с ошибкой сертификата, зафиксируйте и его: возможна попытка автоматического повышения, после которой обнаружилась отдельная TLS-проблема ресурса.

Шаг 2. Свяжите запрос с источником

В панели Network найдите проблемный адрес, откройте сведения о запросе и изучите Initiator. Для JavaScript он помогает увидеть, какой код инициировал загрузку; для других ресурсов полезны связанный документ и цепочка зависимостей. Возможности просмотра инициаторов описаны в справке Chrome DevTools Network.

Запишите не только имя файла, но и место формирования URL. Например, ошибка в checkout.bundle.js может исходить из настройки apiBaseUrl, переданной сервером. Ручная замена текста внутри собранного файла исчезнет при следующей сборке. Исправлять следует настройку или исходный модуль, из которого создаётся этот файл.

Шаг 3. Исключите влияние кеша

На время диагностики используйте Disable cache в DevTools и повторите загрузку. Это помогает сравнить результат без обычного браузерного кеша, но не очищает CDN, кеш CMS и все механизмы приложения. Если старый адрес продолжает приходить в свежем HTML-ответе, причина находится выше уровня локального кеша.

Для сайта с service worker проверьте раздел Application → Service Workers и Cache Storage. В документации Chrome описаны просмотр worker и диагностическое обращение к сети через Bypass for network. Используйте сравнение в своей тестовой сессии, затем верните обычный режим: обход worker не обновляет его у посетителей.

Сохраните минимальную карточку ошибки

Достаточно пяти полей: страница, действие, незащищённый URL, инициатор и наблюдаемый результат. Добавьте владельца компонента — ваша тема, плагин или внешний поставщик. Такой список удобнее для исправления, чем скриншот десятков одинаковых сообщений. Объединяйте повторения по источнику, но сохраняйте разные пользовательские сценарии.

Где искать HTTP-адреса внутри сайта

Простой поиск по исходному HTML полезен как первый шаг. Однако адрес может появиться только после выполнения JavaScript или находиться в настройках конструктора. Поэтому сопоставляйте поиск с данными Network: отсутствие строки в исходнике страницы не доказывает отсутствие запроса.

Место	Что искать	Где обычно вносится правка
HTML и шаблоны	`src`, `href` ресурсов, `srcset`, iframe и встроенные настройки	Шаблон, компонент или редактор блока
CSS	`url()`, `@import`, изображения и файлы шрифтов	Исходная таблица стилей или настройка генератора CSS
JavaScript	Базовый адрес API, динамическая загрузка, конфигурация виджета	Исходный модуль, переменная окружения или серверная настройка
CMS и конструктор	Контент записей, настройки темы, виджеты и данные блоков	Админка или корректная миграция нужных данных
Внешний сервис	Код вставки карты, чата, видео, аналитики	Актуальный код поставщика и параметры интеграции
Кеш и сборка	Старый HTML, объединённый CSS, предыдущий JavaScript bundle	Повторная генерация и обновление конкретного слоя кеширования

Если у вас есть локальная копия исходников и установлен rg, можно выполнить поиск по известным каталогам проекта:

rg -n 'http://' templates assets src

Названия каталогов здесь условные: замените их существующими папками своего проекта. Команда ищет строки в файлах, но не анализирует базу данных и не воспроизводит страницу. Результаты просматривают по смыслу. Ссылки в документации, пространства имён XML и обычные текстовые примеры нельзя механически переписывать как загружаемые ресурсы.

Проверьте также адреса, которые собраны из нескольких частей: схема хранится в одном параметре, домен — в другом. Если URL генерируется на сервере из настроек окружения, исправление одной записи в контенте не устранит системную причину. Для мультиязычного сайта или нескольких доменов сравните настройки каждой реально используемой версии.

Как исправить Mixed Content без поломки ресурсов

Для каждого найденного адреса ответьте на два вопроса: существует ли рабочая HTTPS-версия и кто управляет источником ссылки. Сначала проверяют защищённую точку, затем меняют адрес. Одна замена букв в URL не создаёт сертификат, файл или поддержку нужного API-метода на сервере поставщика.

1. Проверьте HTTPS-версию ресурса

Откройте подходящий HTTPS-адрес и убедитесь, что он возвращает нужный ресурс, а не страницу входа, заглушку или ошибку. Для статического изображения сравните содержимое. Для скрипта или CSS проверьте статус, тип содержимого и отсутствие перенаправления обратно на HTTP. Для API проверяйте поддерживаемый путь, метод и параметры в согласованной тестовой среде.

После смены схемы могут измениться origin и требования к доступу. Не отправляйте реальные платёжные запросы или повторные заявки только ради проверки нового адреса. Для интеграций используйте тестовый режим поставщика либо согласованный безопасный сценарий. При ошибке сертификата на внешнем ресурсе обратитесь к его владельцу или замените зависимость.

2. Измените адрес в исходном месте

Пример исправленной ссылки на собственное изображение после проверки HTTPS:

<img src="https://example.com/images/product.webp" alt="Фотография товара">

Для ресурса того же сайта можно использовать путь от корня, если он соответствует архитектуре проекта:

<img src="/images/product.webp" alt="Фотография товара">

Проверьте базовый URL документа: тег base влияет на разрешение относительных адресов. Указание //cdn.example.com/file.js без схемы тоже зависит от контекста и не делает HTTP-сервер защищённым. Для внешней зависимости обычно понятнее явный проверенный HTTPS-адрес из актуальной инструкции поставщика.

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

3. Обновите зависимость, которая не поддерживает HTTPS

Для стороннего виджета запросите современный код вставки или защищённую точку подключения. Если поставщик не поддерживает HTTPS, рассмотрите замену компонента. Перенос статического файла на свой сервер возможен только с учётом прав использования, обновлений и зависимостей. Простое копирование интерактивного сервиса обычно не сохраняет его работу.

Не создавайте универсальный открытый прокси, который получает произвольные чужие URL ради «исправления SSL». Такой механизм добавляет собственные риски и обслуживание. Для критичной интеграции архитектуру подключения должен определить разработчик с учётом авторизации, данных и условий поставщика.

4. Проверьте всю цепочку загрузки

HTTPS-скрипт может сам запросить HTTP API, а защищённый CSS — подключить старый шрифт. После замены верхнего адреса повторите пользовательское действие и просмотрите новые запросы. Если зависимостей несколько, исправляйте их до последнего фактического ресурса, а не до исчезновения первого сообщения.

HTTP-редирект ресурса на HTTPS не является универсальным исправлением: браузер может заблокировать смешанный запрос до обращения к HTTP-серверу. Укажите корректный защищённый URL в источнике. Общий редирект главной страницы решает другую часть перехода на HTTPS и не заменяет работу с её содержимым.

Как убрать смешанный контент в WordPress

Начните с точного источника: контент записи, настройка темы, данные конструктора, виджет или файл плагина. Изменение адреса сайта в общих настройках не гарантирует замены всех ранее сохранённых ссылок. Если проблема только в одном блоке, исправление этого блока обычно понятнее массовой операции по всей базе.

Сначала подготовьте восстановление и область правки

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

WordPress и плагины могут хранить настройки в сериализованном виде. Обычная строковая замена в SQL-дампе не всегда сохраняет такую структуру. Официальное руководство по переносу WordPress рассматривает изменения адресов и способы работы с данными; используйте инструменты, которые понимают формат хранилища.

Пример ограниченной замены через WP-CLI

Ниже — пример для администратора, у которого уже установлен WP-CLI и выбран каталог нужного сайта. Исправляется только старый адрес медиафайлов своего домена. Таблицы с префиксом wp_ условные: подставьте реальные имена и подтвердите, что именно они входят в задачу.

wp search-replace 'http://example.com/wp-content/uploads/' 'https://example.com/wp-content/uploads/' wp_posts wp_postmeta wp_options --skip-columns=guid --dry-run

Команда wp search-replace обрабатывает PHP-сериализацию; --dry-run показывает результат без сохранения замен, а список таблиц ограничивает область. --skip-columns=guid оставляет GUID без изменения. Проверьте отчёт и ожидаемое число совпадений до реальной операции.

Если область подтверждена, копия проверена и тестовый результат подходит, тот же запрос без --dry-run применяет изменения:

wp search-replace 'http://example.com/wp-content/uploads/' 'https://example.com/wp-content/uploads/' wp_posts wp_postmeta wp_options --skip-columns=guid

Этот пример не исправляет все возможные ресурсы, пользовательские таблицы плагинов и отдельные сайты Multisite. Не добавляйте --all-tables для удобства: в базе могут находиться другие проекты. Дополнительные таблицы и адреса включают только после анализа. При отсутствии доступа по SSH задайте такую же ограниченную задачу администратору или используйте подходящий инструмент миграции.

Завершите исправление на уровне приложения

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

Если после каждого сохранения контента HTTP-адрес возвращается, найдите его генератор. Причиной может быть настройка плагина, адрес CDN или неверно определяемая схема запроса за прокси. Повторяющаяся массовая замена скрывает эту зависимость только до следующего обновления.

Что проверить при использовании CDN или обратного прокси

CDN может отдавать посетителю HTTPS-страницу, внутри которой приложение сохранило HTTP-ссылки. Поэтому отдельно проверяют защищённое соединение и содержимое ответа. Смена сертификата на CDN не является командой на обновление базы данных CMS или стороннего JavaScript.

В Cloudflare функция Automatic HTTPS Rewrites может помочь с переписыванием подходящих ссылок. Документация описывает условия и ограничения, включая ресурсы, загружаемые JavaScript или CSS. Рассматривайте её как дополнительный механизм: подтвердите результат в браузере и устраните устаревшие адреса в управляемом вами источнике.

Проверьте, как приложение определяет исходную схему запроса за прокси. Например, в режиме Flexible соединение от Cloudflare к исходному серверу идёт по HTTP, хотя посетитель использует HTTPS. Неверная настройка приложения может приводить к формированию неподходящих ссылок. Заголовкам о схеме доверяют только в согласованной конфигурации доверенного прокси.

Не добавляйте вслепую новый редирект на origin: при несовместимой схеме он может создать цикл. Такой случай разобран в инструкции Cloudflare по перенаправлениям. Настройку защищённого соединения до origin и корректного распознавания HTTPS выполняют с учётом всей цепочки.

После исправления обновите нужные объекты кеша CDN и приложения. Сравните свежий ответ с тем, что получал браузер до изменения. Полная очистка всех кешей без необходимости увеличивает объём действий; важнее понять, какой слой продолжает отдавать старую разметку.

Поможет ли Content-Security-Policy: upgrade-insecure-requests

Директива upgrade-insecure-requests просит браузер обрабатывать незащищённые URL ресурсов как защищённые. Это может быть полезно при переходном состоянии большого сайта, если целевые ресурсы уже поддерживают HTTPS. Пример заголовка ответа:

Content-Security-Policy: upgrade-insecure-requests

Как объясняет MDN, изменение выполняется до отправки запроса. Если HTTPS-версия не работает, возврата к HTTP не будет. Директива не выдаёт сертификаты внешним серверам и не переписывает сохранённый контент CMS.

Перед включением проверьте зависимости и существующую CSP. Не заменяйте действующий заголовок целиком приведённой строкой: так можно потерять другие правила. Способ добавления зависит от сервера, приложения и CDN. После изменения проверьте фактически полученный заголовок и загрузку ресурсов в целевых браузерах.

Такая директива не завершает весь перевод сайта на HTTPS и не заменяет отдельную политику HSTS. У неё также есть ограничения для навигационных переходов. Для этой задачи важнее получить рабочие защищённые ресурсы и постепенно исправить исходные URL, сохраняя понятную конфигурацию.

Старые инструкции могут предлагать block-all-mixed-content. Сейчас эта директива помечена как устаревшая. Не добавляйте её как обязательный универсальный рецепт. Отключение защиты браузера, разрешение небезопасного содержимого и игнорирование ошибок сертификата также не исправляют сайт для посетителей.

Как проверить, что смешанный контент исправлен

Критерий результата — нужные ресурсы загружаются по корректным защищённым адресам, а пользовательский сценарий работает в обычных настройках браузера. Одного исчезнувшего предупреждения на компьютере разработчика недостаточно, если посетителям продолжает выдаваться старый кеш.

Повторите исходный сценарий. Откройте ту же страницу, выполните прокрутку, выбор товара, раскрытие блока или другое действие.
Проверьте Console и Network. Убедитесь, что прежнего Mixed Content нет, а замена не создала ошибку TLS, CORS, CSP, MIME-типа или загрузки файла.
Проверьте разные шаблоны. Главная, категория, карточка, статья, контакты, корзина и личный кабинет могут использовать разные компоненты.
Сравните экраны и состояния. Мобильная версия, варианты из srcset, вход и выход из аккаунта, язык и согласие на загрузку внешнего виджета меняют набор запросов.
Проверьте обычную работу кеша. После диагностических режимов повторите открытие как новый и возвращающийся посетитель.
Проверьте формы и скачивания. Уточните конечные защищённые адреса, а для формы подтвердите результат тестовой отправки в согласованном окружении.
Сохраните результат. Запишите исправленный источник, затронутые страницы, дату и исполнителя.

Для формы проверьте атрибут action, JavaScript-обработчик и адрес фактического запроса. Видимая HTTPS-страница не оправдывает отправку введённых данных по HTTP. Поведение предупреждений зависит от браузера, поэтому критерием должна быть защищённая передача и успешная обработка, а не отсутствие одного конкретного баннера.

Для большого сайта начните с перечня шаблонов и важных действий, затем расширяйте проверку на обнаруженные варианты. Статический обход страниц помогает собрать адреса, но может не воспроизводить авторизацию, отложенную загрузку и действия после клика. Укажите границы проверки в отчёте, чтобы «найдено ноль ошибок» не воспринималось как проверка функций, которые инструмент не запускал.

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

Что передать разработчику и как организовать контроль

В обращении укажите адрес страницы, действие, HTTP-ресурс, инициатор и ожидаемое поведение. Например: «На HTTPS-странице корзины после выбора доставки запрос идёт на HTTP API из настройки виджета. Нужна проверка защищённой точки и обновление адреса в конфигурации». Приложите очищенный от токенов и персональных данных фрагмент отчёта.

Такую задачу удобно принимать по двум результатам: исправлен управляемый источник URL и подтверждена работа нужного сценария. Отдельно отметьте оставшиеся зависимости от стороннего поставщика. Это помогает распределить ответственность и не считать косметическое изменение строки завершённой работой.

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

Частые вопросы о Mixed Content

Нужно ли перевыпускать SSL-сертификат?

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

Почему проверка показывает ошибку только на телефоне?

Мобильная версия может выбирать другое изображение из srcset, подключать отдельный блок или выполнять иной сценарий. Сравните конкретный запрос и инициатор в проблемном варианте. Сам по себе размер экрана не меняет HTTP на HTTPS.

Достаточно ли заменить все http:// на https://?

Сначала определите, какие строки являются адресами загружаемых ресурсов, и проверьте их HTTPS-версии. Механическая замена может повредить данные, затронуть чужие проекты или создать неработающие зависимости. В CMS используйте подходящий форматам данных инструмент и ограниченную область изменения.

Почему после исправления ошибка осталась?

Проверьте свежий HTML, собранные стили и скрипты, кеш CDN, данные CMS и service worker. Затем сравните URL ошибки: возможно, первый источник уже исправлен, но найден следующий ресурс. Работайте с текущим запросом и его инициатором.

Можно ли оставить автоматическое повышение HTTP до HTTPS?

Оно помогает загрузке предусмотренных ресурсов, однако старый адрес остаётся зависимостью от поведения браузера и настроек. Исправление источника делает конфигурацию понятнее и упрощает последующие переносы. Для внешнего ресурса всё равно необходима рабочая HTTPS-версия.

Официальные материалы

Инструкции и ограничения сверены 31 октября 2026 года. При работе ориентируйтесь на фактический отчёт браузера и актуальную документацию используемых компонентов.