☰

nginx > Lack > hhvm

tag-icon • tag-icon nginx varnish hhvm
nginx > Lack > hhvm

Ich habe Nginx auf dem Frontend, das SSL interpretiert und den gesamten Nicht-HTTPS-Verkehr auf https umleitet:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

Von dort interpretiert der nächste Serverblock SSL und übergibt es an 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;
    }
}

ich habe alles aus Varnish entfernt, um mein Problem zu debuggen, sodass es ab sofort einfach an Nginx auf Port 8080 zurückgegeben wird

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

zurück im Nginx-Port 8080-Serverblock:

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

die PHP-Variable verweist auf einen Upstream zu hhvm auf 127.0.0.1:hhvmport mit einem Fallback auf 127.0.0.1:php-fpmport.

Wenn ich versuche, den WordPress-Administrator zu erreichen, erhalte ich eine Umleitungsschleife. Ich bin nicht sicher, ob dies ein WordPress-Problem oder ein Server-Setup-Problem ist, denn wenn ich hhvm aus dem Upstream entferne und direkt zu php-fmp gehe, habe ich überhaupt keine Probleme. auch curl -Ihttps://www.example.com/wp-admin/zeigt eine 302-Weiterleitung zuhttps://www.example.com/wp-admin/statt 301. Auch wenn ich Varnish komplett aus dem Bild nehme, lässt hhvm den Zugriff auf wp-admin problemlos zu. Verwirren die hinzugefügten Header (X-Forwarded usw.) hhvm und lassen es erwarten, dass der Datenverkehr von 443 kommt?

/var/log/hhvm/error.log zeigt mir nichts an, außer dass JIT erstellt wird. Habe die Protokollumleitung in Nginx aktiviert und es hilft mir auch nicht. Das habe ich nicht erwartet, aber einen Versuch war es wert.

Wirklich verwirrt, was hier vor sich geht. Ich war mir nicht sicher, ob dies in den WordPress-Bereich gehört, da das Entfernen von Varnish das Problem behebt oder das Umgehen von hhvm im Admin-Bereich von WordPress das Problem ebenfalls behebt. Es scheint eher ein Setup-Problem zu sein. Für jede Hilfe wäre ich sehr dankbar. Läuft auf Ubuntu 14.04, falls das von Bedeutung ist.

Antwort1

Dies kann passieren, wenn Sie WordPress so konfiguriert haben, dass der gesamte unsichere Datenverkehr an eine sichere URL umgeleitet wird (z. B. über .htaccess). Was passiert, ist, dass die erste Anfrage eintrifft, von SSL-Headern befreit wird und WordPress erreicht, das feststellt, dass die Verbindung nicht sicher ist, und daraufhin eine Umleitung an den Client sendet.

Wenn Sie nicht glauben, dass WordPress dies tut, versuchen Sie es mit einfachem PHP (etwas wirklich Unkompliziertem wie <?php phpinfo(); ?>). Wenn es mit einfachem PHP funktioniert, besteht die beste Möglichkeit zum Debuggen darin, entweder den Datenverkehr zwischen Punkt A und Punkt B abzuhören (um zu sehen, wo die Diskrepanz zwischen erwartetem Datenverkehr und Realität auftritt) oder direkt zu den interessanten Ports zu gehen (z. B. über die http://host:port/URI-Syntax, indem Sie Ihre „Hosts“-Datei ändern und/oder Portweiterleitung verwenden) und den Stapel Dienst für Dienst nach oben zu gehen, bis Sie Daten erhalten, die nicht mit Ihren Erwartungen übereinstimmen.

Antwort2

Es stellte sich heraus, dass ich hinzufügen musste:

fastcgi_param HTTPS on;

im Standortblock, der an PHP übergeben wird, und jetzt funktioniert alles wie vorgesehen.

verwandte Informationen