☰

nginx > varnish > hhvm

tag-icon • tag-icon nginx varnish hhvm
nginx > varnish > 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からすべてを取り出したので、今のところはポート8080のnginxに渡されるだけです。

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 変数は、127.0.0.1:hhvmport 上の hhvm へのアップストリームを指し、127.0.0.1:php-fpmport にフォールバックします。

wordpress の管理者にアクセスしようとすると、リダイレクト ループが発生します。これが wordpress の問題なのか、サーバー設定の問題なのかはわかりません。アップストリームから hhvm を削除して php-fmp に直接アクセスすると、まったく問題が発生しません。また、curl -Ihttps://www.example.com/wp-admin/302リダイレクトを表示しますhttps://www.example.com/wp-admin/301 ではなく。また、varnish を完全に削除すると、hhvm は wp-admin へのアクセスを問題なく許可します。追加されたヘッダー (X-Forwarded など) が hhvm を混乱させ、トラフィックが 443 から来ると想定しているのでしょうか?

/var/log/hhvm/error.log には、jit が作成されていること以外は何も表示されません。nginx でリダイレクト ログをオンにしましたが、これも役に立ちませんでした。期待していませんでしたが、試してみる価値はありました。

ここで何が起こっているのか本当に混乱しています。この問題は、WordPress セクションに属するものかどうかわかりませんでした。varnish を削除すると問題が解決するか、WordPress の管理セクションで hhvm をバイパスすると問題が解決するかはわかりません。セットアップの問題のようです。どなたか助けていただければ幸いです。Ubuntu 14.04 で実行していますが、それが重要かどうかはわかりません。

答え1

これは、安全でないトラフィックをすべて安全な URL ( 経由など.htaccess) にリダイレクトするように WordPress を設定した場合に発生することがあります。最初のリクエストが到着し、SSL ヘッダーが削除されて WordPress に到達します。WordPress は接続が安全でないことに気づき、結果としてクライアントにリダイレクトをアップストリームで送信します。

WordPress がこのような動作をしていないと思われる場合は、フラット PHP ( のような非常に単純なもの<?php phpinfo(); ?>) で試してみてください。フラット PHP でこのような動作をする場合、デバッグする最善の方法は、ポイント A とポイント B の間のトラフィックをスニッフィングする (予想されるトラフィックと実際のトラフィックの断絶がどこで発生しているかを確認する) か、または、関心のあるポートに直接アクセスし (たとえば、http://host:port/URI 構文経由、"hosts" ファイルの変更、および/またはポート転送の使用)、予想と矛盾するデータが表示されるまで、一度に 1 つのサービスずつスタックを上っていくことです。

答え2

結局、次の内容を追加する必要がありました:

fastcgi_param HTTPS on;

location ブロックで php に渡され、すべてが意図したとおりに動作するようになりました。

関連情報