Flujo para analizar caídas
Cómo comprobar si un sitio web está caído
Sigue un flujo claro para distinguir entre una caída real del sitio, un problema DNS, un fallo SSL, un puerto cerrado o una respuesta que técnicamente existe, pero sigue estando rota.
Cuando un sitio deja de cargar, la primera pregunta suele ser demasiado amplia, “¿está caído?”. En la práctica, primero hay que responder algo más preciso. ¿La solicitud falló antes de terminar DNS, durante la conexión, durante TLS o solo después de que el servidor devolviera una respuesta HTTP? Esa diferencia separa un diagnóstico útil de una simple suposición de uptime.
Empieza por toda la ruta de la solicitud
Una comprobación web da la respuesta general más rápida porque toca DNS, TCP, TLS, redirecciones y la respuesta HTTP final en una sola ejecución.
No trates cualquier fallo como una caída
Un 403, 429 o 503 sigue significando que el servidor respondió. No es lo mismo que un fallo DNS, una conexión rechazada o un error en la negociación TLS.
Usa herramientas de seguimiento para acotar la capa
DNS, SSL, puertos, ping y traceroute importan después de que la primera comprobación te muestre dónde empezó a romperse la ruta de la solicitud.
01
Cuándo conviene usar esta guía
Este flujo está pensado para los primeros minutos de revisión, antes de tocar registros o culpar al hosting sin pruebas.
El sitio no carga para ti
Necesitas saber si el fallo también es visible desde un servidor público o si puede estar limitado a tu navegador, red de oficina, VPN o proveedor.
Un cliente dice que el sitio está caído
Buscas una respuesta rápida y defendible antes de escalar. Un informe que separe HTTP, DNS, SSL y errores de red aporta más que un simple sí o no.
Tu monitoreo ya marcó un problema
Necesitas una segunda referencia desde una página pública de diagnóstico para entender si parece un fallo de aplicación, de ruta o de confianza HTTPS.
02
Un flujo práctico para la primera revisión
El objetivo es pasar de un síntoma amplio a una capa más concreta sin saltar demasiado pronto a herramientas de bajo nivel.
Ejecuta el Comprobador web sobre la URL exacta que falla
Usa el host y el esquema reales siempre que puedas. Te interesan la cadena de redirecciones, la URL final, el desglose de tiempos y el resultado HTTP visible en una sola comprobación.
Lee el punto de fallo, no solo el titular
Un error DNS, una advertencia TLS, un tiempo de espera agotado y un HTTP 503 pueden sentirse como “el sitio está caído”, pero apuntan a responsables y siguientes pasos distintos.
Confirma la capa concreta con la herramienta adecuada
Si el primer resultado apunta a certificados, abre el Comprobador SSL. Si apunta a resolución de nombres, abre Consulta DNS. Si la conexión ni siquiera se abre, usa Comprobador de puertos y luego Ping o Traceroute si sospechas de la ruta.
Decide si el resultado demuestra un problema global
Un único servidor público puede demostrar que una ubicación vio el fallo. No puede demostrar que todas las regiones, proveedores o navegadores vieran lo mismo.
03
Qué suelen significar los resultados más comunes
Estas son las interpretaciones que más importan cuando alguien pregunta si un sitio está realmente inaccesible.
Hay una respuesta HTTP con código de estado
La solicitud llegó a una aplicación o a un servicio de borde. El sitio puede seguir siendo inutilizable, pero el host resolvió y algo respondió por HTTP.
Fallo DNS o ausencia de registros útiles
El problema empezó antes de que cualquier servidor web pudiera responder. Revisa A, AAAA, CNAME, NS y el comportamiento del resolutor antes de tocar SSL o código de aplicación.
Error TLS o de certificado
El host era lo bastante accesible como para iniciar HTTPS, pero falló la confianza o la negociación del protocolo. Los usuarios pueden ver un bloqueo de seguridad aunque el servidor siga técnicamente en línea.
Conexión cerrada, rechazada o agotada por tiempo
El servicio web no aceptó una conexión funcional desde la ubicación de prueba activa. Eso suele apuntar a firewall, proceso caído, problema en el origen o filtrado aguas arriba.
04
Qué herramienta abrir a continuación
Usa la página dedicada que mejor encaje con la primera señal clara en lugar de adivinar a partir de un mensaje ambiguo.
Es la mejor primera comprobación para “el sitio no carga” porque enseña toda la ruta de la solicitud y dónde falló primero.
Comprobador webRespuestas DNS analizadasÁbrela cuando los nombres no cuadrenÚsala tras un NXDOMAIN, respuestas vacías, IP antiguas o un desajuste entre el host y la infraestructura que esperabas ver.
Consulta DNSInspección de certificados y TLSÚsala cuando HTTPS sea el bloqueo principalEs la mejor opción para certificados caducados, falta de coincidencia del host, certificados autofirmados y soporte visible de versiones TLS.
Comprobador SSLConectividad TCPÚsala cuando el servicio quizá no esté escuchandoUna prueba limpia del puerto ayuda a separar errores de la aplicación web de una conexión que nunca llegó a establecerse en 80 o 443.
Comprobador de puertos05
Errores que hacen perder tiempo
Estos atajos ralentizan el análisis porque mezclan capas distintas dentro de una conclusión demasiado vaga.
- Tratar cualquier respuesta distinta de 200 como prueba de que todo el sitio está caído.
- Probar solo la página de inicio cuando el fallo real ocurre en un login redirigido, en el checkout o en una ruta API.
- Ir directamente a traceroute antes de confirmar si el sitio responde por HTTP o escucha en el puerto esperado.
- Asumir que uno o dos fallos del lado del servidor demuestran que el problema es global para todas las regiones y navegadores.