У меня есть nginx на интерфейсе, интерпретирующий ssl и перенаправляющий весь трафик без https на https:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://www.example.com$request_uri;
}
оттуда следующий блок сервера интерпретирует ssl и переходит к varnish:
server {
listen 443 ssl spdy;
server_name example.com www.example.com;
...<ssl stuff>...
location / {
proxy_pass http://127.0.0.1:6081;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Port 443;
proxy_set_header Host $host;
proxy_redirect off;
}
}
Я снял все с лака, чтобы помочь отладить мою проблему, поэтому теперь он просто возвращается к nginx на порт 8080
backend default {
.host = "127.0.0.1";
.port = "8080";
}
обратно в nginx порт 8080 серверный блок:
server {
listen 8080;
server_name example.com www.example.com;
...<access logs root index stuff>...
location ~ \.php$ {
try_files $uri =404;
include fastcgi_params;
fastcgi_pass php;
}
}
переменная php указывает на восходящий поток к hhvm на 127.0.0.1:hhvmport с откатом на 127.0.0.1:php-fpmport.
Когда я пытаюсь связаться с администратором WordPress, у меня возникает цикл перенаправления. Я не уверен, что это проблема Wordpress или проблема с настройкой сервера, потому что, когда я удаляю hhvm из восходящего потока и перехожу непосредственно к php-fmp, у меня нет никаких проблем. также curl -I https://www.example.com/wp-admin/ показывает 302 редирект на https://www.example.com/wp-admin/ вместо 301. Также, если я полностью уберу лак с изображения, hhvm разрешит доступ к wp-admin. Добавленные заголовки (X-Forwarded и т. Д.) Сбивают с толку hhvm и ожидают ли, что трафик будет поступать с 443?
/var/log/hhvm/error.log не показывает мне ничего, кроме создания jit. Включен журнал перенаправления в nginx, и это мне тоже не помогает. Не ожидал, но попытка стоила того.
Действительно запутался в том, что здесь происходит. Я не был уверен, относится ли это к разделу wordpress, поскольку удаление лака устраняет проблему или обход hhvm в разделе администратора WordPress также устраняет проблему, которая больше похожа на проблему с настройкой. Любая помощь приветствуется. Работает на Ubuntu 14.04, если это имеет какое-то значение.
Оказывается, мне нужно было добавить:
fastcgi_param HTTPS on;
в блоке местоположения, переходящем в php, и теперь все работает, как задумано.
Это может произойти, если вы настроили WordPress для перенаправления всего небезопасного трафика на безопасный URL-адрес (например, через .htaccess
). Что происходит, так это то, что приходит первый запрос, лишается заголовков SSL и попадает в WordPress, который замечает, что соединение небезопасно, и, следовательно, отправляет клиенту перенаправление вверх по течению.
Если вы не думаете, что WordPress делает это, попробуйте его с помощью простого PHP (что-то действительно простое, например <?php phpinfo(); ?>
). Если он делает это с помощью плоского PHP, лучший способ отладить это, как правило, состоит в том, чтобы либо прослушать трафик между точками A и B (чтобы увидеть, где возникает разрыв между ожидаемым трафиком и реальностью), либо перейти непосредственно к интересному порты (например, через http://host:port/
Синтаксис URI, изменяя файл «hosts» и / или используя переадресацию портов) и поднимайтесь по стеку по одной службе за раз, пока не получите данные, не соответствующие тому, что вы ожидаете.