☰

nginx > barniz > hhvm

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

Tengo nginx en la interfaz interpretando ssl y redirigiendo todo el tráfico que no sea https a https:

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

a partir de ahí, el siguiente bloque del servidor interpreta ssl y pasa a barniz:

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

Quité todo el barniz para ayudar a depurar mi problema, por lo que a partir de ahora simplemente vuelve a nginx en el puerto 8080.

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

De vuelta en el bloque del servidor 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;
   }
}

la variable php apunta a un flujo ascendente de hhvm en 127.0.0.1:hhvmport con un respaldo a 127.0.0.1:php-fpmport.

Cuando intento comunicarme con el administrador de WordPress, aparece un bucle de redireccionamiento. No estoy seguro de si se trata de un problema de WordPress o de configuración del servidor porque cuando elimino hhvm del flujo ascendente y voy directamente a php-fmp no tengo ningún problema. también rizo -yohttps://www.example.com/wp-admin/muestra una redirección 302 ahttps://www.example.com/wp-admin/en lugar de 301. Además, si quito el barniz de la imagen por completo, hhvm permite el acceso a wp-admin. ¿Los encabezados agregados (X-Forwarded, etc.) confunden a hhvm y esperan que el tráfico provenga de 443?

/var/log/hhvm/error.log no me muestra nada excepto que se está creando jit. Se activó el registro de redireccionamiento en nginx y tampoco me ayuda. No me lo esperaba, pero valió la pena intentarlo.

Realmente confundido en cuanto a lo que está pasando aquí. No estaba seguro de si esto pertenecía a la sección de WordPress, ya que quitar el barniz soluciona el problema o omitir hhvm en la sección de administración de WordPress también soluciona el problema, parece más bien un problema de configuración. Cualquier ayuda sería muy apreciada. Ejecutándose en Ubuntu 14.04 si eso tiene alguna importancia.

Respuesta1

Esto puede suceder cuando haya configurado WordPress para redirigir todo el tráfico inseguro a una URL segura (por ejemplo, a través de .htaccess). Lo que sucede es que llega la primera solicitud, se le quitan los encabezados SSL y llega a WordPress, que nota que la conexión no es segura y, en consecuencia, envía una redirección al cliente.

Si no crees que WordPress esté haciendo esto, pruébalo con PHP plano (algo realmente sencillo como <?php phpinfo(); ?>). Si lo hace con PHP plano, la mejor manera de depurar esto tiende a ser olfatear el tráfico entre el punto A y el punto B (para ver dónde aparece la desconexión entre el tráfico esperado y la realidad), o ir directamente al punto interesante. puertos (por ejemplo, a través de la http://host:port/sintaxis URI, modificando su archivo "hosts" y/o usando el reenvío de puertos) y suba en la pila un servicio a la vez hasta que obtenga datos inconsistentes con lo que esperaría.

Respuesta2

Resulta que necesitaba agregar:

fastcgi_param HTTPS on;

en el bloque de ubicación pasando a php y ahora todo funciona según lo previsto.

información relacionada