wake-up-neo.net

Die Homepage wird geladen, aber alle Permalinks sind 404, wenn Nginx und PHP-FPM verwendet werden

Ich habe versucht, ein seltsames Problem mit meiner Nginx-Konfiguration zu lösen, das kurz nach dem Anwenden eines Debian-Backports-Upgrades nicht mehr zu funktionieren scheint.

Die Landing Page meines Blogs ( http://blog.balaji-dutt.name/ ) funktioniert einwandfrei, aber ein Klick auf einen anderen Permalink ( Beispiel 1 , Beispiel 2 ) wirft a nginx 404 fehler.

Hier ist meine Konfiguration, die jetzt so ziemlich die Standardkonfiguration von dem Codex ist:

server {
    listen 80;
    server_name blog.balaji-dutt.name;
    error_log /var/log/nginx/blog-error.log;
    access_log /var/log/nginx/blog-access.log combined;

    ## Your only path reference.
    root /var/www/wordpress;
    ## This should be in your http block and if it is, it's not needed here.
    index index.php;

    #Gzip
    include /etc/nginx/sites-available/gzip.conf;

    location / {
            # This is cool because no php is touched for static content. 
            # include the "?$args" part so non-default permalinks doesn't break when using query string
            try_files $uri $uri/ /index.php?$args;
    }

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    location ~ /\.ht {
            deny  all;
            access_log off;
    }

    location ~ \.php$ {
            try_files $uri =404;

            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            include fastcgi_params;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            #fastcgi_intercept_errors on;
            fastcgi_pass   127.0.0.1:9010;
    }

}

Folgendes wird im nginx-Fehlerprotokoll angezeigt, wenn ich versuche, auf einen Permalink zuzugreifen ( http://blog.balaji-dutt.name/about/ ):

2014/10/19 03:35:09 [error] 21698#0: *76739 "/var/www/wordpress/about/index.php" is not found (2: No such file or directory), client: 174.36.241.151, server: blog.balaji-dutt.name, request: "GET /about/ HTTP/1.1", Host: "blog.balaji-dutt.name", referrer: "http://blog.balaji-dutt.name/"

Es sieht so aus, als würde Nginx die Location-Direktive für .php-Dateien nicht lesen, aber ich konnte nicht herausfinden, warum dies der Fall ist. Anregungen oder Hilfe ist sehr willkommen!

Update 1 - 20.10.2014

Verzeichnisliste für den Nginx-Stammspeicherort:

    # ls -la /var/www/wordpress
total 256
drwxr-xr-x  5 blog   www-data  4096 Sep 28 03:09 .
drwxr-xr-x  8 www-data www-data  4096 Jan 15  2014 ..
-rw-r--r--  1 blog   www-data   418 Sep 25  2013 index.php
-rw-r--r--  1 blog   www-data 19930 May 16 22:23 license.txt
-rw-r--r--  1 blog   www-data  1764 Oct  5 01:17 nginx.conf
-rw-r--r--  1 blog   www-data  7192 Sep 28 03:09 readme.html
-rw-r--r--  1 blog   www-data 55174 Mar 27  2014 sitemap.backup.xml
-rw-r--r--  1 blog   www-data  7125 Mar 27  2014 sitemap.backup.xml.gz
-rw-r--r--  1 blog   www-data  4951 Sep 28 03:09 wp-activate.php
drwxr-xr-x  9 blog   www-data  4096 Dec 12  2013 wp-admin
-rw-r--r--  1 blog   www-data   271 Jan  8  2012 wp-blog-header.php
-rw-r--r--  1 blog   www-data  4946 Sep 28 03:09 wp-comments-post.php
-rw-r--r--  1 blog   www-data  2746 Sep 28 03:09 wp-config-sample.php
-rw-r--r--  1 blog   www-data   237 Dec 22  2013 wp-config.php
drwxr-x---  9 blog   www-data  4096 Sep 28 03:09 wp-content
-rw-r--r--  1 blog   www-data  2956 Sep 28 03:09 wp-cron.php
drwxr-xr-x 12 blog   www-data  4096 Sep 28 03:09 wp-includes
-rw-r--r--  1 blog   www-data  2380 Oct 24  2013 wp-links-opml.php
-rw-r--r--  1 blog   www-data  2714 Sep 28 03:09 wp-load.php
-rw-r--r--  1 blog   www-data 33043 Sep 28 03:09 wp-login.php
-rw-r--r--  1 blog   www-data  8252 Sep 28 03:09 wp-mail.php
-rw-r--r--  1 blog   www-data 11115 Sep 28 03:09 wp-settings.php
-rw-r--r--  1 blog   www-data 26256 Sep 28 03:09 wp-signup.php
-rw-r--r--  1 blog   www-data  4026 Oct 24  2013 wp-trackback.php
-rw-r--r--  1 blog   www-data  3032 May 16 22:23 xmlrpc.php

Wenn ich versuche, auf die URL ( http://blog.balaji-dutt.name/2013/481-nginx-Apache-w3-total-cache-a-bad-combination/ ) zuzugreifen, wird Folgendes angezeigt im nginx-fehlerprotokoll

*14 "/var/www/wordpress/2013/481-nginx-Apache-w3-total-cache-a-bad-combination/index.php" is not found (2: No such file or directory), client: 174.36.241.151, server: blog.balaji-dutt.name, request: "GET /2013/481-nginx-Apache-w3-total-cache-a-bad-combination/ HTTP/1.1", Host: "blog.balaji-dutt.name", referrer: "http://blog.balaji-dutt.name/"

Der Pfad im Fehlerprotokoll ist verwirrend, da der Teil nach /var/www/wordpress/ eigentlich der Permalink ist und ich nicht sicher bin, warum er der Anfrage hinzugefügt wird.

Update 2 - 25.10.2014 [Gelöst]

Es stellt sich heraus, dass die von W3 Total Cache für Disk Enhanced Caching erstellte nginx-Konfigurationsdatei die Permalinks unterbricht. Da die Datei jedoch nur beim erneuten Laden von nginx gelesen werden kann, funktioniert die Site, bis Sie nginx erneut laden/neu starten. Detaillierte Antwort und eine funktionierende Konfiguration in diese Antwort .

3
avggeek

Es stellt sich heraus, dass die von W3 Total Cache eingefügte nginx-Konfiguration bei aktiviertem festplattenverbesserten Modus die Permalinks unterbricht, jedoch nur, wenn Sie nginx neu starten, nachdem W3 Total Cache die Konfiguration für den festplattenverbesserten Modus eingefügt hat.

Aufgrund des Vorschlags von birgire habe ich alle Plugins deaktiviert und die Website überprüft, die ordnungsgemäß funktioniert hat. Ich habe dann W3 Total Cache eingeschaltet und Überraschung ! Die Seite funktionierte weiterhin korrekt. Es funktionierte weiterhin einwandfrei, bis ich nginx neu startete. Zu diesem Zeitpunkt wurde die von W3 Total Cache erstellte Datei nginx.conf geladen und die Site ging kaputt. Was dieses Verhalten verursacht, ist die folgende Zeile:

if ($w3tc_rewrite = 1) {
rewrite .* "/wp-content/cache/page_enhanced/$http_Host/$request_uri/_index$w3tc_rewrite$w3tc_ext" last;
}

Wenn nginx neu gestartet wird, wird die obige Zeile geladen und alle URLs werden in zwischengespeicherte HTML-Dateien in wp-content/cache/page_enhanced umgeleitet. Beim Neustart werden die HTML-Dateien jedoch gelöscht und die Links werden zu 404. Die Lösung, die ich gefunden habe, bestand darin, zunächst die Berechtigungen für die Nginx-Konfigurationsdatei zu ändern, in die W3 Total Cache normalerweise schreibt, damit sie nicht überschrieben werden kann. Ich habe dann die obige Konfiguration geändert:

location / {
    rewrite ^(.*\/)?w3tc_rewrite_test/?$ $1?w3tc_rewrite_test=1 last;
    if ($w3tc_rewrite = 1) {
        rewrite .* "/wp-content/cache/page_enhanced/$http_Host/$request_uri/_index$w3tc_rewrite$w3tc_ext" last;
    }
    try_files $uri $uri/ /index.php?$args;
} 

Die Konfiguration führt einige Dinge aus - die ursprüngliche Zeile zum Umschreiben wird in einen Location-Block eingeschlossen, sodass die HTML-Datei auch dann auf ein reguläres index.php-Rendering-Modell zurückgreift, wenn sie nicht gefunden wird. Außerdem soll die Zeile w3tc_rewrite_test einen Fehler im Dashboard beseitigen. Ich mache dies in einer separaten Datei, um meine W3 TC-Konfiguration zu zentralisieren, sodass es zwei location \-Direktiven für meine Site gibt.

Für zusätzliches Guthaben stellt sich heraus, dass die Nginx-Konfiguration für das Minify-Modul von W3 Total Config ebenfalls fehlerhaft ist. Hier ist eine funktionierende Konfiguration1:

#Test Rewrites
    location ~ ^/wp-content/cache/minify/[^/]+/(w3tc.*)$ {
                   try_files $uri /wp-content/plugins/w3-total-cache/pub/minify.php?w3tc_rewrite_test=$1;
           }
#End Test Rewrites
# BEGIN W3TC Minify core
    set $w3tc_enc "";
    location ~ ^/wp-content/cache/minify/(.+/[X]+\.css)$ {
                try_files $uri /wp-content/plugins/w3-total-cache/pub/minify.php?test_file=$1;
    }
    location ~ ^/wp-content/cache/minify/(.+\.(css|js))$ {
                try_files $uri /wp-content/plugins/w3-total-cache/pub/minify.php?file=$1;
    }

# END W3TC Minify core

Da viele Wordpress/W3-Gesamtcache-Informationen versionsabhängig sind, finden Sie hier die Versionsinformationen für die obige Konfiguration: W3-Gesamtcache v0.9.4/Wordpress 4.0/nginx 1.6.2-2 ~ bpo70 + 1


1https://rtcamp.com/wordpress-nginx/tutorials/single-site/w3-total-cache/
2
avggeek