Wordpress Subfolder issue with Nginx Configuration

Question

I am using wordpress and it's a multi-site subfolder config.

 - www.xyz.com is pointing to /var/www/project (Working)
 - (Wordpress blog) www.xyz.com/blog is pointing to /var/www/blog (Working)
 - (Wordpress blog) www.xyz.com/blog/page/2 (not working - Error given below) 

So if I open page www.xyz.com/blog/page/2 or www.xyz.com/blog/2015/11/15/takeup, it should point to /var/www/blog rather than pointing to /var/www/blog/page/2/index.php.

Here is my Nginx config file:

server {
     listen 80;
     server_name xyz.com;
     rewrite ^/(.*)/$ /$1 permanent;
     return 301 $scheme://www.xyz.com$request_uri;
}

server {
    listen   80 default_server;
    server_name www.xyz.com;
    index index.php index.html index.htm;

    location / {
        root /var/www/project/public;
            try_files $uri $uri/ /index.php?$query_string;


        location ~*  \.(jpg|jpeg|png|gif|ico|css|js)$ {
                expires 365d;
        }

        location ~*  \.(pdf)$ {
                expires 30d;
        }

        location ~ \.(?:css|htc|js|js2|js3|js4)$ {
                gzip_vary on;
        }

        # pass the PHP scripts to FastCGI server listening on /var/run/php5-fpm.sock

        location ~ \.php$ {
                try_files $uri /index.php =404;
                fastcgi_pass unix:/var/run/php5-fpm.sock;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME      $document_root$fastcgi_script_name;
                include fastcgi_params;
        }
    }

    location /blog {
           alias /var/www/blog;
           if (!-e $request_filename) {
               rewrite /wp-admin$ $scheme://$host$uri/ permanent;
               rewrite ^/[_0-9a-zA-Z-]+(/wp-.*) $1 last;
               rewrite ^/[_0-9a-zA-Z-]+(/.*\.php)$ $1 last;
           }     
           location ~ \.php$ {  
               #try_files $uri =404;
               fastcgi_split_path_info ^(.+\.php)(/.+)$;
               fastcgi_pass unix:/var/run/php5-fpm.sock;
               fastcgi_index index.php;                 
               #fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
               include fastcgi_params;
          }
          rewrite ^/sitemap_index\.xml$ /index.php?sitemap=1 last;
          rewrite ^/([^/]+?)-sitemap([0-9]+)?\.xml$ /index.php?sitemap=$1&sitemap_n=$2 last;
    }   
}

I am getting 404:

2016/01/23 23:27:05 [error] 32532#0: *2 "/var/www/blog/page/2/index.php" is not found (2: No such file or directory), client: 27.5.217.2, server: www.xyz.com, request: "GET /blog/page/2/ HTTP/1$

(Edited to improve error log formatting)

Answer 1

My best guess is the problem is the alias you have in your blog location is a problem, plug your config looks messy. I have one site that serves random PHP on the document root and Wordpress single site in the blog folder, here's the important parts of the config I use. Note I've removed all caching and header manipulation, and I use HHVM not PHP.

I also have a WPMU site, it doesn't require anything special in the way of location block configuration. I couldn't the child blogs to be in a subfolder, that's why I have one Wordpress single site install as well.

They key is you may not need a location block for your blog, you may just need try_files in your root block with "/blog/index.php?args"

server {
  server_name example.com;
  root /var/www/whatever;


  # Default location to serve
  location / {
    # If the file can't be found try adding a slash on the end - it might be
    # a directory the client is looking for. Then try the Wordpress blog URL
    # this might send a few requests to PHP that don't need to go that way
    try_files $uri $uri/ /blog/index.php?args;
    more_clear_headers Server; more_clear_headers "Pragma"; more_clear_headers "Expires";
  }

  # Send HipHop and PHP requests to HHVM
  location ~ \.(hh|php)$ {
    fastcgi_keep_conn on;
    fastcgi_intercept_errors on;
    fastcgi_pass   php;
    include        fastcgi_params;
    fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
  }
}

I'm not 100% sure this will solve your problem, but it's the best I can do without doing the diagnosis myself. Even if this fails trying the ideas in this will give further information that might help solve the problem.