Question
Redirect loop with Wordpress on Apache with nginx reverse proxy and HTTPS on Ubuntu 16
- Posted May 4, 2017
- ApacheNginxWordPressUbuntu 16.04
I’m experimenting with a DO droplet to host my Wordpress blog, setting it up myself because I’m difficult that way.
I configured Apache with TLS via Lets Encrypt and migrated my Wordpress blog over, and everything was working fine.
I then put nginx in front of Apache as a reverse proxy and configured nginx as the TLS terminator, redirecting any non-https to https using the tutorials here.
Now I can access any static files which are served up by nginx, and accessing a phpinfo() test file on Apache works fine. But accessing any Wordpress php files, like index.php or admin triggers a redirect loop.
What did I do wrong? Here’s my nginx config
# Default server configuration
#
server {
listen 80;
listen [::]:80;
server_name demo.EXAMPLE.com;
# redirect all http to https
return 301 https://$server_name$request_uri;
}
server {
# SSL configuration
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
include snippets/ssl-demo.EXAMPLE.com.conf;
include snippets/ssl-params.conf;
root /var/www/demo.EXAMPLE.com/public_html;
index index.php index.html index.htm;
server_name demo.EXAMPLE.com;
location / {
try_files $uri $uri/ /index.php;
}
# proxy PHP requests to Apache
location ~ \.php$ {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_pass http://127.0.0.1:8080$request_uri;
}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
location ~ /\.ht {
deny all;
}
}
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
The only issue with your server block that I can see is within the location block that handles PHP.
location ~ \.php$ {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_pass http://127.0.0.1:8080$request_uri;
}
Specifically, this line:
proxy_pass http://127.0.0.1:8080$request_uri;
You shouldn’t need to add $request_uri to the end of the proxy, so my first recommendation would be to remove $request_uri from the URL and leave it as:
proxy_pass http://127.0.0.1:8080;
Another issue is most likely due to termination of SSL. WordPress doesn’t handle proxies all that well and from what I’ve read, have no intention on implementing anything to make it easier, so you may need to add a bit of code to your wp-config.php file.
Open wp-config.php and find:
define('WP_DEBUG', false);
Directly below it, add:
if ( $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' )
{
$_SERVER['HTTPS'] = 'on';
$_SERVER['SERVER_PORT'] = 443;
}
Close and save the file, then refresh the page and see if you’re still seeing the loop.
If yes, and you happen to be using CloudFlare, there’s a fix for that too :-). CloudFlare needs to be set to use Full (Strict) under the SSL/Crypto menu (should be the first option). Without Full (Strict), you end up with a loop that seems hopeless.
If none of that works, my first recommendation would be to check the error logs.
tail -50 /var/log/nginx/error.log
Please paste the output in to a code block as a reply.
…
My second recommendation, ditch Apache as you don’t need it, even for WordPress (or any other CMS for that matter). NGINX + PHP-FPM can handle more than Apache can with mod_php and the setup is pretty darn simple (I’ll be more than happy to help if you want to go that route).
Try DigitalOcean for free
Click below to sign up and get $100 of credit to try our products over 60 days!
Also I noticed that a reply was given suggesting disappointing results with adding nginx to apache. There was mention of mod php without explaining this further.
Might I suggest checking to see whether or not you are running mpm prefork (which is default) or mpm worker or mpm event.
My understanding is that mpm prefork is a bit of a resource hog, so “mpm worker” and “mpm event” are the preferred option if the system is struggling a bit.
@digitalocean would be great to have a one-click LEMP/LAMP stack on Ubuntu 18.04 with nginx running on the front side of apache. Like what serverpilot offers.
actually i had setup my ubuntu server with vesta cp (apache with nginx proxy). i installed letsencrypt and it installed successfully. the problem is ssl works only with vestacp admin panel on port 8083. other than that document root (public_html) never works. I tried all possible fixes googling and it never worked. i checked everything. port 443 is open. but still not loading.
the error i get in firefox is : **"Secure Connection Failed, The connection to ****.com was interrupted while the page was loading. The page you are trying to view cannot be shown because the authenticity of the received data could not be verified."
none of my firewall configuration blocking it. i have removed and reinstalled letsencrypt certificates using certbot successfully but the same thing happens again. there are two files created by vestacp for nginx config. one is for normal http “nginx.conf” and another one is for https “snginx.conf” my nginx.conf has the following codes:
the only modification i made here was code in “### Add SSL specific settings here ###” .i checked nginx config and restarted it was ok. but still not working.
there are two files created by vestacp for apache config. one is for normal http “apache2.conf” and another one is forhttps “sapache2.conf” my sapache2.conf file has following code in it
i tried reloading and restarting apache and nginx. it runs ok but https only works on port 8083, vestacp admin panel. i tried disabling firewalls and checked. the result is same.
all i can see is in chrome it reloads several times like establishing secure connection, connecting and finaly error follows after few seconds. in firefox, error as said above. i checked by placing a dummy index.html in my home directory (moving wordpress index.php). but same error comes.
please help me. i am cracking my head here…
This comment has been deleted