¿El sitio web está caído para todos o solo para mí?

Por qué lo zanja una verificación multiubicación

Una petición desde tu portátil pasa por la caché del navegador, el resolutor DNS de tu sistema operativo, tu router y tu proveedor de internet, y solo después llega al camino de internet hacia el servidor. Cualquiera de esas capas puede fallar por su cuenta mientras el servidor está perfectamente sano. Lanza la misma petición desde un punto de verificación de otro país y ninguna de tus capas locales interviene. Si allí también falla, el problema está en el destino. Si funciona, el problema está entre tú e internet, y la búsqueda ha pasado del mundo entero a tu propio equipo y tu red.

Ejecutarla desde más de una ubicación añade una tercera respuesta posible, y es habitual: el sitio está en pie en unos sitios y caído en otros. Ese patrón apunta a una ruta de red regional, a un nodo de borde de una CDN, a un bloqueo geográfico o a un cambio de DNS que ha llegado a unos resolutores y a otros no, y no a que el servidor esté apagado.

Qué suele fallar cuando eres solo tú

• Caché DNS obsoleta. Tu resolutor o tu sistema operativo todavía guardan una IP antigua del dominio, así que te estás conectando a un servidor que se ha mudado.
• Tu proveedor de internet o la ruta hasta el host. Un enlace de interconexión roto o un problema de enrutamiento afecta a todos los de ese proveedor y a nadie más.
• VPN o proxy corporativo. El tráfico sale desde otro sitio completamente distinto, y ese punto de salida puede estar bloqueado, filtrado o simplemente lento.
• El archivo hosts. Una entrada añadida hace meses durante unas pruebas sigue teniendo prioridad sobre el DNS real, normalmente apuntando a una máquina que ya no está.
• Caché del navegador, service worker o una extensión. Una página de error en caché, un service worker obsoleto o un bloqueador de contenido pueden hacer que una página que funciona parezca muerta.
• Cortafuegos local o software de seguridad. Algunas suites bloquean categorías enteras de sitios, o bloquean un puerto que el sitio necesita.
• Un certificado caducado o no confiable solo en tu máquina. Un reloj del sistema mal puesto hace que todos los certificados válidos parezcan caducados.

Cómo verificar desde otra red

La prueba manual más rápida no necesita herramienta alguna. Apaga la Wi-Fi del teléfono y abre el sitio con datos móviles: otra red, otro resolutor DNS. Si allí carga y en tu portátil no, el fallo es local.

Desde un terminal, pide las cabeceras directamente y luego pregunta a un resolutor público qué IP cree que tiene el dominio:

curl -I -sS --max-time 10 https://example.com/
dig +short example.com @8.8.8.8
dig +short example.com

La primera línea te dice si respondió algún servidor y con qué código de estado. Si curl informa de un tiempo de conexión agotado o de un fallo de DNS, no respondió nada. Si las dos líneas de dig no coinciden, tu resolutor local guarda una dirección distinta de la del público, y una caché obsoleta es el sospechoso probable. En Windows, ipconfig /flushdns vacía la caché local; en macOS, sudo dscacheutil -flushcache; en la mayoría de los sistemas Linux basta con reiniciar el servicio del resolutor.

Qué significa cada resultado

• Caído en todas partes. El servidor, su alojamiento o su DNS están rotos de verdad. Mira el código de estado: un 502 o un 503 significan que algo respondió y que la aplicación de detrás no, lo que es muy distinto de que no responda nada.
• Caído solo en algunos sitios. Sospecha de un DNS que no ha terminado de actualizarse en todas partes, de un nodo de borde o una región de la CDN con un problema, o de una regla de cortafuegos que bloquea ciertas redes o países.
• En pie en todas partes menos para ti. Recorre las causas locales de arriba, empezando por el DNS y la VPN.
• En pie, pero lento en todas partes. No es una caída. A menudo va antes de una, así que mídelo bien en lugar de suponer.

Hay un detalle que despista. Un sitio puede estar "en pie" en el sentido de que devuelve una página y aun así estar roto para los visitantes: una verificación que solo mira si hay respuesta cuenta como éxito una página de error de base de datos si el servidor la devuelve con un 200. Fíjate en lo que volvió, no solo en si volvió algo.

Enterarte antes que un cliente

Una verificación puntual responde a la pregunta que tienes ahora mismo, y solo porque se te ocurrió hacerla. Las caídas que empiezan a las tres de la madrugada, o que solo afectan a una región, suele encontrarlas antes un cliente. El monitoreo programado ejecuta la misma verificación de forma continua desde muchas ubicaciones y te avisa en cuanto cambia el resultado, con la ubicación y el error incluidos. HostTracker ejecuta esas verificaciones desde más de 300 puntos de verificación en 158 ciudades y avisa por correo electrónico, SMS, llamada de voz, Slack, Telegram y otros canales, así que un fallo regional se distingue de uno global ya en la primera alerta. El comprobador de sitios caídos te da el estado de un sitio ahora mismo. Si el sitio responde pero responde despacio, mídelo como toca: tiempo de respuesta del servidor.