Pagina principală se încarcă, dar toate legăturile permanente returnează 404 pe nginx și PHP-FPM

19 oct. 2014, 10:38:56
Vizualizări: 18.5K
Voturi: 4

Am încercat să rezolv o problemă ciudată cu configurația nginx, care pare să nu mai funcționeze corect după o actualizare Debian backports.

Pagina principală a blogului meu (http://blog.balaji-dutt.name/) funcționează normal, dar accesând orice altă legătură permanentă (Exemplul 1, Exemplul 2) primește o eroare 404 de la nginx.

Iată configurația mea, care acum este practic configurarea standard din 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;

    ## Calea către directorul rădăcină
    root /var/www/wordpress;
    ## Acest parametru ar trebui să fie în blocul http, dacă este acolo, nu mai e nevoie aici
    index index.php;

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

    location / {
            # Acest lucru este util pentru că conținutul static nu necesită PHP
            # include secțiunea "?$args" pentru a nu afecta legăturile permanente non-standard
            try_files $uri $uri/ /index.php?$args;
    }

    # blochează accesul la fișierele .htaccess
    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;
    }

}

Iată ce văd în jurnalul de erori nginx când încerc să accesez o legătură permanentă (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/"

Se pare că nginx nu interpretează corect directiva location pentru fișierele .php, dar nu am reușit să înțeleg de ce se întâmplă acest lucru. Orice sugestie sau ajutor este binevenit!

Actualizare 1 - 20 Octombrie 2014

Listare director pentru locația rădăcină 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

Când încerc să accesez URL-ul (http://blog.balaji-dutt.name/2013/481-nginx-apache-w3-total-cache-a-bad-combination/), iată ce apare în jurnalul de erori 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/"

Calea din jurnalul de erori este confuză, deoarece partea după /var/www/wordpress/ este de fapt legătura permanentă și nu sunt sigur de ce este adăugată la cerere.

Actualizare 2 - 25 Octombrie 2014 [REZOLVAT]

S-a dovedit că fișierul de configurare nginx creat de W3 Total Cache pentru caching Disk Enhanced poate strica legăturile permanente, dar deoarece fișierul este citit doar la reîncărcarea nginx, site-ul va funcționa până când reîncărcați/reporniți nginx. Răspuns detaliat și o configurație funcțională sunt postate în acest răspuns.

6
Comentarii

Ai setat permalinkurile tale la permalinkuri frumoase? Ai activat depanarea - văd doar un ecran alb când vizitez pagina ta principală, ceea ce mă face să cred că este vorba despre ecranul alb al morții :)

kaiser kaiser
19 oct. 2014 17:05:47

@kaiser - Încercam o serie de lucruri diferite și am postat o configurație nginx defectă. Am actualizat configurația pentru a arăta cum arată acum și ar trebui să poți vedea pagina principală, precum și erorile 404. Iată o captură de ecran cu setările mele de permalink: http://imgur.com/25mCkXM

avggeek avggeek
20 oct. 2014 04:20:22

Se pare că folosești multe lucruri nemintite aici, cum ar fi W3TC (disk:enhanced) cu CloudFront CDN, https și http-auth care ar putea afecta configurația ta. Cred că aș încerca să configurez un blog de test simplu sub un alt subdomeniu și să văd dacă configurația NginX de mai sus (care arată normal) funcționează și apoi să continui de acolo.

birgire birgire
22 oct. 2014 13:05:46

Ai încercat pașii discutați în acest fir de discuție?

Roman Roman
23 oct. 2014 03:37:07

@avggeek deci ai rezolvat problema. Vrei să ne spui cum ai făcut-o?

alpipego alpipego
24 oct. 2014 01:54:24

@alpipego - Sunt ocupat cu munca așa că nu pot posta un răspuns detaliat acum, dar o voi face în weekend. Pe scurt - W3 Total Cache Page Cache în modul Disk Enhanced creează o "condiție de concurență" cu repornirile nginx. Trecererea la modul Page Cache Basic rezolvă eroarea 404, deși rămân fără un Page Cache funcțional.

avggeek avggeek
24 oct. 2014 05:18:48
Arată celelalte 1 comentarii
Toate răspunsurile la întrebare 1
3

Se pare că configurația nginx pe care W3 Total Cache o inserează atunci când modul Disk Enhanced este activat va strica permalink-urile, dar numai dacă reporniți nginx după ce W3 Total Cache a injectat configurația pentru modul Disk Enhanced.

Bazându-mă pe sugestia lui birgire, am dezactivat toate plugin-urile și am verificat site-ul, care a început să funcționeze corect. Apoi am pornit W3 Total Cache și surpriză! site-ul a continuat să funcționeze corect. A continuat să funcționeze corect până când am repornit nginx, moment în care fișierul nginx.conf creat de W3 Total Cache a fost încărcat și site-ul s-a stricat. Ceea ce provoacă acest comportament este următoarea linie:

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

Când nginx este repornit, linia de mai sus este încărcată și toate URL-urile sunt redirecționate către fișierele HTML cache în wp-content/cache/page_enhanced. Însă la repornire, fișierele HTML sunt șterse și astfel link-urile devin 404. Soluția pe care am găsit-o a fost mai întâi să schimb permisiunile pe fișierul de configurare nginx pe care W3 Total Cache îl scrie în mod normal, astfel încât să nu poată fi suprascris. Apoi am modificat configurația de mai sus:

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;
} 

Configurația face câteva lucruri - linia originală de rewrite este încadrată într-un bloc de tip location, astfel încât chiar dacă fișierul HTML nu este găsit, se revine la un model obișnuit de randare index.php. În plus, linia w3tc_rewrite_test este pentru a elimina o eroare din Panoul de administrare. Fac asta într-un fișier separat pentru a centraliza configurația W3 TC, așa că există două directive location \ pentru site-ul meu.

Pentru bonus, se pare că configurația nginx pentru modulul de minificare al W3 Total Cache este de asemenea defectă. Iată o configurație funcțională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

Deoarece multe informații despre WordPress/W3 Total Cache depind de versiune, iată informațiile despre versiune pentru configurația de mai sus: W3 Total Cache v0.9.4 / WordPress 4.0 / nginx 1.6.2-2~bpo70+1


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

25 oct. 2014 15:45:56
Comentarii

Nu sunt sigur care este cel mai bun mod de a proceda în privința recompensei. Aveți sugestii?

avggeek avggeek
25 oct. 2014 15:49:48

Pur și simplu acceptă răspunsul tău ca fiind răspunsul corect. Vezi "Pot să acord o recompensă propriului meu răspuns?" http://meta.stackexchange.com/questions/16065/how-does-the-bounty-system-work

iyrin iyrin
28 oct. 2014 02:09:47

Poți rezolva asta fără să modifici fișierul de configurare w3 prin simpla ajustare a regulii tale de location / rewrite la try_files $uri $uri/ /index.php$is_args$args;. Referință: http://wordpress.stackexchange.com/questions/98271/enable-minify-in-w3total-cache-using-nginx

THpubs THpubs
15 iun. 2016 15:59:44