web-dev-qa-db-ja.com

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;
    }
}

問題のデバッグに役立てるためにワニスからすべてを取り出したので、今のところ、ポート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:php-fpmportへのフォールバックで127.0.0.1:hhvmport上のhhvmへのアップストリームを指します。

wordpress adminに到達しようとすると、リダイレクトループが発生します。これがwordpressの問題なのか、サーバーセットアップの問題なのかわかりません。アップストリームからhhvmを削除し、php-fmpに直接移動します。問題はまったくありません。curl-I https://www.example.com/wp-admin/ は、302リダイレクトを示しています- https://www.example.com/wp-admin/ 301の代わりに。また、画像からワニスを完全に取り除く場合は、hhvmでwp-adminへのアクセスを許可します。ヘッダーは追加されていますか(X-転送など)hhvmを混乱させ、トラフィックが443から来ることを期待していますか?

/var/log/hhvm/error.logには、jitが作成されている以外は何も表示されません。nginxでリダイレクトログがオンになっていて、それも役に立ちません。期待していなかったが、一撃の価値があった。

ここで何が起こっているのか本当に混乱しています。これがwordpressセクションに属しているかどうかはわかりませんでした。ワニスを削除すると問題が修正されるか、wordpressの管理セクションでhhvmをバイパスすると、問題も修正されるためです。セットアップの問題のようです。助けていただければ幸いです。それが重要な場合は、Ubuntu14.04で実行してください。

3
user44176

追加する必要があることがわかりました:

fastcgi_param HTTPS on;

phpに渡されるロケーションブロックで、すべてが意図したとおりに機能しています。

1
user44176

これは、すべての安全でないトラフィックを安全なURLにリダイレクトするようにWordPressを構成した場合に発生する可能性があります(例:_.htaccess_経由)。最初のリクエストが到着し、SSLが削除されます。ヘッダーを作成し、WordPressにアクセスすると、接続が安全でないことがわかり、その結果、リダイレクトがアップストリームにクライアントに送信されます。

WordPressがこれを行っていると思わない場合は、フラットなPHP(<?php phpinfo(); ?>のような本当に簡単なもの)で試してみてください。これはフラットPHPで実行されます。これをデバッグする最良の方法は、ポイントAとポイントBの間のトラフィックをスニッフィングするか(予想されるトラフィックと現実の間の切断がどこにあるかを確認するため)、または対象のポートに直接移動することです。 (たとえば、_http://Host:port/_ URI構文を介して、「hosts」ファイルを変更するか、ポート転送を使用して)、期待するものと矛盾するデータが得られるまで、一度に1サービスずつスタックを上げます。

1
BMDan