#Суть неисправности и признаки
На сайте WordPress файлы медиатеки доступны по https://, но после вставки изображения редактор формирует ссылку с http://. Браузер может блокировать её как смешанное содержимое или автоматически преобразовывать URL. Разница между доступностью одного файла по HTTPS и сохранённым адресом в контенте требует отдельной проверки. Причиной обычно бывает старый базовый адрес сайта, сохранённые HTTP-ссылки в блоках, настройка CDN либо неверное определение HTTPS за прокси. Не включайте отключение проверки сертификатов и не меняйте URL сайта без резервной копии.
#Почему возникает проблема
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| WordPress считает основным HTTP-адресВ параметрах home/siteurl или конфигурации ядра сохранился http://. | При вставке нового изображения получается HTTP, несмотря на доступность HTTPS. | Проверить параметры и фактический адрес входа. |
| В записи хранятся старые абсолютные ссылкиРедактор сохраняет прежний URL в атрибутах блоков и HTML. | Проблема только со старыми изображениями, новая загрузка использует HTTPS. | Изменять сохранённые адреса сериализованно-совместимым инструментом и после копии. |
| Прокси неверно сообщает протоколВнешний HTTPS завершается перед WordPress, но приложение видит внутренний HTTP. | Перенаправления и ссылки генерируются на HTTP только при работе за CDN. | Сверить настройки доверенного прокси и правильность HTTPS. |
| Оптимизатор или CDN переписывает URLДополнение меняет домен изображений или схему адресов. | Без определённого дополнения на тестовой копии ссылки правильные. | Проверить настройку URL медиа и плагина. |
#Пошаговая диагностика и устранение
- Различите старый контент и новую вставкуОткройте в WordPress «Записи» → «Все записи» → тестовую запись и вставьте новый файл из «Медиафайлы». Сохраните черновик, откройте в редакторе параметры изображения и посмотрите адрес или HTML блока через меню редактора. Сравните с изображением из прежней записи. Если HTTP только у старых блоков, причина может быть в контенте, а не в настройках новых загрузок.
- Найдите фактический URL, который блокирует браузерОткройте публичную страницу и нажмите F12 → «Консоль» и «Сеть». Найдите предупреждение Mixed Content и полный URL, который редактор или браузер запросил по HTTP. Отличайте заблокированный запрос от автоматического повышения до HTTPS, которое современный браузер может выполнять. Зафиксируйте исходный HTML/атрибут src, а не только итоговую строку адреса после перенаправления.
- Проверьте настройки сайтаВ админке откройте «Настройки» → «Общие». Проверьте «Адрес WordPress (URL)» и «Адрес сайта (URL)»: при рабочем HTTPS и стандартной схеме они должны использовать HTTPS. Если поля недоступны, ищите WP_HOME и WP_SITEURL в wp-config.php. Перед исправлением запишите значения и убедитесь, что сертификат и перенаправление HTTPS действительно работают: иначе можно потерять доступ к панели.
- Сравните реальную выдачу сайта и поведение проксиЕсли используется CDN/обратный прокси, убедитесь, что запросы посетителя приходят через HTTPS, а WordPress получает корректные сведения о первоначальной схеме. Посмотрите журнал редиректов: не должно быть циклов между http и https. Не копируйте в wp-config.php чужой код доверия всем X-Forwarded-Proto — сначала узнайте у хостинга, какие прокси доверенные и где правильно задаётся протокол.
- Проверьте правило перенаправления и CDN для картинокВ настройках хостинга или CDN посмотрите политику HTTPS и исходный домен изображений. В браузере откройте проблемный URL по HTTPS и проверьте HTTP-код. Если HTTPS работает, а HTML по-прежнему содержит HTTP, включение редиректа не исправляет неправильные ссылки у пользователя: требуется исправить источник формирования URL. Не отключайте проверку безопасности ради обхода предупреждений.
- При необходимости подготовьте безопасную замену старых адресовЕсли после исправления home/siteurl новые вставки правильные, но старые блоки остались с HTTP, выгрузите базу данных и резервную копию файлов. При установленном WP-CLI можно сделать пробный
wp search-replaceс --dry-run и --skip-columns=guid. Это не изменяет таблицы; внимательно оцените количество совпадений. Не используйте обычный SQL REPLACE для всех полей: сериализованные настройки тем и виджетов могут повредиться. - Примените изменение адресов только после проверки копииНа тестовой копии сайта выполните WP-CLI search-replace без --dry-run с точно указанной старой и новой схемой на своём домене; убедитесь, что корректны блоки, виджеты и меню. На рабочем сайте делайте это только после проверенного восстановления из копии и согласования с владельцем: массовая операция меняет данные. Если затронут только один блок, безопаснее исправить ссылку вручную в редакторе.
- Сверьте новую и старую записи, затем очистите кешСоздайте новую тестовую публикацию с изображением и откройте уже существующую. Во вкладке «Сеть» проверьте, что URL изображений имеют HTTPS, сертификаты действительны, загрузка возвращает 200, а консоль не сообщает Mixed Content. Если HTTP остаётся, откатите последнее изменение из резервной копии и исследуйте настройки плагина/прокси; CDN очищайте после исправления исходного HTML.
- В SSH от пользователя WordPress, в его каталоге и при наличии WP-CLILinux · Терминал (Bash)КомандаВ SSH от пользователя WordPress, в его каталоге и при наличии WP-CLI. Замените example.com на свой домен, убедитесь, что в результатах нет ненужных совпадений. Пример только диагностический: с --dry-run данные не меняются.
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run
#Как проверить результат и что делать, если не помогло
Успех подтверждается не только открытием картинки по HTTPS, но и тем, что новый блок и сохранённый HTML прежних записей больше не содержат некорректные http:// для этого домена. Если сайт многосайтовый или использует отдельный CDN-домен, не применяйте глобальную замену без карты доменов и резервных копий.