Patrones de fallo
Problemas comunes de disponibilidad web explicados
Entiende las capas más habituales detrás de los incidentes de disponibilidad web, desde errores DNS y fallos de confianza SSL hasta puertos cerrados, aplicaciones sobrecargadas y problemas ligados a la ruta.
La mayoría de los incidentes de disponibilidad dejan de ser misteriosos cuando se clasifican por capa. Lo difícil es que los usuarios los describen con la misma frase, “el sitio está caído”. En un diagnóstico, eso puede significar un registro DNS roto, un listener muerto en 443, un certificado caducado, un origen sobrecargado que devuelve 503 o un problema regional de ruta. Una buena resolución empieza por colocar el síntoma dentro de la familia de fallo correcta.
Fallos distintos se ven iguales para el usuario
Una página de error del navegador, un tiempo de espera agotado sin más contexto y un 503 pueden describirse todos como “caído”, aunque provienen de capas distintas.
Pensar por capas ahorra tiempo
Cuando sabes si el problema está en DNS, conexión, TLS, HTTP o ruta, la siguiente herramienta y el responsable probable se vuelven mucho más claros.
Un informe debería llevarte a una sola acción siguiente
El objetivo del diagnóstico no es reunir todos los datos posibles, sino estrechar el problema lo bastante rápido como para que el siguiente paso sea evidente.
01
Las principales familias de problemas de disponibilidad
Estos grupos cubren la mayoría de los incidentes prácticos que verás en sitios públicos.
Problemas de resolución de nombre
El host no resuelve correctamente, resuelve hacia el lugar equivocado o se comporta de forma inconsistente por datos DNS antiguos o desajustados.
Problemas de conectividad del servicio
El host puede existir, pero el puerto web esperado está cerrado, filtrado, rechazado o agota el tiempo desde una de las ubicaciones de prueba.
Problemas de confianza TLS
El servicio es lo bastante accesible como para iniciar HTTPS, pero el certificado, el host, la cadena o la negociación del protocolo impiden una sesión de confianza.
Problemas a nivel de aplicación
La solicitud llega al sitio, pero el resultado HTTP final muestra un error del servidor, sobrecarga, modo de mantenimiento o una restricción de acceso.
02
Síntoma, capa probable y mejor primera comprobación
Úsala como mapa rápido de diagnóstico inicial cuando el informe de un cliente o de un compañero sea demasiado vago.
| Síntoma | Capa probable | Mejor primera comprobación |
|---|---|---|
| El host no resuelve o resuelve de forma extraña | DNS | Comprobador web, luego Consulta DNS |
| El navegador advierte sobre el certificado o HTTPS | TLS / SSL | Comprobador SSL, luego Comprobador web |
| La conexión a 80/443 se rechaza o agota el tiempo | Puerto o conectividad de red | Comprobador de puertos, luego Ping o Traceroute |
| El sitio responde con 403, 429, 500, 502, 503 o 504 | Aplicación / borde / upstream | Comprobador web, luego Comprobador de hosting o seguimiento SSL/DNS si hace falta |
| Solo se quejan algunos usuarios o algunas regiones | Ruta, propagación DNS, geografía o diferencias de política | Comprobador web más una revisión metodológica desde otro entorno |
03
Una secuencia limpia de diagnóstico inicial
Así evitas saltar de herramienta en herramienta sin aprender nada nuevo.
Empieza por la URL exacta que falla
Usa el host, el esquema y la ruta reales siempre que puedas para que las redirecciones y el comportamiento del certificado sigan siendo relevantes.
Clasifica la primera capa en la que aparece el fallo
Decide si la primera señal seria apunta a DNS, conexión, TLS o una respuesta HTTP o de aplicación.
Abre una sola herramienta de seguimiento especializada
Usa Consulta DNS, Comprobador SSL, Comprobador de puertos, Ping o Traceroute solo después de que la primera ejecución amplia te diga qué capa merece atención.
Comprueba si el resultado puede depender de la ubicación
Si solo se quejan algunos usuarios o el sitio está detrás de un CDN o de una política regional, ten presente la limitación de una sola vista antes de hacer afirmaciones demasiado amplias.
04
Señales que suelen llevar a error
Son observaciones técnicamente ciertas que aun así empujan hacia un diagnóstico equivocado.
- “Ping funciona, así que el sitio tiene que estar bien”.
- “El certificado es válido, así que HTTPS no puede ser el problema”.
- “DNS responde, así que el fallo tiene que estar dentro de la aplicación”.
- “El sitio falló desde una ubicación o desde ambas sondas aquí, así que tiene que estar caído para todo el mundo”.
05
Mejores herramientas para acotar problemas comunes de disponibilidad
Elige la herramienta que mejor encaje con la familia de problema que ahora te parezca más probable.
Es el mejor primer paso cuando todo lo que sabes es que una URL parece rota y necesitas una clasificación rápida y seria.
Comprobador webRespuestas DNS analizadasUsa Consulta DNS para problemas de resolución de nombresÁbrela después de IP erróneas, respuestas vacías, NXDOMAIN o sospechas de propagación o delegación.
Consulta DNSInspección de certificados y TLSUsa el Comprobador SSL para fallos de confianza HTTPSEs la mejor opción para analizar ciclo de vida del certificado, cobertura del host, certificados autofirmados y visibilidad de protocolos.
Comprobador SSLConectividad TCPUsa el Comprobador de puertos cuando sospeches de la capa de conexiónResulta útil cuando 80 o 443 pueden estar cerrados, filtrados o simplemente sin escucha desde una de las ubicaciones de prueba.
Comprobador de puertos