Cómo diagnosticar los errores «No se puede acceder a este sitio»

«No se puede acceder a este sitio» (o la frase equivalente de tu navegador) es deliberadamente vago: abarca desde un error tipográfico en la URL hasta un servidor totalmente caído o una caída de red en tu propia conexión. Para resolverlo con eficiencia hay que empezar por lo más barato y rápido de comprobar.

Empieza con una consulta DNS sencilla

Antes de suponer que un servidor está caído, resuelve el dominio por separado, al margen de tu navegador. Si devuelve una dirección IP limpia, el DNS no es el problema y puedes pasar a revisar la conexión en sí (si el puerto está abierto, si TLS negocia, si el servidor responde realmente). Si devuelve NXDOMAIN, un tiempo de espera agotado o una dirección privada o de aspecto inalcanzable, has aislado el problema en el DNS, lo que descarta de inmediato toda una categoría de otras comprobaciones.

Qué te dice cada resultado

Por eso mismo una herramienta de consulta rápida y sin registro resulta realmente útil en mitad de una incidencia: te da la respuesta de la capa DNS en segundos, sin necesidad de abrir un terminal ni recordar la sintaxis de dig/nslookup, de modo que puedes determinar de inmediato si realmente se trata de un problema de DNS antes de perder tiempo en cualquier otro sitio.

Más allá del DNS: qué revisar a continuación, en orden

1. La conectividad TCP con la IP resuelta en el puerto esperado (normalmente 443): un cortafuegos o un servidor totalmente caído rechazarán la conexión o se quedarán colgados aquí aunque el DNS sea perfecto.
2. La validez del certificado TLS: un certificado caducado o que no coincide produce una advertencia de seguridad en el navegador que parece alarmante, pero que no tiene nada que ver con el DNS ni con que el servidor sea accesible.
3. La respuesta a nivel HTTP: un servidor que acepta la conexión pero devuelve un error 5xx está activo y es accesible, simplemente falla en la capa de aplicación, varios pasos más allá de cualquier cosa que el DNS pudiera haber causado.

Avanzar por estos pasos en orden (DNS, luego transporte, luego TLS y después aplicación) hace que cada paso descartado reduzca de forma significativa las posibilidades restantes, en lugar de adivinar sobre toda la pila a la vez.

Por qué este orden en concreto

Cada capa de esta secuencia depende por completo de que la anterior tenga éxito, y por eso comprobarlas en orden (en lugar de saltar a la que parezca más probable) es el enfoque eficiente. No tiene sentido inspeccionar un certificado TLS si la conexión TCP nunca llegó a completarse, ni revisar los códigos de respuesta HTTP si falló la negociación TLS. Empezar por el DNS (lo primero que tiene que ocurrir para que el resto sea siquiera posible) y avanzar hacia fuera capa a capa significa que nunca pierdes tiempo investigando un síntoma que en realidad estaba causado por un problema más sencillo de una capa anterior.