Monitorización de sitios web por tipo de error: DNS, TCP, TLS y HTTP

Cuando un sitio web deja de funcionar, la falla a menudo se siente como una caja negra. Los visitantes ven una rueda giratoria, un código de error críptico o una página en blanco. Para las personas responsables de mantener ese sitio en línea, la primera pregunta siempre es la misma: ¿qué se rompió?

La verdad es que no existe una sola forma en que un sitio web «se caiga». En cambio, una solicitud desde un navegador pasa por varios pasos: resolución DNS, conexión TCP, negociación TLS y respuesta HTTP. Cada paso depende de los anteriores. Y en cada paso, distintas cosas pueden fallar.

Por eso la monitorización inteligente de la disponibilidad no se limita a decirte que el sitio está «caído». Te dice dónde en la cadena ocurrió la falla. Los errores de DNS señalan una cosa. Los errores de TCP otra. Los errores de TLS/SSL indican una causa raíz distinta a los 5xx de HTTP. Si sabes qué capa falló, sabes a qué equipo o proveedor debes contactar, y puedes acortar el tiempo de resolución dramáticamente.

Este artículo repasa cada tipo de error en el orden en que un navegador carga realmente un sitio: DNS, TCP, TLS y HTTP. Para cada uno, explicaremos qué hace el paso, qué puede salir mal y cómo la monitorización puede detectar problemas antes que tus clientes.

Errores de DNS

DNS es donde comienza toda solicitud web. Cuando un usuario escribe tu dominio en un navegador, lo primero que sucede es una consulta para resolver ese dominio en una dirección IP. Si ese paso falla, nada más importa: no se puede establecer conexión, no se puede verificar ningún certificado y nunca llegará una respuesta HTTP. Por eso los errores de DNS son a menudo las señales más tempranas y críticas de una interrupción.

Errores comunes de DNS

A continuación se muestran algunas fallas comunes de DNS:

• NXDOMAIN — Esto significa que el nombre de dominio simplemente no existe. En la práctica, generalmente proviene de registros caducados, zonas mal configuradas o errores tipográficos en las entradas de registros. Un dominio caducado puede dejar tu sitio entero fuera de línea al instante, mientras que un registro mal escrito puede afectar solo a un subdominio o servicio.
• SERVFAIL — Un error de servidor que indica que el servidor DNS autoritativo no pudo procesar la solicitud. A menudo apunta a archivos de zona rotos, registros glue faltantes o problemas de validación DNSSEC. Los SERVFAIL suelen aparecer de repente después de cambios de configuración, por lo que son una señal de aviso útil sobre despliegues erróneos.
• Time-outs — Cuando no llega respuesta dentro de los límites esperados, el cliente finalmente se rinde. Los time-outs suelen ser causados por servidores de nombres sobrecargados, interrupciones de red o ataques DDoS que saturan el resolvedor. Dado que las consultas DNS ocurren antes de que entre en juego el caché, incluso pequeñas subidas de latencia aquí pueden repercutir en tiempos de carga más lentos en toda tu base de usuarios.

Cómo monitorizar DNS

Monitorizar la salud de DNS va más allá de comprobar si tu dominio se resuelve una vez. Requiere probar las rutas de resolución tal como las experimentan los usuarios reales:

• Comprobaciones globales: Los agentes de monitorización sintética deberían ejecutar consultas DNS desde múltiples geografías y redes. Un registro puede resolverse correctamente desde tu oficina pero fallar en Asia o Sudamérica debido a problemas de enrutamiento anycast o interrupciones regionales en tu proveedor.
• Conciencia del TTL: Cada registro lleva un valor de time-to-live (TTL) que controla el caché. Los TTL largos aceleran la navegación normal pero pueden retrasar la propagación después de cambios. La monitorización debería validar que los nuevos valores realmente se reflejan en consultas en vivo y que no persiste caché obsoleta.
• Alertas por anomalías: Las señales más accionables provienen de tendencias. Un aumento repentino de respuestas NXDOMAIN o SERVFAIL, o un pico en la latencia de resolución, suele ser la primera pista de que algo anda mal — incluso antes de que los clientes empiecen a quejarse.

Cuando la monitorización de DNS falla, también te da confianza sobre lo que no es el problema. Si las consultas no se resuelven, entonces no se intentaron las comprobaciones de TCP, TLS ni HTTP. Eso reduce rápidamente el triage. En la mayoría de los casos, las soluciones implican a tu proveedor de alojamiento DNS, registrador o quien gestione el archivo de zona. Los equipos maduros construyen relaciones y rutas de escalado con esos proveedores para que los problemas puedan elevarse y resolverse con rapidez.

Fallas de conexión TCP

Una vez que DNS ha resuelto una dirección IP, el siguiente paso es el handshake TCP. Esto es el equivalente digital a darse la mano: el cliente envía un SYN, el servidor responde con SYN-ACK y el cliente confirma con ACK. Solo después de este intercambio se establece un canal de comunicación.

Si TCP falla, el navegador sabe dónde debería estar el servidor pero no puede hablar con él. El resultado se siente como un agujero negro: las páginas se quedan colgadas, los sockets nunca se abren y los usuarios ven ruedas giratorias interminables. A diferencia de los errores de DNS, que suelen ser rápidos y evidentes, las fallas de TCP a menudo crean interrupciones parciales confusas donde el sitio está accesible para algunas personas pero no para otras.

Errores comunes de TCP

• Conexión rechazada — El cliente alcanzó el host, pero no había nada escuchando en el puerto esperado. Esto suele ocurrir cuando los servicios se bloquean, los contenedores mueren o los balanceadores de carga están mal configurados. Un servidor web que olvidó enlazar el puerto 443 es invisible incluso si la máquina en sí está bien.
• Conexión agotada (timed out) — Los paquetes se están perdiendo en algún punto del camino. Esto podría ser un firewall que bloquea el tráfico silenciosamente, una mala configuración de enrutamiento o congestión en un proveedor upstream. Los time-outs son especialmente frustrantes porque no proporcionan retroalimentación: solo silencio hasta que el cliente se rinde.
• Reinicio de conexión — Aquí el handshake se completa pero se termina casi inmediatamente. Los reinicios suelen apuntar a proxies sobrecargados, timeouts de inactividad agresivos o middleboxes (como WAFs) que terminan lo que consideran sesiones sospechosas.

Cómo monitorizar TCP

Las comprobaciones básicas de disponibilidad no son suficientes aquí. Los pings ICMP pueden tener éxito mientras que los handshakes TCP fallan, dando una falsa sensación de salud. La monitorización TCP adecuada se centra en el comportamiento de la conexión:

• Validación del handshake: Las herramientas deberían intentar explícitamente un intercambio SYN/SYN-ACK/ACK en el puerto real del servicio. Esto asegura que el listener es alcanzable y responde.
• Análisis de la ruta: Traceroutes o MTRs desde distintas regiones pueden revelar dónde se están atascando las conexiones — si dentro de tu centro de datos, en el borde de tu CDN o en un ISP upstream.
• Paridad de protocolo: Si soportas tanto IPv4 como IPv6, monitoriza ambos. Muchos incidentes reales afectan a uno solo, creando problemas visibles para clientes que se pasan por alto si solo pruebas el otro.

La monitorización TCP da la confianza de que los servidores no solo están vivos, sino preparados para aceptar tráfico. Y reduce el triage: si TCP falla, la resolución DNS ya funcionó, por lo que el problema está en el host o en la ruta de red. Esa claridad evita que los equipos persigan falsos culpables en la capa de aplicación cuando el verdadero problema es una regla de firewall o un pool de balanceo de carga que eliminó su último nodo sano.

Errores de TLS/SSL

Hoy en día, casi todos los sitios funcionan sobre HTTPS (comparado con años anteriores, cuando SSL no era tan común). Eso significa que, después del handshake TCP, el navegador y el servidor necesitan negociar una sesión TLS (Transport Layer Security). TLS hace dos trabajos a la vez: cifra los datos en tránsito y demuestra que el servidor es quien dice ser mediante certificados digitales.

Esa confianza viene con complejidad. Si los certificados expiran, no coinciden con el nombre de host o no pueden validarse, los usuarios verán advertencias del navegador — o la página directamente se negará a cargar. En la práctica, los errores de TLS son algunos de los incidentes más visibles y embarazosos que puede tener un sitio, porque detienen a los usuarios en la puerta con una alerta que no pueden omitir de forma segura.

Errores comunes de TLS/SSL:

• Certificado caducado — La ventana de validez del certificado ha expirado. Este es uno de los cortes más comunes porque no hay automatización en su renovación o la renovación no se propagó a todas partes.
• Desajuste de nombre de host — El certificado fue emitido para www.example.com, pero el usuario visitó api.example.com. Esto suele ocurrir tras añadir nuevos subdominios o mover servicios detrás de un CDN.
• Autoridad de certificación no confiable — El navegador no reconoce a la CA emisora, normalmente porque el certificado fue autofirmado o encadenado a una raíz privada no instalada en los dispositivos clientes.
• Fallo de handshake — La negociación criptográfica en sí falla. Las causas varían desde suites de cifrado no soportadas, versiones de protocolo obsoletas o una cadena de certificados corrupta.

Cómo monitorizar TLS:

La monitorización TLS debe ser proactiva y continua. Los certificados no fallan de forma gradual: funcionan un día y bloquean el acceso al siguiente. Una buena monitorización debería:

• Rastrear la validez del certificado y generar alarmas mucho antes del vencimiento — idealmente con varios umbrales (30 días, 7 días, 1 día).
• Validar la cadena completa de certificados desde múltiples regiones, ya que intermediarios faltantes o problemas regionales con CAs pueden romper la confianza de forma diferente en distintas partes del mundo.
• Comprobar compatibilidad de protocolo y cifrado, asegurando que el sitio siga siendo compatible conforme los navegadores van deprecando versiones antiguas como TLS 1.0 y 1.1.
• Vigilar picos de errores de handshake, que a menudo coinciden con malas configuraciones de balanceadores de carga o despliegues en CDNs.

Cuando aparecen fallos de TLS en la monitorización, también aportan contexto: la resolución DNS funcionó, la conectividad TCP fue correcta, pero no se pudo establecer el canal seguro. Eso acota el troubleshooting de inmediato. La solución suele estar en la renovación de certificados, configuración del balanceador de carga o terminación en el borde, no en el código de la aplicación.

Para muchos equipos, la lección operativa es simple: trata los certificados como código. Automatiza la emisión y renovación, monitoriza la expiración con la misma agresividad con que monitorizas el espacio en disco y ensaya las rotaciones para que los certificados que expiran nunca se conviertan en interrupciones públicas graves.

Errores HTTP

Finalmente, después de que DNS, TCP y TLS tengan éxito, el navegador envía una solicitud HTTP. El servidor responde con un código de estado HTTP: 200 si todo está bien, o un código de error si no.

La monitorización HTTP es lo que la mayoría de la gente piensa cuando imagina la «monitorización de disponibilidad». Pero sin el contexto de los pasos anteriores, los errores HTTP solo cuentan parte de la historia.

Errores HTTP comunes:

• 404 Not Found – El recurso no existe. Puede ser un enlace roto, una página eliminada o una solicitud mal enrutada.
• 500 Internal Server Error – El servidor encontró una condición inesperada. Normalmente errores de código o de configuración.
• 502 Bad Gateway – Un proxy o balanceador de carga no pudo obtener una respuesta válida de un servidor upstream.
• 503 Service Unavailable – El servidor está sobrecargado o en mantenimiento.
• 504 Gateway Timeout – Un servicio upstream tardó demasiado en responder.

Cómo monitorizar HTTP:

• Ejecuta solicitudes sintéticas GET desde agentes globales para verificar las respuestas.
• Captura los códigos de respuesta y alerta ante cualquier cosa fuera del rango 200–299.
• Monitoriza flujos de transacción, no solo páginas aisladas (login, luego añadir al carrito, luego checkout).
• Establece umbrales para el tiempo de respuesta, no solo para la disponibilidad.

La monitorización HTTP te dice que la capa de aplicación está rota. A diferencia de los problemas de DNS/TCP/TLS, los errores HTTP suelen estar en manos de los equipos de desarrollo u operaciones, no de proveedores externos.

Unirlo todo: Una estrategia de monitorización por capas

El valor de desglosar los errores por tipo es la claridad. Cada fallo ocurre en secuencia. Si DNS falla, nada más ocurre. Si TCP falla, DNS estuvo bien. Si TLS falla, DNS y TCP funcionaron. Si HTTP falla, todo hasta ese punto funcionó.

Un enfoque de monitorización por capas refleja esta secuencia:

1. Comienza con comprobaciones DNS.
2. Añade monitorización de conexiones TCP.
3. Superpone monitorización de certificados TLS.
4. Finaliza con monitorización de respuestas HTTP.

Este modelo por capas te permite identificar la causa raíz rápidamente:

• ¿Error de DNS? Llama a tu proveedor de DNS.
• ¿Error de TCP? Involucra a tu hosting o ISP.
• ¿Error de TLS? Arregla tu certificado o la configuración del borde.
• ¿Error de HTTP? Habla con tu equipo web.

En lugar de una vaga alerta de «el sitio está caído», obtienes un mapa preciso de qué se rompió y a quién debe solucionarlo. Eso reduce el tiempo medio de resolución (MTTR) y evita que los equipos se echen la culpa unos a otros.

Conclusión

Los sitios web no fallan de una sola manera: fallan en capas. DNS, TCP, TLS y HTTP introducen cada uno sus propios riesgos y sus propias firmas de error. Monitorizar por tipo de error convierte esa complejidad en claridad.

Con la estrategia de monitorización adecuada (y una herramienta como Dotcom-Monitor), no solo sabes que el sitio está caído: sabes por qué está caído. Sabes si debes escalar con tu proveedor DNS, con el proveedor de red, con el equipo de seguridad o con los desarrolladores. Y obtienes esa visibilidad rápido, sin esperar un ticket de soporte o la queja de un cliente.

Al final, monitorizar por tipo de error no se trata solo de disponibilidad. Se trata de responsabilidad y velocidad. La próxima vez que tu sitio falle, no te conformes con «algo se rompió». Sabe exactamente qué capa falló, qué significa y cómo arreglarlo.