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!
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.
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 .
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