У меня была эта проблема раньше. При запуске Wordpress (или других скриптов PHP) за Amazon EC2 Load Balancer скрипты не понимают, что они выполняются по протоколу https://и приводят к таким проблемам, как бесконечные циклы перенаправления и предупреждения HTTPS ( "Некоторое содержимое на этом страница запрашивается не защищенным способом..." ).
Я нашел решение здесь, но требует модификации ядра Wordpress, что не подходит для обновления: https://wordpress.org/support/topic/when-behind-amazon-web-services-elastic-load-balancer-causes-endless-redirect
Есть ли способ исправить это, не изменяя ядро Wordpress? Я использую Apache 2.2.
В качестве ссылки, которую вы предложили, для Wordpress проблема заключается в функции is_ssl()
, которая, как и большинство программ PHP, явно проверяет $_SERVER['HTTPS']
и $_SERVER['SERVER_PORT']
, чтобы проверить, доступна ли текущая страница в https://контекст.
Когда ваша страница обращается через HTTPS, но балансировщик загрузки Amazon выполняет разгрузку SSL и фактически запрашивает ваш контент на порту без SSL 80, веб-сервер, PHP или что-то еще в этом случае не понимает и не видит что к нему обращаются через https://.
Исправление для этого - это то, что Amazon ELB отправляет стандартный HTTP-заголовок X-Forwareded-Proto
HTTP, который мы можем использовать для определения того, какой протокол фактически использует клиент на другой стороне балансировки нагрузки.
С Apache 2.2 вы можете использовать что-то по строкам:
<IfModule mod_setenvif.c>
SetEnvIf X-Forwarded-Proto "^https$" HTTPS
</IfModule>
Это просто читает заголовок X-Forwared-Proto
, а если он равен https
, то устанавливает переменную среды https
в 1
. PHP увидит эту переменную среды, и в итоге она станет $_SERVER['HTTPS']
, которая равна 1
- так же, как и для "реального" собственного запроса SSL.
Другим вариантом из документации Wordpress является добавление этого в ваш wp-config.php:
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
$_SERVER['HTTPS']='on';
force_ssl_content(true);
в wp-config.php также. Обычно я делаю это через правило перезаписи Apache или в конфигурации балансировщика нагрузки.
Если кто-то еще искал эквивалент Nginx, вот что вам нужно сделать:
Для перезаписывания вы должны добавить следующее в блок server
:
if ($http_x_forwarded_proto != 'https') {
rewrite ^ https://$host$request_uri? permanent;
}
И для установки параметра HTTPS вы должны добавить следующее в блок location ~ \.php$
:
if ($http_x_forwarded_proto = 'https') {
set $fe_https 'on';
}
fastcgi_param HTTPS $fe_https;
Не забудьте удалить любую другую команду fastcgi_param HTTPS
, если она у вас есть (у меня она была в файле fastcgi_params
).
Ни один из вышеперечисленных проблем, к сожалению, не разрешил ошибки смешанного содержимого. Однако какая работа заключалась в добавлении протокола к WP_HOME && Переменные WP_SITEURL в wp-config.php, например.
define( 'WP_HOME', 'https://' . $_SERVER['HTTP_HOST']);
define( 'WP_SITEURL', WP_HOME );
После этого все URL-адреса источника начали с https, и все ошибки смешанного содержимого исчезли.
Используйте этот четырехэтапный метод, чтобы удалить цикл перенаправления и проблемы смешанного содержимого при использовании ssl в wordpress.
1) Замените 'http://' на '//' в базе данных - создайте все относительные URL-адреса для изображений и других активов
2) в wp-config, определите общие переменные wp_home и wp_siteurl.
define('WP_HOME','//'. $_SERVER['SERVER_NAME']);
define('WP_SITEURL','//'. $_SERVER['SERVER_NAME']);
3) Если вы используете балансировщик нагрузки, используйте переменную сервера HTTP_X_FORWARDED_PROTO для определения используемого протокола. Для этого добавьте эту строку в wp-config
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
$_SERVER['HTTPS']='on';
4) Наконец, в .htaccess, используйте эту строку, если вы отстаете от loadbalancer, чтобы перенаправить весь трафик на https.
# http to https
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule . https://%{HTTP:Host}%{REQUEST_URI} [L,R=permanent]