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" и / или используя переадресацию портов), и поднимайтесь по стеку по одной службе за раз, пока не получите данные, несовместимые с тем, что вы ожидаете.

Другие вопросы по тегам