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...
0 comentarios: sobre Depurando errores HTTP 500 en Nginx
Publicar un comentario para Depurando errores HTTP 500 en Nginx