La página principal carga pero todos los enlaces permanentes dan error 404 con nginx y PHP-FPM

19 oct 2014, 10:38:56
Vistas: 18.5K
Votos: 4

He estado intentando resolver un problema extraño con mi configuración de nginx, que parece haber dejado de funcionar poco después de aplicar una actualización de Debian backports.

La página de inicio de mi blog (http://blog.balaji-dutt.name/) funciona bien, pero al hacer clic en cualquier otro enlace permanente (Ejemplo 1, Ejemplo 2) aparece un error 404 de nginx.

Aquí está mi configuración, que ahora es básicamente la configuración estándar del 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;

    ## Tu única referencia de ruta.
    root /var/www/wordpress;
    ## Esto debería estar en tu bloque http y si lo está, no es necesario aquí.
    index index.php;

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

    location / {
            # Esto es genial porque no se toca PHP para contenido estático.
            # incluye la parte "?$args" para que los enlaces permanentes no predeterminados no se rompan al usar cadenas de consulta
            try_files $uri $uri/ /index.php?$args;
    }

    # denegar acceso a archivos .htaccess, si la raíz del documento de Apache
    # coincide con la de nginx
    #
    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;
    }

}

Esto es lo que veo en el registro de errores de nginx cuando intento acceder a un enlace permanente (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/"

Parece que nginx no está leyendo la directiva de ubicación para archivos .php, pero no he podido averiguar por qué ocurre esto. ¡Cualquier sugerencia o ayuda es bienvenida!

Actualización 1 - 20 Oct 2014

Listado de directorios para la ubicación raíz de 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

Cuando intento acceder a la URL (http://blog.balaji-dutt.name/2013/481-nginx-apache-w3-total-cache-a-bad-combination/), esto es lo que aparece en el registro de errores de 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/"

La ruta en el registro de errores es confusa, porque la parte después de /var/www/wordpress/ es en realidad el enlace permanente y no estoy seguro de por qué se está agregando a la solicitud.

Actualización 2 - 25 Oct 2014 [SOLUCIONADO]

Resulta que el archivo de configuración de nginx creado por W3 Total Cache para el almacenamiento en caché mejorado en disco romperá los enlaces permanentes, pero como el archivo solo se lee al recargar nginx, el sitio funcionará hasta que recargues/reinicies nginx. Respuesta detallada y una configuración funcional publicada en esta respuesta.

6
Comentarios

¿Has configurado tus enlaces permanentes para que sean "pretty permalinks"? ¿Has activado el modo de depuración? Solo puedo ver una pantalla blanca cuando visito tu página de inicio, lo que me hace pensar que se trata de la famosa pantalla blanca de la muerte :)

kaiser kaiser
19 oct 2014 17:05:47

@kaiser - Estaba probando varias cosas diferentes y publiqué una configuración de nginx que estaba rota. He actualizado la configuración para mostrar cómo se ve ahora y deberías poder ver la página de inicio así como los errores 404. Aquí tienes una captura de pantalla de mis ajustes de enlaces permanentes: http://imgur.com/25mCkXM

avggeek avggeek
20 oct 2014 04:20:22

Parece que estás usando muchas cosas que no se mencionan aquí, como W3TC (disk:enhanced) con CloudFront CDN, https y http-auth que podrían afectar tu configuración. Supongo que lo que haría sería configurar un blog de prueba básico en un subdominio diferente y ver si la configuración de NginX anterior (que parece normal) funciona, y partir de ahí.

birgire birgire
22 oct 2014 13:05:46

¿Has probado los pasos mencionados en este hilo?

Roman Roman
23 oct 2014 03:37:07

@avggeek así que lo solucionaste. ¿Quieres compartir cómo lo hiciste?

alpipego alpipego
24 oct 2014 01:54:24

@alpipego - Estoy ocupado con el trabajo, así que no puedo publicar una respuesta detallada en este momento, pero lo haré durante el fin de semana. En resumen - W3 Total Cache Page Cache en modo Disk Enhanced crea una "condición de carrera" con los reinicios de nginx. Cambiar al modo Page Cache Basic soluciona el error 404, aunque me quedo sin un Page Cache funcional.

avggeek avggeek
24 oct 2014 05:18:48
Mostrar los 1 comentarios restantes
Todas las respuestas a la pregunta 1
3

Resulta que la configuración de nginx que W3 Total Cache inserta cuando el modo Disk Enhanced está activado romperá los enlaces permanentes, pero solo si reinicias nginx después de que W3 Total Cache inyecte la configuración para el modo Disk Enhanced.

Basado en la sugerencia de birgire, desactivé todos los plugins y verifiqué el sitio, el cual comenzó a funcionar correctamente. Luego activé W3 Total Cache y ¡sorpresa! el sitio continuó funcionando correctamente. Siguió funcionando bien hasta que reinicié nginx, momento en el que se cargó el archivo nginx.conf creado por W3 Total Cache y el sitio se rompió. Lo que causa este comportamiento es la siguiente línea:

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

Cuando se reinicia nginx, la línea anterior se carga y todas las URLs son redirigidas a archivos HTML en caché en wp-content/cache/page_enhanced. Sin embargo, al reiniciar, los archivos HTML son purgados y por lo tanto los enlaces devuelven error 404. La solución que encontré fue primero cambiar los permisos del archivo de configuración de nginx que W3 Total Cache normalmente escribe para que no pudiera ser sobrescrito. Luego cambié la configuración anterior:

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

Esta configuración hace un par de cosas: la línea original de rewrite está envuelta dentro de un bloque location para que, incluso si el archivo HTML no se encuentra, recurra al modelo de renderizado regular de index.php. Además, la línea w3tc_rewrite_test es para eliminar un error en el Dashboard. Estoy haciendo esto en un archivo separado para centralizar mi configuración de W3 TC, por lo que hay dos directivas location \ para mi sitio.

Para más detalle, resulta que la configuración de nginx para el módulo de minify de W3 Total Cache también está rota. Aquí hay una configuración funcional1:

#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

Dado que mucha información sobre WordPress/W3 Total Cache depende de la versión, aquí está la información de versión para la configuración anterior: 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
Comentarios

No estoy seguro de cuál es la mejor manera de proceder con la recompensa. ¿Alguna sugerencia?

avggeek avggeek
25 oct 2014 15:49:48

Simplemente acepta tu respuesta como la solución. Ver "¿Puedo otorgar una recompensa a mi propia respuesta?" http://meta.stackexchange.com/questions/16065/how-does-the-bounty-system-work

iyrin iyrin
28 oct 2014 02:09:47

Puedes solucionar esto sin modificar el archivo de configuración de w3 simplemente ajustando tu regla de ubicación/reescritura a try_files $uri $uri/ /index.php$is_args$args;. Referencia: http://wordpress.stackexchange.com/questions/98271/enable-minify-in-w3total-cache-using-nginx

THpubs THpubs
15 jun 2016 15:59:44