nginx > лак> hhvm
У меня есть nginx на внешнем интерфейсе, интерпретирующий ssl и перенаправляющий весь не-https трафик на https:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://www.example.com$request_uri;
}
оттуда следующий блок сервера интерпретирует ssl и переходит на лак:
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, если это имеет какое-либо значение.
2 ответа
Оказывается, мне нужно было добавить:
fastcgi_param HTTPS on;
в блоке местоположения, переходящем к php, и все теперь работает как положено.
Это может произойти, если вы настроили WordPress для перенаправления всего незащищенного трафика на защищенный URL-адрес (например, через .htaccess
). Что происходит, так это то, что первый запрос приходит, лишается заголовков SSL и обращается к WordPress, который замечает, что соединение небезопасно, и, следовательно, отправляет перенаправление вверх по потоку к клиенту.
Если вы не думаете, что WordPress делает это, попробуйте это с каким-то плоским PHP (что-то действительно простое, как <?php phpinfo(); ?>
). Если он делает это с плоским PHP, лучший способ отладить это, как правило, либо перехватывать трафик между точкой A и точкой B (чтобы увидеть, где появляется разрыв между ожидаемым трафиком и реальностью), либо переходить непосредственно к интересующему порты (например, через http://host:port/
Синтаксис URI, изменив файл "hosts" и / или используя переадресацию портов), и поднимайтесь по стеку по одной службе за раз, пока не получите данные, несовместимые с тем, что вы ожидаете.