Назад | Перейти на главную страницу

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