WordPress dans le sous-répertoire sert la racine index.php sur nginx fastcgi

Question

Je rencontre un problème étrange sur mon serveur NGINX.

Comme expliqué dans le Codex, j'ai transféré wordpress de mon répertoire racine vers un sous-répertoire/blog /.

Il montre l'index de blogs avec succès, mais si je veux montrer quoi que ce soit d'autre, comme un poste ou une page spécifique de l'archive, il sert la racine index.php

Même URL inexistantes sont servis sous forme de l'indice racine. php

Si je supprime la racine index.php, elle renvoie une erreur 404.

Peut-être son dû à mes paramètres nginx et FastCGI, mais je n'ai vraiment aucune idée:

server { 
    listen 80; 
    listen [::]:80; 

    root /var/www/html; 
    index index.php index.html index.htm; 

    client_max_body_size 10M; 

    # Make site accessible from http://localhost/ 
    server_name 


      set $no_cache 0; 
      if ($request_method = POST){set $no_cache 1;} 
      if ($query_string != ""){set $no_cache 1;} 
      if ($http_cookie = "PHPSESSID"){set $no_cache 1;} 
      if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") {set $no_cache 1;} 
      if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in"){set $no_cache 1;} 



    location ~ \.php$ { 
      try_files $uri =404; 
      fastcgi_split_path_info ^(.+\.php)(/.+)$; 
      fastcgi_cache microcache; 
      fastcgi_cache_key $scheme$host$request_uri$request_method; 
      fastcgi_cache_valid 200 301 302 30s; 
      fastcgi_cache_use_stale updating error timeout invalid_header http_500; 
      fastcgi_pass_header Set-Cookie; 
      fastcgi_no_cache $no_cache; 
      fastcgi_cache_bypass $no_cache; 
      fastcgi_pass_header Cookie; 
      fastcgi_ignore_headers Cache-Control Expires Set-Cookie; 
      fastcgi_pass unix:/var/run/php5-fpm.sock; 
      fastcgi_index index.php; 
      include fastcgi_params; 
    } 


    location/{ 
      # First attempt to serve request as file, then 
      # as directory, then fall back to displaying a 404. 
      # try_files $uri $uri/ =404; 
      try_files $uri $uri/ /index.php?q=$uri&$args; 
      # Uncomment to enable naxsi on this location 
      # include /etc/nginx/naxsi.rules 
    } 

} 

Edit: Mise à jour avec bloc entier serveur

Answer 1

L'instruction try_files envoie tous les fichiers aucun existant à index.php dans votre racine web. Ajouter un deuxième emplacement spécifique pour votre blog à la configuration:

location /blog { 
    try_files $uri $uri/ /blog/index.php; 
} 

try_files fonctionne comme suit:

vérifie l'existence de fichiers dans l'ordre spécifié et utilise le d'abord trouvé le fichier pour le traitement de la demande; le traitement est effectué dans le contexte actuel. Le chemin d'accès à un fichier est construit à partir du paramètre de fichier en fonction des directives root et alias. Il est possible de vérifier l'existence du répertoire en spécifiant une barre oblique à l'extrémité d'un nom, par ex. "$ Uri /". Si aucun des fichiers n'a été trouvé, une redirection interne vers l'URI spécifié dans le dernier paramètre est effectuée. Par exemple: