☰

nginx > лак > hhvm

tag-icon • tag-icon nginx varnish hhvm
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;
    }
}

Я удалил все из Varnish, чтобы помочь отладить мою проблему, так что на данный момент он просто возвращается к nginx на порт 8080

backend default {
.host = "127.0.0.1";
.port = "8080";
}

обратно в блок сервера nginx port 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 из upstream и перехожу напрямую к php-fmp, у меня вообще нет никаких проблем. Также curl -Ihttps://www.example.com/wp-admin/показывает 302 перенаправление наhttps://www.example.com/wp-admin/вместо 301. Также, если я полностью уберу Varnish из картины, hhvm разрешит доступ к wp-admin без проблем. Запутывают ли hhvm добавленные заголовки (X-Forwarded и т. д.) и ожидают ли они, что трафик будет идти с 443?

/var/log/hhvm/error.log не показывает мне ничего, кроме того, что jit создается. Включил перенаправление журнала в nginx, и это тоже не помогает. Не ожидал, что это поможет, но попробовать стоило.

Действительно запутался, что здесь происходит. Я не был уверен, относится ли это к разделу WordPress, так как удаление Varnish исправляет проблему, или обход hhvm в разделе администратора WordPress также исправляет проблему, это больше похоже на проблему настройки. Любая помощь была бы очень признательна. Работает на Ubuntu 14.04, если это имеет какое-либо значение.

решение1

Это может произойти, если вы настроили WordPress на перенаправление всего небезопасного трафика на безопасный URL (например, через .htaccess). Происходит следующее: первый запрос поступает, лишается заголовков SSL и попадает в WordPress, который замечает, что соединение не защищено, и, следовательно, отправляет перенаправление вверх по течению к клиенту.

Если вы не думаете, что WordPress делает это, попробуйте сделать это с каким-нибудь простым PHP (чем-то действительно простым, например <?php phpinfo(); ?>). Если это происходит с простым PHP, лучшим способом отладки обычно является либо прослушивание трафика между точкой A и точкой B (чтобы увидеть, где появляется разрыв между ожидаемым трафиком и реальностью), либо переход напрямую к интересующим портам (например, через http://host:port/синтаксис URI, путем изменения файла "hosts" и/или использования переадресации портов) и переход по стеку по одной службе за раз, пока не получите данные, не соответствующие ожидаемым.

решение2

Оказывается, мне нужно было добавить:

fastcgi_param HTTPS on;

в блоке location перехожу в php и теперь все работает так, как задумано.

Связанный контент