Qué significa un error 500 de servidor interno y de quién es la culpa

Un error 500 de servidor interno es el servidor que ejecuta el sitio admitiendo que algo salió mal en su propio código, y que no puede mostrarte la página por ello. No es “la página no existe”, no es “no tienes permiso”, no es “vuelve más tarde” - solo un honesto e inútil “algo se rompió aquí adentro, y no fue tu culpa”.

La palabra que debes notar es interno. El servidor está hablando de sí mismo, no de una red, un permiso o algo que hiciste. Ejecutó tu solicitud, se encontró con un error que no sabía cómo manejar, y lo único veraz que le quedaba por decir era 500. Es por eso que el mensaje es tan vago: el servidor no está ocultando el detalle para ser difícil, se niega a filtrar sus propias entrañas a un extraño.

Por qué no te dice nada

Un 500 es el error más genérico en la web a propósito. Cuando una aplicación falla de manera que no anticipó - una excepción que nadie atrapó, una consulta que explotó, un nulo donde se esperaba un objeto - lo seguro es mostrar al mundo externo un muro en blanco. Los detalles de qué se rompió, la traza de pila, el número de línea, la consulta que falló, todo se queda en el servidor, en un registro, donde solo los que ejecutan el sitio pueden leerlo.

Entonces el 500 que ves y la razón de ello viven en dos lugares diferentes. El navegador tiene el código; el servidor tiene la causa. Esa brecha es la dificultad completa de un 500, y es por eso que “obtuve un 500” es un reporte que casi no le dice nada a un desarrollador por sí solo.

500 contra 502 y 504, que se ven igual desde afuera

Los tres son la familia del servidor de “algo salió mal de nuestro lado”, y distinguirlos entre sí señala causas muy diferentes.

500 Internal Server Error

La aplicación se ejecutó y su propio código falló - una excepción no manejada, un colapso dentro de la solicitud. El servidor respondió; la respuesta fue un error que él mismo cometió

502 Bad Gateway

Un servidor frontal obtuvo una respuesta inutilizable de la aplicación detrás de él - colapsó, rechazó, malformada. El fallo está entre dos servidores

504 Gateway Timeout

La aplicación no respondió a tiempo en absoluto. El servidor frontal dejó de esperar

Aproximadamente: un 500 es la aplicación fallando mientras se ejecuta, un 502 es un proxy fallando en obtener una respuesta buena de ella, y un 504 es la aplicación siendo demasiado lenta para responder. Si obtuviste un 500, el código se ejecutó y se rompió; si obtuviste un 502 o 504, a menudo nunca terminó de ejecutarse. Esa distinción es la primera cosa que vale la pena saber, porque decide si buscas en los registros de la aplicación o en la infraestructura delante de ellos.

Si eres un visitante

Recarga una vez, porque una cantidad considerable de 500s son un mal momento único - una solicitud que se encontró con una condición de carrera, una consulta que agotó el tiempo de espera bajo una ráfaga - y el siguiente intento cae en algún lugar saludable. Si se aclara, no hay nada que perseguir.

Si persiste, la culpa está del lado del sitio, y genuinamente no hay nada en tu navegador que alcance un error en su código. Limpiar tu caché, intentar incógnito, cambiar navegadores - nada de eso toca el servidor, y cada uno es un período común de media hora gastado tratando un 500 como si fuera un problema que podrías arreglar desde tu asiento. La única cosa útil que puedes hacer es decirles, con suficiente detalle para que puedan encontrar la línea coincidente en su registro: qué estabas haciendo y aproximadamente cuándo.

Si es tu sitio

Un 500 significa que tu código lanzó algo que no manejó, así que la pregunta es solo qué, y la respuesta está en tus registros en lugar de en la respuesta que vio el usuario. Algunas pocas causas explican la mayoría de ellos.

Una excepción no manejada en la solicitud. La más común por mucho. Un método llamado en un nulo, una clave que no estaba allí, un tipo que no era lo que el código asumía. La solicitud llegó a tu código, tu código lanzó, y nada la atrapó. Tu registro de aplicación tiene la traza de pila; el 500 del usuario no.

Una llamada de base de datos fallida. Una consulta contra una columna que fue renombrada, un grupo de conexión agotado bajo carga, una migración que se ejecutó en un servidor y no en otro. Estos a menudo llegan en ráfagas, porque rastrean carga o un despliegue en lugar de una única entrada.

Un problema de configuración o entorno. Una variable de entorno faltante, un secreto que no fue establecido, un servicio que la aplicación espera alcanzar y no puede. Estos son los que convierten cada solicitud en un 500 a la vez, generalmente justo después de un despliegue o un cambio de infraestructura, y se ven alarmantes precisamente porque nada en el código cambió - el terreno debajo sí.

Un despliegue defectuoso. Código nuevo que lanza en una ruta que las pruebas no cubrieron, o se inicia contra un esquema que no existe aún. Si los 500s comenzaron en un lanzamiento, ese es el primer lugar a buscar, y una reversión es más rápida que un diagnóstico.

Por qué un 500 es tan difícil de perseguir después del hecho

El error que vio el usuario no lleva nada de la causa, así que un 500 reportado una hora después, de memoria, es prácticamente inútil: tienes un código genérico y un tiempo aproximado, y estás buscando en un registro una aguja que solo puedes describir como “alrededor de las tres en punto”. La traza de pila que hubiera nombrado el error está en una línea de registro que nadie capturó contra la solicitud que la produjo.

Lo que cierra un 500 rápidamente es la solicitud que lo causó, su tiempo exacto, y qué estaba haciendo la persona - capturado mientras sucedía, para que puedas hacerlo coincidir con la única línea de registro que tiene el error real en ella. Esa es la diferencia entre un error que encuentras en un minuto y un registro que desplazas durante toda una tarde.

El registro de red contiene la solicitud fallida con su 500 y el momento exacto en que sucedió, así que quien recoja el reporte puede alinearlo contra el registro del servidor y leer el error real - en lugar de necesitar reproducir todo primero para descubrir qué estaba ocultando ese código genérico.

En un párrafo

Un error 500 de servidor interno significa que la aplicación ejecutó tu solicitud y su propio código falló de manera que no manejó, así que mostró la única respuesta segura y genérica que tenía - lo que es lo que lo hace diferente de un 502, donde un proxy no pudo obtener una respuesta buena de la aplicación, y un 504, donde la aplicación fue demasiado lenta para responder en absoluto. Si estás visitando, recarga una vez y luego asume que es de su lado. Si es tuyo, la causa está en tus registros, no en la respuesta: sospecha una excepción no manejada, una consulta fallida, una configuración faltante, o el último despliegue - y captura la solicitud fallida mientras la tengas, porque un 500 no te dice nada por sí solo.