Interpretación del resultado
Cómo interpretar los resultados de una comprobación web
Aprende a leer la salida de una comprobación web en el orden correcto, incluido el estado, la cadena de redirecciones, los tiempos, los encabezados, las IP resueltas, las advertencias y la diferencia entre un problema de aplicación y un fallo de red.
Una comprobación web solo resulta útil si la lees en el orden adecuado. Muchas personas se quedan en el código HTTP o en el tiempo total y pasan por alto la pista más importante, si la ruta falló antes de que el servidor pudiera responder, si las redirecciones cambiaron el destino o si TLS y DNS ya eran inestables antes de que la aplicación respondiera.
Lee de arriba hacia abajo
Empieza por el estado general y la explicación, y después pasa al comportamiento de redirecciones, los tiempos y los detalles de la respuesta.
No todas las advertencias significan lo mismo
Una advertencia puede describir un resultado usable pero arriesgado, mientras que un error suele indicar que la ruta de la solicitud se rompió antes de completar una respuesta normal.
La siguiente herramienta depende de la primera pista
No abras DNS, SSL o comprobaciones de puertos al azar. Usa el bloque que se vea anómalo para decidir qué página abrir después.
01
Cuándo ayuda más esta guía
Úsala cuando ya tienes un resultado delante, pero la página todavía deja sin responder una pregunta importante.
El informe devolvió una advertencia
Las advertencias suelen necesitar interpretación. El destino puede seguir siendo accesible, pero el resultado puede revelar problemas de confianza, redirecciones o rendimiento que merecen seguimiento.
Estás comparando dos ejecuciones
Aquí campos como la URL final, la IP resuelta y las fases de tiempo importan más que la etiqueta superior por sí sola.
Necesitas decidir qué herramienta abrir después
Leer la salida bloque a bloque te ayuda a decidir si el problema pertenece a DNS, SSL, al servicio que escucha o a la propia aplicación.
02
Un orden fiable de lectura
Esta secuencia evita que te aferres demasiado a un número o a un código de estado aislado.
Primero revisa el estado resumido y la explicación
Ahí ves si la solicitud terminó bien, si devolvió una advertencia de aplicación o si se rompió antes en la ruta de red.
Después mira la URL final y la cadena de redirecciones
Una página de inicio correcta puede redirigir a un inicio de sesión roto, a un subdominio regional o a un punto final HTTPS con problemas de certificado.
Lee el desglose de tiempos antes de juzgar el rendimiento
Un tiempo total alto puede venir de DNS, de la conexión TCP, de la negociación TLS o de una respuesta lenta del servidor. Son problemas distintos, con responsables distintos.
Usa encabezados, direcciones resueltas y advertencias como contexto
Te ayudan a entender qué borde respondió, si el sitio cambió de host y si la respuesta dejó pistas extra sobre confianza o plataforma.
03
Qué te está diciendo cada bloque
Leer estas secciones por separado evita que el significado de una quede oculto por otra.
Estado y explicación
Es la respuesta más rápida a “¿qué falló primero?”. Tómalo como titular, no como toda la historia.
Cadena de redirecciones
Muestra si la URL original pasó por varios saltos antes de terminar en un lugar inesperado, más lento o menos fiable.
Tiempos
El tiempo DNS, de conexión, TLS, TTFB y el total indican dónde se acumuló realmente la latencia, en lugar de obligarte a adivinar.
Encabezados de respuesta
Los encabezados pueden explicar caché, plataforma, proxy inverso o comportamiento de mantenimiento. A menudo confirman que la solicitud llegó a un servicio de borde real.
IP resueltas
La dirección elegida importa porque el comportamiento puede variar entre IPv4, IPv6 y distintos bordes de proveedor incluso para el mismo host.
04
Advertencia frente a fallo, la diferencia que de verdad importa
El error de lectura más común es tratar cualquier resultado problemático como el mismo tipo de caída.
Los HTTP 4xx y 5xx siguen siendo respuestas
Normalmente significan que la solicitud llegó a una aplicación, un CDN o una política de borde. El sitio puede estar mal, pero la ruta de red ya no es el principal misterio.
Un fallo TLS ocurre antes de que haya contenido útil
Si se rompe la confianza HTTPS, los usuarios pueden quedar bloqueados antes de que la aplicación tenga la oportunidad de responder con normalidad.
Los errores DNS o de conexión ocurren incluso antes
Eso significa que la solicitud no llegó en absoluto a un servicio web utilizable. La investigación se desplaza del contenido de la página hacia la infraestructura.
05
Qué analizar después según el resultado
Elige la herramienta específica que encaje con el bloque sospechoso en lugar de repetir la misma página una y otra vez.
Ábrelo después de advertencias del certificado, falta de coincidencia del host o problemas con el protocolo TLS para ver el certificado con más detalle.
Comprobador SSLRespuestas DNS analizadasUsa Consulta DNS cuando el host parezca inestableEs el mejor paso siguiente tras errores de resolutor, IP inesperadas, respuestas ausentes o comportamientos distintos entre hostnames.
Consulta DNSConectividad TCPUsa el Comprobador de puertos cuando el servicio quizá no esté escuchandoUn resultado limpio de puerto ayuda a confirmar si 80 o 443 son accesibles antes de culpar a la lógica de la aplicación.
Comprobador de puertosPistas de proveedor y bordeUsa el Comprobador de hosting cuando la respuesta apunte a un borde de plataformaResulta útil cuando los encabezados y los hosts sugieren un CDN, una plataforma gestionada o un cambio de proveedor que explique el comportamiento.
Comprobador de hosting