WordPress redirect loop on site root. Nginx proxy apache

I’m setting up Nginx as a proxy to apache2 serving a WordPress installation. Issue is that on the root url appsrd.devmbs.com im getting a redirect loop. When I hit the server I see the following in the logs like 12-15 times.

127.0.0.1 - - [03/Sep/2012:12:29:25 +0000] "GET /index.php HTTP/1.0" 301 529 "http://appsrd.devmbs.com/wp-admin/options-general.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_0) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1"

But the /wp-admin works well. No redirect issue. I tried deleting the database, and while the db wasn’t available the root displayed a msg of Error establishing a database connection which is fine since this is the expected behavior but there was no redirect issue. Then I created the DB again and ran the wordpress setup, and when everything is done, the redirect issue comes back.

Read More

Beloe my nginx server conf:

server {
        listen       80 default_server;
        server_name  appsrd.devmbs.com;
        root /home/ubuntu/projecs/APPS-RD;
        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location / {
            root   /home/ubuntu/projects/APPS-RD;
            index  index.html index.htm index.php;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

        location ~ .php$ {
        proxy_pass   http://127.0.0.1:3000;
        proxy_buffering on;
        proxy_buffers 12 12k;
        proxy_set_header Host $host;
        }
}

The url is appsrd.devmbs.com, appsrd.devmbs.com/wp-admin works fine.

Anyone have a clue what might be happening?

Related posts

Leave a Reply

3 comments

  1. For any future person that may encounter this problem…

    1. Going this route isn’t really the most practical way of doing this.
    2. I was determined to make it work for the sake of doing it.

    For the purpose of my experiment I wanted Nginx to display any and all existing non-PHP files and to proxy the PHP files and the dynamic URL’s to Apache for WordPress to do its thing. I also wanted WordPress to be able to use the normal .htaccess file.

    The problem with the initial code that Luis’ original posted is that Nginx is explicitly declaring the use of index.php because it’s the only index that is given in a WordPress environment. The result is that when you go to “domain.com/” Nginx sends that to Apache looking exactly like “domain.com/index.php”. When WordPress receives “domain.com/index.php” it automatically shortens and redirects you to “domain.com/”; thus you end up with that loop.

    The best work around (for the determined) that works for a WordPress environment is to just send any directories to WordPress as well. The downside to this setup is that it will ignore any indexes that aren’t index.php.

    server {
            listen       80;
        server_name  domain.com;
        root   /path/to/web/root/;
    
    
        # Proxy anything that isn't a file.
        location / {
            try_files $uri @apache;
        }
    
        # Proxy directories (This fixes the loop)
        # This will kill any other indexes like index.html if they're not explicitly used in the URL.
        location ~[^?]*/$ {
            include proxy_apache;
        }
    
        # Proxy any .php file.
        location ~ .php$ {
            include proxy_apache;
        }
    
            # Proxy to apache, used by location / {...}
        location @apache {
            include proxy_apache;
        }
    
        # this will prevent files like .htaccess .htpassword .secret etc from being served
        # You can remove the log directives if you wish to
        # log any attempts at a client trying to access a hidden file
        location ~ /. {
            deny all;
            access_log off;
            log_not_found off;
        }   
    }
    

    If you noticed the contents of the file named *proxy_apache* which is included several times above is,

    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;
    

    Again, not necessarily the most practical solution but it does have the advantages of,

    1. Displaying any none-PHP files with Nginx instead of having to define an explicit list of static files in a regular expression.
    2. Using WordPress’s beloved .htaccess file; though you’re not likely to change the .htaccess file after the initial setup.
  2. I wanted the same thing Lucas did and I got it to work. Here is a basic example of my congiration.

    # A basic configuration with reverse proxy to apache2
    
    server {
      listen 80;
    
      server_name someurl.com www.someurl.com;
    
      root /var/www/someurl.com/html/;
    
      index index.php index.html index.html;
    
      access_log /var/log/nginx/someurl.com.access.log;
      error_log /var/log/nginx/someurl.com.error.log;
    
      # send anything with .php in it to apache
      location ~* .php$ {
        try_files /dev/null @proxy;
      }
    
      # for everything else, 
      location / {
        try_files $uri $uri/ @proxy;
        error_page 404 = @proxy;
      }
    
      # Deny access to all dotfiles
      location ~ /. {
        deny all;
      }
    
      # Named location for reverse proxy
      location @proxy {
        if ( $uri = /index.php ) {
          rewrite /index.php / break;
        }
        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;
      }
    }
    
    # need to add https support
    

    The key is the if statement inside my @proxy location. I check for a $uri and rewrite the request URI back to / using the break flag. This avoids the redirect loop.

    What’s weird is that the problem only occurred on the root index, not on subdirectory indexes. I appreciate any feedback on my configuration. It might have problems I have yet to discover, but as of now it’s providing me with what I need for WordPress deployment.

    GL!