Este artículo explica cómo obtener mayor detalle de un error 500 en un servidor Nginx, lo que permite depurar (o como decimos en Argentina "debuggear") errores o problemas de configuración en un servidor Web.



Los errores 500 son muy ambiguos y muchas veces el servidor Nginx no da ningún tipo de detalle de qué lo causa. La respuesta HTTP 500 significa "error interno del servidor". Los errores internos pueden ser provocados por infinidad de cosas: un problema en la aplicación o en el contenido del sitio; una configuración incompatible del servidor Web; un problema de librerías o dependencias; error de permisos al intentar conectarse a un upstream; módulos faltantes; etc. Desde la versión 8, el servidor Nginx soporta el modo de debug a un log. Esto permite obtener mayor información sobre el procesamiento del servidor. Simplemente basta con cambiar el nivel a "debug" en la directiva error_log:

error_log /var/log/nginx/error.log debug;

Sin embargo, cuando el error 500 es generado programáticamente desde la aplicación Web, esto no es de gran ayuda. Veamos un ejemplo...

Durante la migración de una aplicación Web (particularmente Nextcloud) me encontré con esta situación. Al acceder al sitio, simplemente retornaba error 500:

El mensaje "Ha ocurrido un error" resulta de gran utilidad. Se observa que la respuesta que recibe el navegador es HTTP 500.

Por otro lado, no se encuentra absolutamente nada en el log de errores:

Sólo se encuentra que la respuesta es 500 en el log de accesos. Es aquí donde viene a mano el "trucazo" de este artículo: simplemente desactivar la página de errores 50x amigable desde la configuración de Nginx.

Esta configuración (típica de la mayoría de los sitios Web en producción) se utiliza para que se presente una página de error amigable al usuario:

        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
            root /usr/local/www/nginx-dist;
        }

Simplemente comentar la directiva error_page:

#        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
            root /usr/local/www/nginx-dist;
        }

Reiniciar el sitio Web y volver a cargar la página en cuestión:

Toda una tarde perdida tratando de encontrar el problema, cuando era tan trivial

Tal como se observa, el error 500 era generado por la propia aplicación. Al ser capturado por Nginx y en su lugar renderizada la página 500 amigable, sin dejar rastros en el log de errores, se perdía toda chance de entender qué estaba sucediendo. Otra solución (para este caso en particular) hubiera sido habilitar el log de Nextcloud. Claro que para ello primero debería haber sospechado que el error provenía desde la aplicación.

En fin, dicen que a los golpes se aprende...

Referencias


Tal vez pueda interesarte


Compartí este artículo