Когда SSL активен, но блокировка браузера отсутствует, повреждена или показывает предупреждение, причина почти всегда в смешанном контенте: сама страница зашифрована, но что-то на ней по-прежнему загружается через простой HTTP. Это руководство объясняет, почему это происходит, как найти каждый проблемный ресурс и как правильно его исправить, а не замазать проблему.
Что такое смешанный контент
Браузер считает страницу защищённой только если страница и всё, что она загружает, получены через HTTPS. Если страница HTTPS загружает изображение, скрипт, таблицу стилей, шрифт или iframe с адреса http://, браузер это флагирует.
Браузеры делят это на две категории, и они ведут себя совершенно по-разному:
- Активный смешанный контент: скрипты, таблицы стилей, iframe и XHR. Браузеры блокируют их полностью. Макеты разваливаются, слайдеры перестают работать, формы перестают отправляться. Это разрушительный вид.
- Пассивный смешанный контент: изображения, аудио и видео. Они обычно всё ещё загружаются, но блокировка переходит в пониженный статус или удаляется.
Сайт может поэтому выглядеть полностью нормально и всё равно теряет блокировку, или выглядеть сломанным без очевидной ошибки на самой странице.
Почему это происходит после включения SSL
Включение SSL меняет способ отправки вашего сайта. Это не меняет то, что хранится внутри него.
WordPress записывает абсолютные URL в базу данных, поэтому сайт, который работал на HTTP какое-то время, имеет адреса http://, сохранённые в:
- Содержимое постов и страниц, включая каждое изображение, вставленное через редактор.
- Записи вложений медиа.
- Параметры кастомизатора тем и параметры тем.
- Содержимое виджетов и параметры блоков.
- Параметры плагинов, в частности конструкторы страниц и плагины слайдеров.
- Параметры
siteurlиhome.
Ничто из этого не обновляется само по себе. Включение SSL и последующее удивление, почему блокировка сломана, это один из самых частых вопросов в поддержке, и вот почему.
Шаг 1: Принудить HTTPS на сервере
Перед тем, как трогать базу данных, убедитесь, что каждый посетитель попадает на HTTPS с самого начала.
- Войдите в KPanel и нажмите Websites на левой боковой панели.
- Нажмите на ваш сайт.
- Откройте Settings.
- В разделе Behavior включите Принудить HTTPS.
- Нажмите Сохранить изменения.
Каждый HTTP-запрос теперь перенаправляется на HTTPS на сервере, прежде чем ваш сайт запустится.
Принудить HTTPS обрабатывает входящие запросы. Это не перезаписывает URL, уже сохранённые в вашей базе данных, поэтому само по себе это не очистит предупреждение о смешанном контенте, вызванное жёстко закодированным изображением http://. Вам нужны оба шага: этот и шаг 2.
Если SSL ещё не активен или сертификат выглядит неправильно, начните с SSL Certificates.
Шаг 2: Переписать сохранённые URL
Это исправление, которое действительно устраняет смешанный контент.
- Откройте сайт, затем вкладку WordPress, затем раздел Быстрые действия.
- Найдите карточку Поиск и замена и нажмите Configure.
- В поле Найти (старое значение) введите
http://yourdomain.co.nz. - В поле Заменить на введите
https://yourdomain.co.nz. - Оставьте Пробный запуск (только предпросмотр, без изменений) отмеченным и нажмите Preview.
- Проверьте количество и разбивку по таблицам.
- Снимите флажок Пробный запуск, нажмите Run и подтвердите.
Полная резервная копия создаётся автоматически перед заменой, и все таблицы покрыты, включая созданные плагинами. Сериализованные параметры плагинов обрабатываются правильно.
Не делайте это с SQL запросом в phpMyAdmin. WordPress хранит параметры плагинов и тем как сериализованные строки, которые записывают длину каждого значения, поэтому необработанный REPLACE() их ломает и параметры молча сбрасываются в пусто. Восстановления нет, кроме восстановления из резервной копии. Полное объяснение находится в Running a Search and Replace.
Если ваш план включает консоль, эквивалентная команда:
search-replace 'http://yourdomain.co.nz' 'https://yourdomain.co.nz' --all-tables --dry-run
Отбросьте --dry-run для применения, и сначала создайте резервную копию самостоятельно: консоль не делает.
Шаг 3: Очистить всё кэширование
Кэшированная копия страницы продолжит отправлять старые HTTP URL ещё долго после исправления базы данных, вот почему люди часто думают, что замена не сработала.
- WordPress, затем Быстрые действия, затем Очистить кэш.
- WordPress, затем Caching, затем Очистить кеш, если включено кэширование полной страницы.
- Performance, затем Kapsule CDN, затем Purge, если CDN включен. Смотрите Purging the CDN Cache.
- Любой плагин кэширования со своего экрана параметров.
- Ваш собственный браузер. Тестируйте в приватном окне, чтобы не вводить себя в заблуждение своим собственным кэшем.
Шаг 4: Найти то, что осталось
Большинство сайтов чистые после шага 2. Когда предупреждение остаётся, найдите точный ресурс вместо угадывания.
Консоль браузера. Откройте инструменты разработчика с F12, перейдите на вкладку Console и перезагрузитесь. Смешанный контент появляется как явное предупреждение, называющее полный URL проблемного ресурса. Этот URL говорит вам, какой плагин или тема ответственны.
Вкладка Network. Отфильтруйте по http:// для просмотра каждого небезопасного запроса, которое сделала страница.
Исходный код страницы. Загрузите страницу, посмотрите исходный код и поищите http://. Игнорируйте всё внутри xmlns атрибутов и объявлений схемы: это идентификаторы, не запросы.
Обычные уцелевшие ресурсы и что делать с каждым:
| Что вы нашли | Исправление |
|---|---|
| Изображение или логотип в параметре кастомизатора темы | Повторно загрузите или переберите его в кастомизаторе |
Модуль конструктора страниц с введённым вручную URL изображения http:// | Отредактируйте этот модуль и исправьте URL |
| Таблица параметров собственного плагина слайдера | Переохраните слайдер или запустите поиск и замену с --all-tables |
| Шрифт или скрипт от стороннего домена | Проверьте, предлагает ли поставщик HTTPS. Большинство теперь предлагает. Переключите URL |
| Пиксель отслеживания или встроенный код от старого поставщика | Если поставщик не имеет HTTPS, удалите его. Это сломанная зависимость, а не проблема KapsuleHost |
Жёстко закодированный http:// в файле шаблона темы | Отредактируйте шаблон или лучше используйте https или ссылку относительно протокола |
Если ровно одна страница затронута и остальная часть сайта чистая, виновник это содержимое на этой странице, а не сайт широко установку. Откройте её в редакторе и посмотрите, какие медиа она встраивает.
Подтверждение исправления
- Загрузите сайт в приватном окне.
- Блокировка должна быть сплошной, без предупредительного треугольника и без вычёркнутого указателя.
- Нажмите на блокировку. Браузер сообщает о соединении как безопасном без уведомления о смешанном контенте.
- Откройте консоль и перезагрузитесь ещё раз. Ноль предупреждений о смешанном контенте.
- Проверьте глубокую страницу, а не только главную: внутреннюю страницу, пост блога с изображениями и оформление заказа в магазине.
Предотвращение возвращения проблемы
- Оставьте Принудить HTTPS включённым. Это однострочный параметр, который удаляет целый класс проблем.
- Никогда не вводите полный URL
http://в содержимое. Используйте библиотеку медиа, которая теперь хранит адреса HTTPS. - Проверяйте параметры плагина после установки чего-либо, что запрашивает URL.
- Следите за возвращающимся предупреждением после обновления плагина. Некоторые плагины сбрасывают свои собственные сохранённые URL.
- Повторно запустите поиск и замену после любой миграции, так как импортированная база данных приносит с собой URL старого хоста: Migrating a Website From cPanel.
Решение проблем
Блокировка хорошо для меня, сломана для коллеги. Кэшированная страница. Попросите их перезагрузить в приватном окне.
Сайт полностью сломался после замены. Восстановите автоматическую резервную копию до запуска: Restoring From a Backup.
Консоль показывает предупреждение о смешанном контенте на домене, который не мой. Ресурс от третьей стороны. Вы не можете исправить их сервер: либо они поддерживают HTTPS и вы переключаете URL, либо вы удаляете ресурс.
Всё HTTPS, но сайт вообще не загружается. Это не смешанный контент. Начните с Website Not Loading и проверьте сертификат на SSL Certificates.
Если вы прошли через всё это и предупреждение остаётся, отправьте письмо по адресу support@kapsulehost.com с затронутым URL и точным текстом предупреждения консоли браузера.