500 Internal Server Error: qué significa y cómo solucionarlo

Publicado:

15 min de lectura

Acar Diveroli
Autor: Acar Diveroli
Servidor isométrico con rejillas y tornillos, placa de estado HTTP 500 y una luz roja de fallo; encima flota una placa azul

Pulsas el botón para pagar un pedido y, en lugar de la página siguiente, aparece una pantalla casi en blanco: «500 Internal Server Error» en negrita, con «nginx» debajo. En otro sitio, Chrome dibuja su propia página, «Esta página no funciona», con «HTTP ERROR 500» al pie. Dentro de una app las palabras cambian, por ejemplo «The call failed on the server; see server log for details», pero el número es el mismo.

A continuación: qué significa el código y por qué dice tan poco, quién produjo la página que ves, en qué se diferencia un 500 de un 502, un 503 y un 504, y qué deberían hacer los visitantes, los propietarios de sitios y los scripts.

¿Qué significa 500 Internal Server Error?

El estándar HTTP define el código en una frase: el servidor «encontró una condición inesperada que le impidió atender la petición» (RFC 9110, sección 15.6.1). Todo código que empieza por 5 es un error de servidor, es decir, el servidor sabe que la culpa es suya; el 500 es el que usa cuando no encaja ningún código más concreto.

Por eso el mensaje dice tan poco. El servidor web, el programa que acepta las conexiones, como nginx o Apache, pasó tu petición a la aplicación que construye las páginas, y en algún punto de ese trabajo la aplicación falló. El servidor web solo sabe que no volvió ninguna página utilizable, así que responde 500; el detalle fue a parar a un registro de errores (error log) que solo puede leer el operador del sitio.

¿Quién envió la página que estás viendo?

El aspecto de la página de error te dice qué programa se rindió y cuánto del sitio sigue funcionando.

Lo que vesQuién lo envíaQué te dice
El diseño propio del sitio, una disculpa, a veces un ID de peticiónLa aplicaciónFunciona y capturó su propio error; el ID apunta a la entrada del registro
Una página blanca, «500 Internal Server Error», con «nginx» o «Apache» debajoEl servidor webLa aplicación se cayó o no envió nada utilizable
«Esta página no funciona», «La página example.com no puede procesar esta solicitud ahora.», «HTTP ERROR 500»ChromeEl 500 llegó con el cuerpo vacío; el navegador dibujó su propia página

Comprobamos la última fila con un pequeño servidor de prueba en nuestro propio equipo que responde a cada petición con el estado 500 y sin página, abierto en Chromium 145: exactamente esa estructura, con el nombre de nuestro host en la línea central y un botón Volver a cargar. Los textos en español del título, de la línea del host y del botón están en el archivo de traducción de Chromium (components_strings_es.xtb); «HTTP ERROR 500» lo añade el código y nunca se traduce.

¿Cómo se produce un 500, paso a paso?

  1. Tu navegador envía la petición con la dirección, tus cookies y los datos de cualquier formulario.
  2. El servidor web se la pasa a la aplicación que construye las páginas al vuelo; los archivos estáticos los sirve él mismo.
  3. La aplicación falla a medio camino: un error sin capturar, una base de datos que no responde, una línea de configuración mal escrita, un script que supera su límite de memoria.
  4. Algo responde 500: la página propia de la aplicación si capturó el error, la página genérica del servidor web o una respuesta vacía si se cayó.
  5. Tu navegador muestra lo que recibió, o su propia pantalla «Esta página no funciona» si el cuerpo venía vacío.

¿Qué diferencia hay entre 500, 502, 503 y 504?

Los cuatro son errores de servidor, pero señalan partes distintas que fallan. Un 500 dice que falló la propia aplicación; 502, 503 y 504 describen una puerta de enlace (gateway), el servidor que está delante de la aplicación (un reverse proxy, un balanceador de carga o una CDN) y que reenvía las peticiones de los visitantes.

CódigoQué parte fallóCausa típicaQué puede hacer un visitante
500La aplicaciónError en el código, configuración incorrecta, sin memoria, base de datos caídaRecargar una vez y después avisar
502La puerta de enlace recibió una respuesta no válida, o ningunaAplicación detenida o caídaEsperar un minuto y recargar
503El servidor no puede atender ahora mismoSobrecarga, mantenimientoEsperar, mirar la página de estado
504La puerta de enlace esperó demasiadoAplicación lenta, petición largaProbar más tarde una página más ligera

La misma caída puede aparecer con cualquiera de los dos códigos: si la aplicación muere antes de responder y nginx está delante, nginx informa de un 502; si la aplicación captura el error y responde ella misma, ves un 500. Error 502 Bad Gateway: qué significa y cómo solucionarlo cubre el lado de la puerta de enlace.

¿Un error 500 es culpa tuya?

Casi nunca, y nunca por tu conexión: la petición llegó. Aun así, tu petición puede ser el detonante, como un valor de formulario que el código no esperaba o una subida muy grande; el fallo es del sitio, pero solo salta contigo hasta que el sitio lo corrige. Una cookie o una sesión de inicio caducadas también pueden confundir a una aplicación, y por eso borrar las cookies del sitio a veces quita un 500 que recargar no quita.

Un proxy o una VPN tampoco causan un 500: el error se produce después de que la petición llegue al sitio, así que una dirección IP distinta no lo hará desaparecer.

¿Qué puedes hacer como visitante?

  1. Recarga una vez y después espera unos minutos. Pulsa F5 o el botón Volver a cargar de la página de error de Chrome; a partir de ahí solo añades carga a un servidor que ya va justo.
  2. Prueba otra página del mismo sitio. Si la portada carga pero el pago falla, el sitio está en pie y una función está rota.
  3. Prueba el sitio en tu teléfono con datos móviles. Si también falla ahí, el fallo es general y nada en tu equipo lo cambiará. Cambiar de salida con un proxy o una VPN es la misma prueba; con los Proxies residenciales puedes repetirla desde otro país en un minuto.
  4. Mira la página de estado del sitio. Los servicios grandes anuncian ahí las caídas; una app que sigue mostrando un 500 está chocando con la misma caída a través de su API.
  5. Borra las cookies del sitio, pero solo cuando el error sobreviva a la espera y te siga de página en página. En Chrome, en un equipo: Más > Eliminar datos de navegación, elige un periodo, marca Cookies y otros datos de sitios y pulsa Eliminar datos (los pasos de Google). Cierra tu sesión en los sitios, así que déjalo para el final.
  6. Avisa del error con la dirección exacta, la hora, lo que pulsaste y cualquier ID de petición impreso en la página.

Reiniciar el router, cambiar de servidores DNS o reinstalar el navegador no sirven de nada aquí: actúan sobre la parte del trayecto que ya funcionó.

Si el sitio es tuyo: ¿cómo encuentras la causa?

Un 500 es deliberadamente vago para los visitantes, pero nunca lo es en el registro. Sigue estos pasos en orden; la mayoría de los 500 terminan en los tres primeros.

  1. Lee primero el registro de errores. Apache llama a su registro de errores el primer sitio donde mirar cuando surge un problema; la directiva ErrorLog fija su ubicación, normalmente un archivo llamado error_log en Unix (documentación de registros de Apache). nginx escribe en logs/error.log por defecto, y PHP en su propio archivo error_log o en el registro del servidor web. Busca el minuto del 500: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted es un problema de memoria, el Premature end of script headers de Apache es un script que murió antes de enviar una página, y una traza de pila (stack trace) nombra el archivo y la línea.
  2. Deshaz el último cambio. Un 500 que empieza justo después de una actualización, un despliegue o una edición de la configuración es ese cambio hasta que se demuestre lo contrario; revierte primero.
  3. Plugins y temas. La guía de WordPress sobre el Internal Server Error indica desactivar todos los plugins y cambiar a un tema por defecto (Errores comunes de WordPress); si el sitio vuelve, reactívalos de uno en uno.
  4. El archivo .htaccess. En Apache, este archivo de configuración por carpeta se lee en cada petición, así que una sola línea mala rompe todas las páginas. La guía de WordPress señala un .htaccess corrupto como la causa más probable: renómbralo a .htaccess_old y, si el sitio carga, vuelve a generarlo desde Ajustes > Enlaces permanentes. Una directiva que AllowOverride no permite, o un error de sintaxis, produce un error de servidor con el motivo en el registro.
  5. Límites de PHP. PHP detiene un script que reserva más de memory_limit (128M por defecto) y termina uno que se ejecuta más de max_execution_time (30 segundos por defecto en un servidor web). Sube el límite en php.ini o en los ajustes de PHP del alojamiento, pero trata una necesidad que crece sin parar como un bug.
  6. Permisos y dependencias. El servidor web se ejecuta con su propio usuario: un script que no puede leer o una carpeta en la que no puede escribir termina en un 500 en lugar de en un mensaje claro. Lo mismo ocurre con una base de datos caída, una clave de API o un certificado caducados, o un disco lleno; eso está en el propio registro de la aplicación.
  7. Tu panel de hosting. En un alojamiento compartido, el panel muestra el registro: en cPanel, la interfaz Errors (Errores) dentro de Metrics (Métricas) lista hasta 300 de las entradas más recientes. Si apuntan al propio servidor, o si fallan todos los sitios del servidor, abre un ticket con el proveedor con la hora, la URL y las líneas del registro.

Los rastreadores de Google van más despacio ante errores 5xx y acaban retirando las URL que siguen fallando, así que un 500 que se alarga cuesta posiciones. Una herramienta de supervisión que descargue unas cuantas páginas clave cada minuto te avisa antes que nadie; las comprobaciones hechas desde un par de direcciones fijas y dedicadas de los Proxies de centro de datos se pueden autorizar en el servidor y dejar fuera de tus estadísticas de errores.

¿Cómo debería manejar un 500 un script o un scraper?

Trata un 500 como temporal, pero no como gratuito: reintenta unas pocas veces con pausas cada vez mayores y después abandona esa dirección.

  • Limita los reintentos y alarga la pausa. Un segundo, luego dos, luego cuatro, y para después de tres o cuatro intentos; un bucle que martillea la misma dirección empeora la caída.
  • Un 500 bajo carga significa ir más despacio. Si el sitio empieza a devolver 500 mientras tu crawler trabaja con alta concurrencia, reduce el número de peticiones en paralelo. Nunca cambies de dirección IP para forzar el paso: la aplicación falla para todo el mundo.
  • Registra el cuerpo de la respuesta. Un error en JSON, un ID de petición o una traza de pila dice si el fallo es tuyo (un parámetro incorrecto) o suyo, y distingue un 500 real de un bloqueo: un 403 o un 429 con una página de verificación es una decisión sobre tu tráfico, no un fallo del servidor. 429 Too Many Requests: qué es el error de rate limit cubre esos casos.

El ejemplo siguiente aplica las reglas con la biblioteca Requests de Python. Lo ejecutamos contra nuestro servidor de prueba local, cuya página /flaky devuelve 500 dos veces y luego 200, y cuya página /text devuelve siempre 500 (Python 3.13, Requests 2.34):

python
import time

import requests

URL = "http://127.0.0.1:18500/flaky"  # nuestro servidor de prueba local; pon aquí la página que necesitas
PROXIES = None  # o {"http": "http://user:pass@pr.proxynet.io:8000", "https": "http://user:pass@pr.proxynet.io:8000"}
ATTEMPTS = 4  # un tope: un 500 que persiste es problema del sitio, no tuyo


def fetch(url):
    wait = 1.0
    for attempt in range(1, ATTEMPTS + 1):
        r = requests.get(url, proxies=PROXIES, timeout=20)
        if r.status_code in (403, 429):
            raise RuntimeError(f"{url}: HTTP {r.status_code} is a block or a rate limit, not a server error")
        if r.status_code < 500:
            return r
        print(f"attempt {attempt}: HTTP {r.status_code} {r.reason}, body: {r.text.strip()[:60]!r}")
        if attempt < ATTEMPTS:
            time.sleep(wait)
            wait *= 2  # 1 s, 2 s, 4 s
    raise RuntimeError(f"{url}: HTTP 500 after {ATTEMPTS} attempts, skip it and come back later")


r = fetch(URL)
print(f"HTTP {r.status_code}: {r.text.strip()}")

Salida para /flaky:

text
attempt 1: HTTP 500 Internal Server Error, body: '{"error":"database connection lost"}'
attempt 2: HTTP 500 Internal Server Error, body: '{"error":"database connection lost"}'
HTTP 200: ok

Para /text se imprimen cuatro intentos y el script termina con:

text
RuntimeError: http://127.0.0.1:18500/text: HTTP 500 after 4 attempts, skip it and come back later

A través de un proxy, rellena PROXIES con la dirección del Endpoint Generator; la lógica no cambia, porque el 500 viene del destino. Qué códigos reintentar y en cuáles parar, del 403 al 504, está en Códigos de estado HTTP en web scraping: 403, 407, 429, 503.

Dónde puedes encontrarte un 500

  • Un «500 Internal Server Error» a secas con «nginx» debajo en un sitio pequeño, a menudo justo después de actualizar su CMS o PHP.
  • Dentro de una app como Discord o la de un banco, cuyas pantallas llaman a la API del propio servicio y muestran el número que devolvió.
  • El mensaje «The call failed on the server; see server log for details» en una aplicación web Java: el texto fijo que el framework GWT envía con un 500 cuando falla una llamada al servidor.

Errores habituales

  • Recargar cada segundo. La aplicación ya está fallando; más peticiones la frenan aún más y ocultan el momento en que se recupera.
  • Propietarios: subir memory_limit sin leer el registro. Un límite más alto esconde una fuga de memoria durante una semana, y luego el 500 vuelve.
  • Propietarios: mostrar la traza de pila a los visitantes. Un modo de depuración que se queda activado en producción imprime rutas de archivos y detalles de la base de datos en la página de error.
  • Scrapers: rotar IP ante un 500. El sitio falla para todas las direcciones; reintenta con pausas o salta la página.

Guía de decisión

Tu situaciónQué hacer
Una página muestra un 500, el resto del sitio funcionaRecarga una vez, inténtalo de nuevo en unos minutos, avisa de la página
Todo el sitio falla también en tu teléfonoEl sitio está caído; espera o mira su página de estado
Tu sitio, justo después de una actualización o un despliegueRevierte y después lee el registro de errores
Tu sitio, el registro dice «Allowed memory size»Sube memory_limit una vez y después arregla el código que lo necesita
Tu script recibe 500 de un sitioReintenta 3-4 veces con pausas crecientes, luego salta y baja la concurrencia

Preguntas frecuentes

¿Un error 500 internal server error es culpa mía?

No. El código significa que el propio software del sitio falló al procesar tu petición; tu conexión y tu navegador hicieron su parte. Lo que escribiste puede disparar un bug que ya existía, pero arreglarlo sigue siendo tarea del sitio.

¿Cuánto dura un error 500?

No hay un tiempo fijo. Un reinicio o un corte breve de la base de datos se resuelven en segundos; una actualización rota o un archivo .htaccess dañado duran hasta que el propietario lo nota y lo arregla.

¿Qué significa «500 Internal Server Error nginx»?

nginx es el programa servidor web que está delante del sitio, y la página es su página de error genérica: la aplicación detrás de nginx falló y nginx no tenía ninguna respuesta correcta que pasar.

¿Qué significa «The call failed on the server; see server log for details»?

Es el texto fijo que el framework GWT, usado por algunas aplicaciones web Java, envía con el estado 500 cuando una petición al servidor lanza un error. El registro al que se refiere solo pueden leerlo los operadores del sitio; para ti es un 500 corriente.

¿Por qué Discord u otra app muestra un error 500?

Las apps obtienen sus datos a través de la API del servicio, y cuando esta responde 500 la app muestra el número. La caída está en el lado del servicio; mira su página de estado e inténtalo más tarde.

¿Borrar las cookies arregla un error 500?

A veces, cuando la aplicación se atraganta con una cookie o una sesión caducadas. Pruébalo solo después de recargar y esperar; la mayoría de los 500 están en el servidor, y borrar datos no hace nada por ellos.

En resumen

Un 500 Internal Server Error significa que la aplicación del sitio encontró un problema que no pudo manejar, y el servidor envió un error genérico en lugar de la página. Los visitantes recargan una vez, esperan y prueban desde otro dispositivo; los propietarios leen el registro de errores y repasan hacia atrás el último cambio, los plugins, el .htaccess, los límites de PHP y los permisos; los scripts reintentan con pausas crecientes y nunca fuerzan el paso con direcciones nuevas. Los tipos de proxy se comparan en nuestra página de proxies.