Cuando una web está caída, lo primero es confirmar que no funciona para nadie y no solo para ti. Después, trabaja de fuera hacia dentro: el DNS, la conexión, el certificado TLS, la CDN o el proxy, el servidor web y, por último, la aplicación y sus dependencias. El error que ves suele indicarte por qué capa empezar, y cada paso de abajo tiene una prueba rápida que la confirma o la descarta.
Toma notas sobre la marcha: qué has comprobado, a qué hora y qué has visto. Así es más rápido pasar el arreglo a otra persona y más fácil escribir el postmortem.
Paso 1: ¿Está caída para todos o solo para ti?
Pega la dirección en el comprobador Is it down?. Solicita la página desde Estocolmo (Suecia), sigue hasta cinco redirecciones y considera activa cualquier respuesta por debajo de HTTP 500. Después prueba el sitio en el móvil con el wifi desactivado.
Si funciona desde fuera pero no para ti, el problema está cerca de ti: una VPN, una entrada en el archivo hosts, la caché DNS de tu router, una extensión del navegador o un firewall que ha bloqueado tu dirección IP tras demasiados inicios de sesión fallidos. Prueba con una ventana privada y otra red antes de tocar el servidor.
Lee el mensaje de error
El error exacto señala la capa que ha fallado. Apúntalo antes de empezar a cambiar cosas.
Lo que vesCapa probableEmpieza porDNS_PROBE_FINISHED_NXDOMAIN, “no se ha podido encontrar la dirección IP del servidor”DNS o dominioPaso 2ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUTRed o servidorPaso 3“La conexión no es privada”, NET::ERR_CERT_DATE_INVALIDCertificado TLSPaso 4Cloudflare 521, 522, 525 o 526, o una página de error de la CDNDe la CDN al origenPaso 5500, 502, 503 o 504Servidor web o aplicaciónPaso 6Una página que carga pero está en blanco o muestra un errorAplicación o dependenciaPaso 7
Paso 2: Comprueba el DNS y el dominio
Si el nombre no se resuelve, lo demás da igual. Pregunta al DNS qué responde para tu dominio y compáralo con la dirección de tu servidor:
dig +short example.com A
dig +short www.example.com
dig +short example.com NS
Ninguna respuesta: comprueba si el registro del dominio ha caducado con el comprobador de caducidad de dominios. Un dominio caducado suele perder sus servidores de nombres o apuntar a la página de aparcamiento del registrador.
Una dirección equivocada: alguien ha cambiado un registro, o los servidores de nombres se han movido a un proveedor que no tiene tus registros. Compara la respuesta con la que esperas usando la herramienta de consulta DNS.
Bien para unos, mal para otros: un cambio reciente todavía se está extendiendo. Los resolvers guardan la respuesta antigua hasta que vence su TTL; es la propagación DNS.
Nuestra guía sobre DNS_PROBE_FINISHED_NXDOMAIN repasa las causas de DNS una por una.
Paso 3: ¿Puedes llegar al servidor?
Con la dirección correcta, prueba si el servidor acepta conexiones en los puertos web:
nc -vz example.com 443
curl -sv -o /dev/null https://example.com/
Conexión rechazada: la máquina responde, pero nada escucha en el puerto. El servidor web se ha detenido o ha fallado. Arráncalo y lee su log para saber por qué.
Tiempo de espera agotado: los paquetes no llegan a ninguna parte. El servidor está apagado, un firewall o un grupo de seguridad descarta el tráfico, o la red intermedia tiene una avería. Mira la página de estado y la consola de tu proveedor de hosting.
No te fíes solo de ping. Muchos hosts bloquean ICMP, así que un servidor puede no responder al ping y servir la web sin problemas, o responder al ping con el servidor web caído.
Paso 4: Comprueba el certificado TLS
Un problema de certificado tumba el sitio para todos a la vez, con un aviso del navegador a pantalla completa, aunque el servidor esté bien. Pasa el host por el comprobador SSL, o míralo desde la línea de comandos:
openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject
Las causas habituales son un certificado caducado tras fallar la renovación automática, un certificado emitido para otro nombre o un certificado intermedio que falta. Errores de certificado SSL explicados relaciona cada aviso del navegador con su solución.
Paso 5: Descarta la CDN o el proxy
Si hay una CDN o un proxy inverso delante del sitio, la página de error puede venir del proxy y no de tu servidor. Los códigos 52x de Cloudflare dicen exactamente dónde se ha roto:
521: el servidor de origen ha rechazado la conexión.
522: se ha agotado el tiempo de conexión con el origen.
525: ha fallado el handshake TLS con el origen.
526: el certificado del origen no es válido.
Para probar el origen sin la CDN, envía la petición directamente a su dirección IP manteniendo el nombre de host. Sustituye 203.0.113.10 por la dirección de tu origen:
curl -sv -o /dev/null –resolve example.com:443:203.0.113.10 https://example.com/
Si el origen responde bien, revisa la CDN: su página de estado, las reglas de firewall que hayas cambiado hace poco y si sigue teniendo la dirección correcta del origen. Si el origen también falla, pasa al servidor.
Paso 6: Comprueba el servidor web y la aplicación
Un código de estado 5xx significa que la petición llegó a tu stack y algo falló allí. El código acota el problema:
500: la aplicación ha lanzado un error. Consulta 500 Internal Server Error.
502: el servidor web no ha recibido una respuesta válida del proceso de la aplicación que tiene detrás, a menudo porque ese proceso ha fallado. Consulta 502 Bad Gateway.
503: el servicio está sobrecargado o en modo mantenimiento. Consulta 503 Service Unavailable.
504: la aplicación ha tardado demasiado en responder. Consulta 504 Gateway Timeout.
Cada código tiene su propia página en la referencia de códigos de estado HTTP. En el servidor, tres comprobaciones encuentran la mayoría de las causas:
df -h # un disco lleno detiene bases de datos, logs y subidas
free -m # la falta de memoria mata procesos
tail -n 50 /var/log/nginx/error.log # o los logs de tu servidor web y de la aplicación
Después pregúntate qué ha cambiado. Un despliegue, una actualización de un plugin, un cambio de configuración o una API key caducada en la última hora es la causa más probable, y revertirlo suele ser más rápido que depurarlo en directo.
Paso 7: Comprueba las dependencias
Tu sitio puede estar sano mientras algo que necesita no lo está. Una base de datos sin conexiones libres, un servidor de caché que se ha detenido o una caída de un proveedor de pagos, de email o de inicio de sesión rompen páginas que por lo demás cargan. Revisa las páginas de estado de tus proveedores y busca los grandes en Is it down?, que sigue servicios conocidos y sus caídas recientes.
Cuando el sitio está activo pero roto
Algunos fallos responden 200: una lista de productos vacía, un botón de pago que no hace nada, un mensaje de error dentro de una página normal. Un código de estado no los detecta. Comprueba que la página contiene lo que debe y recorre el proceso que importa, como iniciar sesión o pagar, igual que lo haría un cliente.
Mientras lo arreglas: avisa a la gente
Publica una actualización breve en cuanto sepas que hay un problema, aunque solo puedas decir que lo estás investigando, y comprométete a una hora para la siguiente. El generador de actualizaciones de estado redacta una para cada fase, y el plan de comunicación de incidencias explica quién dice qué y dónde.
Haz que la próxima caída dure menos
La parte más lenta de la mayoría de las caídas es enterarse de ellas. Con monitorización externa, te enteras del problema por una alerta y no por un cliente, y empiezas con pruebas en lugar de suposiciones. Esto es lo que te da Uptimecheck:
Comprobaciones cada minuto desde Estocolmo, Londres y Nueva York, con cada fallo confirmado desde una segunda ubicación antes de avisarte. Consulta monitorización de uptime.
Pruebas en la incidencia: la dirección a la que resolvió el DNS, las redirecciones, el certificado, las cabeceras y el inicio de la respuesta, además de una captura de pantalla cuando el servidor respondió o un traceroute cuando no lo hizo. Consulta cómo funcionan las incidencias y las pruebas.
Tiempos de respuesta divididos en fases: DNS, conexión, TLS, servidor y descarga, para que una capa lenta destaque antes de fallar.
Recordatorios antes de la caducidad de certificados y dominios, y alertas cuando cambian los registros DNS.
Comprobaciones de palabras clave y flujos que detectan una página que responde 200 pero está rota. Consulta monitorización de flujos.
Si un monitor dice que el sitio está caído mientras a ti te funciona, por qué un monitor marca caída cuando tu sitio funciona explica cómo interpretar la diferencia.
Entérate antes que tus clientes. Prueba Uptimecheck gratis durante 14 días, sin tarjeta de crédito.