nginx > varnish > hhvm

Question

I have nginx on the front end interpreting ssl and redirecting all non https traffic to https:

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

from there the next server block interprets ssl and passes to 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;
    }
}

i have taken everything out of varnish to help debug my issue so as of now it just passes back to nginx on port 8080

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

back in nginx port 8080 server block:

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

the php variable points to an upstream to hhvm on 127.0.0.1:hhvmport with a fallback to 127.0.0.1:php-fpmport.

When i try to reach the wordpress admin i get a redirect loop. i'm not sure if this is a wordpress issue or server setup issue because when i remove hhvm from the upstream and go directly to php-fmp i have no issues whatsoever. also curl -I https://www.example.com/wp-admin/ shows a 302 redirect to https://www.example.com/wp-admin/ instead of 301. Also if i take varnish out of the picture completely hhvm allow access to wp-admin just fine. Are the headers added (X-Forwarded etc..) confusing hhvm and expecting traffic to be coming from 443?

/var/log/hhvm/error.log isn't showing me anything except jit being created Turned on redirect log in nginx and its not helping me either. Wasn't expecting it to but it was worth a shot.

Really confused as to whats going on here. I wasn't sure if this belonged in the wordpress section since removing varnish fixes the issue or bypassing hhvm in the admin section of wordpress also fixes the issue it seems more like a setup issue. Any help would be much appreciated. Running on Ubuntu 14.04 if that is of any significance.

score 1 · Answer 1 · answered Feb 23 '15 at 05:43

1

This can happen when you've configured WordPress to redirect all insecure traffic to a secure URL (e.g. through .htaccess). What happens is that the first request arrives, gets stripped of SSL headers, and hits WordPress, which notices the connection isn't secure, and consequently sends a redirect upstream to the client.

If you don't think WordPress is doing this, try it with some flat PHP (something really straightforward like <?php phpinfo(); ?>). If it does it with the flat PHP, the best way to debug this tends to be to either sniff traffic between Point A and Point B (to see where the disconnect between expected traffic and reality is appearing), or to go directly to the interesting ports (e.g. via the http://host:port/ URI syntax, by modifying your "hosts" file, and/or using port forwarding) and go up the stack one service at a time until you get data inconsistent with what you'd expect.

answered Feb 23 '15 at 05:43

BMDan

7,129
2
22
34

`back in nginx port 8080 server block:` the main site is being served via nginx+php-fpm, so `.htaccess` files aren't going to be relevant, though whatever in `wp-config.php` could be. A simpler test is to try accessing any static file e.g. `https://example.com/favicon.ico` - if a static file is accessible, php logic is invoking the loop. `if i take varnish out of the picture completely hhvm allow access to wp-admin just fine` - suggests headers being stripped - maybe. +1 for general "test in isolation" advice. – AD7six Feb 23 '15 at 09:45
Went through the stack piece by piece and determined that there was an issue going from nginx to hhvm. @AD7six I had the same line of thinking with the headers. It turns out I was missing the fastcgi_param HTTPS parameter which was screwing things up. PHP thought the request was coming over http and the server block on port 80 redirects all traffic back to 443 resulting in a loop. Got it fixed though thanks guys. – user44176 Feb 23 '15 at 22:50

score 1 · Accepted Answer · answered Feb 23 '15 at 22:53

1

Turns out I needed to add:

fastcgi_param HTTPS on;

in the location block passing to php and everything is now working as intended.

answered Feb 23 '15 at 22:53

user44176

41
5

nginx > varnish > hhvm

2 Answers2

Linked