私は私のnginx設定に関する奇妙な問題を解決しようとしていましたが、それはDebianバックポートアップグレードを適用した後すぐに機能しなくなったようです。
私のブログのランディングページ( http://blog.balaji-dutt.name/ )は問題なく動作しますが、他のパーマリンクをクリックすると( 例1 、 例2) )はnginx 404エラーをスローします。
これが私の設定です。これは今ではほとんど the Codex の標準的な設定です。
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;
}
}
これは、パーマリンクにアクセスしようとしたときにnginxエラーログに表示されるものです( 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/"
Nginxが.phpファイルのlocationディレクティブを読んでいないように見えますが、なぜそうなるのか私は理解できませんでした。どんな提案や助けも大歓迎です!
Nginxのルートロケーションのディレクトリ一覧:
# 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
URL( http://blog.balaji-dutt.name/2013/481-nginx-Apache-w3-total-cache-a-bad-combination/ )にアクセスしようとすると、ここにありますnginxエラーログに表示される内容
*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/"
/var/www/wordpress/
の後の部分は実際にはパーマリンクであり、なぜそれがリクエストに追加されるのか私にはわからないので、エラーログのパスは混乱しやすいです。
ディスク拡張キャッシュ用のW3 Total Cacheによって作成されたnginx設定ファイルはパーマリンクを壊すことになりますが、ファイルはnginxリロードでのみ読み取られるので、サイトはnginxをリロード/再起動するまで機能します。詳細な回答と作業設定が この回答 に投稿されています。
ディスク拡張モードが有効な場合にW3 Total Cacheが挿入するnginx設定はパーマリンクを解除しますが、W3 Total CacheがDisk Enhnacedモードの設定を挿入した後にnginxを再起動した場合のみです。
birgireの 提案に基づいて、私はすべてのプラグインをオフにしてサイトをチェックしたところ、正しく機能し始めました。その後、W3 Total Cacheをオンにし、 サプライズ を使用しました。サイトは引き続き正しく機能していました。 W3 Total Cacheが作成したnginx.confファイルがロードされてサイトが壊れた時点でnginxを再起動するまで、それは正しく機能し続けました。この現象の原因は次のとおりです。
if ($w3tc_rewrite = 1) {
rewrite .* "/wp-content/cache/page_enhanced/$http_Host/$request_uri/_index$w3tc_rewrite$w3tc_ext" last;
}
Nginxを再起動すると、上記の行が読み込まれ、すべてのURLがwp-content/cache/page_enhanced
内のキャッシュされたHTMLファイルにリダイレクトされます。再起動すると、HTMLファイルは削除され、リンクは404になります。私が思いついた解決策は、W3 Total Cacheが通常書き込むnginx設定ファイルのアクセス権を変更して上書きできないようにすることでした。それから私は上記の設定を変更しました:
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;
}
設定はいくつかのことをします - 元の書き換え行はlocationブロックの中にラップされているのでHTMLファイルが見つからなくても通常のindex.phpレンダリングモデルにフォールバックします。さらに、w3tc_rewrite_test
行はダッシュボードのエラーを排除するためのものです。私のW3 TCの設定を一元管理するために別のファイルでこれを行っているので、私のサイトには2つのlocation \
ディレクティブがあります。
余計なことに、W3 Total Configのminifyモジュール用のnginx設定も壊れています。これが動作する設定です1:
#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
Wordpress/W3 Total Cacheの情報の多くはバージョンに依存するため、上記の設定のバージョン情報は次のとおりです。W3 Total Cache v0.9.4/Wordpress 4.0/nginx 1.6.2-2〜bpo70 + 1